- Newest
- Most votes
- Most comments
The list of buckets always includes all the buckets in the account; permissions configuration can't be used to filter the list but only to allow obtaining the list or to block it.
If you definitely aren't seeing a bucket on the list and are still able to access it from the same CloudShell session without specifying a different CLI profile or separate credentials, that means that the principal (IAM role, IAM user, or root user) with which you are running CloudShell has been granted access to the target bucket in the bucket policy (or legacy ACLs).
The permissions granted by the bucket policy could just as well grant you the permission to list and delete all the objects in the bucket.
aws s3 ls will only list buckets from the account from which the CLI is uasing credentials from.
If you have the CLI configured with IAM user or role belongs to Account-A, then "aws s3 ls" you can only list buckets from Account-A provided the required permissions such as ListAllMyBuckets, S3ListBucket permissions.
If the role/user is granted permission with buckets from account-B, then you must use "aws s3 ls s3://accountB-bucketName"
Interesting - makes sense. So, why did the CloudShell CLI list that foreign bucket prior to my blundering around with rm? Note that I can still list <contents> of that bucket, but it isn't included in a top level 'ls' that shows other buckets.
as an addendum - I realize that in yet another account I have a number of buckets with policies permitting that same account/user which never appeared in the <ls> listing. But I can list their contents and presumably perform other operations on them.
Probably you had opened multiple browser sessions each logged into different AWS Account and possibly the CloudShell that you opened and saw the foreign bucket was actually from the same foreign account.
Or another reason could be, you may have exported AWS credential variables in CloudShell to use foreign account credentials.
Yeah, I was doing a number of things wrong. I was getting confused between local files and remote/bucket files, and had probably created a number of local files that I was mistaking for bucket contents. In CloudShell I lost sight of the difference between local and s3 commands. At least, having been bitten, I was able to write clear instructions for my audience. Cheers!
Relevant content
- asked 4 years ago
Thanks very much for the info. I am much less confused now. I can work with the buckets that have policies permitting that particular account /user. I tried to use the s3://accountID/bucketname addressing without success, but the straight aws s3 <cmd> bucketname seems to work fine.