...
- Policies are attached to buckets and are a list of statements about actions allowed or denied for that bucket only.
- Policies override the default project permissions so care should be taken not to lock yourself out of the bucket.
- Any DENY in a policy statement counts as a negative permission overall for that action, even if there is also an ALLOW elsewhere.
- Policies only grant visibility of objects in a bucket, not visibility of the bucket itself.
Note |
---|
You can use the pshell command "info mybucket" to examine the active policies on that bucket. |
Expand | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Example1 - give a list of Pawsey usernames (user1, user2, user3, and user4) readonly access to a project bucket called p0002-sfx. Note: if a user (eg user1) attempts to list buckets they will see nothing. However, if they attempt to list objects inside the bucket it will show the objects inside p0002-sfx/ - see Note 4.
Example 2 - revoke user3 from having read access to the bucket.
Example 3 - grant read and write permission on a bucket.
Example 4 - make the objects in p0002-sfx readonly and publicly accessible.
Example 5 - remove all policies on a bucket.
|
...
Simple S3 bucket lifecycles can also be automatically created for you affecting multi-part uploads and versioning.
Note |
---|
Remember to use Use the pshell command "info mybucket" to check if there are any current lifecycle rules as you may overwrite them with the following examples. |
...