I am busy setting up minio for the first time and I would like to limit each user so that they can only see buckets they create, or public buckets.
The idea being that admin can see all buckets, but user1 can only see buckets created by user1, etc.
Is this possible?
I know that using mc policy I can set a buckets access policy to none, download, upload, public. To the best of my knowledge, setting the policy to none will require authenticated access to a bucket - but this will allow any authenticated user which is not what I want.
I have come across this ticket on github - https://github.com/minio/minio/issues/6811
This will create a user policy that limits the users access to a single bucket. The provided example does not allow the user list buckets (private and self created), create new buckets, etc. This user can only access the bucket listed in the policy.
Answering my own question with feedback from the minio team
No it is not possible, we do something similar to what AWS does, user
is not tied to buckets . Buckets exist for all users you just
selectively give them access.
Related
I want to use data transfer API by GCP to grab data from s3 to my GCS bucket. The S3 bucket is controlled by our client and we have zero control on it.
We learned to use this API the AWS IAM has to have these permissions:
s3:ListBucket
s3:GetObject
s3:GetBucketLocation
https://cloud.google.com/st... (edited)
When I asked them, they said the permission are given in prefix level and not bucket level since the bucket has data for many clients and not just us. They do not want to give any permission which might give us access to the whole bucket data and we should be limited to our prefix level.
I want to know if asking for this permission (s3:GetBucketLocation) in the prefix level will give us access to the ALL data present in the bucket? or it is just allowing the transfer API to locate the data?
I did check the AWS documentation and the closest answer was about GetBucketLocation API which stated:
" Returns the Region the bucket resides in. You set the bucket's Region using the LocationConstraint request parameter in a CreateBucket request. For more information, see CreateBucket."
So it does seem it only returns the region of the bucket BUT there is no documentation to be found specific to the permission itself.
In google documentation it does say that this API is only need the region, however we need to make sure it does not open a way for us to read all the data in the bucket if that makes sense.
Please let me know if you have any knowledge on this.
Firstly, I don't think you need to get the bucket's region programatically. If you're interested in a specific bucket, perhaps the client could tell you the region of it?
The action-level detail is in the SAR for S3 which just says:
Grants permission to return the Region that an Amazon S3 bucket resides in
So there's nothing about object-level (i.e. data) access granted by it.
I'm implementing an iOS app with group-chat support, where users can add photos, other files.
Decided on AWS S3 as storage back end, using Cognito Federated Identities to authenticate upload/downloads - data pumped to/from S3, not via our servers.
So far
my implementation allows a user/identity to upload & download to their their own folder on an S3 bucket (example policy arn:aws:s3:::mybucket/users/${cognito-identity.amazonaws.com:sub}/* the variable being the identityID/user_id).
However
I've not been able to find a secure way that allows only participants in a group-chat to upload/download from that group-chat's folder on S3.
Any ideas?
some thoughts on a possible flow:
first, user upload photo to own folder, [ I know how ]
then, the system copies over the photo into the group-chat's folder [ I know how ]
associate group-chat folder with the identities of participants [ not sure how - there could be thousands of groups & participants ]
EDIT 1: as #MyStackRunnethOver suggest, could use one IAM role/credential to manage all upload/download request for users (that belong to said group) [ big security concern if credential compromised ].
EDIT 1: could use PreSigned URLs: files uploaded to user's own folder, presigned url stored on group-chat entries [ max url-life 7days though ]
client caching helps until participants join/leave a group frequently
requires server-side scheduled job to renew expired PreSigned URLs
Any commends/ideas appreciated
Your question boils down to:
"Given that users are part of groups, how can I give users access to group-specific subdirectories based on group membership?"
As I see it, you have two options:
Give each user the "key" to all directories they're a member of. This could mean adding a permission to that user for each group, or providing them with access to a new IAM role for each group. This is the "come up with a way to have fine-grained permissions for S3" strategy.
Don't distribute any directory-specific keys. Instead, when a user requests a certain directory, check whether they're in the group that directory belongs to. This is the "build a fine-grained data storage system around S3" strategy.
I recommend the latter approach, because instead of having an IAM role or a credential per user or per group, you give all your users one credential: the credential needed to make requests of your S3 wrapper. If you keep track of which groups your users are in, all your wrapper needs to do is check the user -> groups mapping to see if a request should be fulfilled. The front end can use the same mapping to prettify the UI: a user is only shown the option to upload / download from the groups they are a member of. In this case, I would envision the mapping as a Dynamo table that is updated whenever a user signs up, joins a group, leaves a group, or deletes their account. You can identify your users by their Cognito credentials, which include user-specific fields.
Amazon STS offers the ability to take an IAM token and create a limited subset of the abilities of that token for other use. The subset of abilities can be by time (expiring in N hours) and by allowed operations (e.g. read one S3 bucket but not all the S3 buckets the original token can read).
Because this is done using the S3 ARN format which which supports wildcards in the S3 key name, that means it's possible to create a sub-token that can read part of an S3 bucket.
Looking through Google Cloud Storage's's access control docs I couldn't find the equivalent of this functionality in GCS.
To be more specific, I'd like to create a bucket with these four objects:
/folder1/file1
/folder1/file2
/folder2/file3
/folder2/file4
And given a token with permissions to access all files indefinitely, produced a limited subset of the token with permissions to view just the objects in /folder2/* (so /folder2/file3 and /folder2/file4) for N hours.
Is this possible in GCS like it is in S3/STS?
Currently, in GCP there are no tokens with a limited subset of the abilities of another token.
The most similar thing to what you are asking are Signed URLs, since they allow access time-limited access to Cloud Storage objects.
I don't know why you need them to have abilities that are a subset to the ones of another token, but in your case you could just create Signed URLs with permissions to view the objects in /folder2/*
I am planning a game app for mobile devices. Users will log into the game using their existing social media account to streamline data capture. Company B would like to directly save player data and scoring information from the mobile app to a DynamoDS table named Score Data When a user saves their game the progress data will be stored to the Game state S3 bucket.
What is the best approach for storing data to DynamoDB and S3?
Option 1: Use an EC2 Instance that is launched with an EC2 role providing access to the Score Data DynamoDB table and the GameState S3 bucket that communicates with the mobile app via web services.
Option 2: Use temporary security credentials that assume a role providing access to the Score Data DynamoDB table and the Game State S3 bucket using web identity federation.
Many architects I talked to Option 1 is the right one. But according to AWS doco, it appears Option2 can be valid too. Any inputs would be appreciated!
I would strongly consider Option #2 using Amazon Cognito to provide temporary credentials to your users that enable them to directly and specifically access DynamoDB and S3.
Generally speaking, you need to:
Create a new Cognito Identity Pool and set up 2 IAM roles -- one for authenticated users and one for unauthenticated users (optional). https://docs.aws.amazon.com/cognito/devguide/getting-started/?platform=ios
Authenticate a user via your own authentication provider or via external providers like Facebook, Twitter, etc., and then use Cognito to create temporary credentials for them. https://docs.aws.amazon.com/cognito/devguide/identity/external-providers/
Use the credentials to access DynamoDB and/or S3. Your AWS resources will be protected as long as you set up your IAM roles appropriately. For example, you can give fine grained access to your DynamoDB table so that users cannot access rows that don't belong to them. See the following link for more details: https://docs.aws.amazon.com/cognito/devguide/identity/concepts/iam-roles/
The Cognito developer guide is here: https://docs.aws.amazon.com/cognito/devguide/.
This is really a two part question:
I'm seeing some users in the "Grantee" dropdown for editing S3 permissions within the AWS console.
Where are those users coming from?
How can I delete them?
They aren't in IAM so I'm not really sure where they're coming from.
A grantee can either be an AWS account (which you probably added in the past) or a predefined AWS "group", such as "Authenticated Users", "All Users" or "Log Delivery". Please have a look at ACL Overview, on AWS docs, for more information.
For removing grants from a given file (or from a set of files), you can use the PUT Object acl operation.
It is not clear, on the documentation, what you need to do in order to remove an user from the "Grantee" list. I performed some tests and this is how S3 is behaving:
If you select a file using the S3 Management Console and add permission to a new user (not yet in your grantees list), using his email address (make sure the email belongs to a valid Amazon account), that user does NOT go to the bucket ACL, but goes to the object ACL. This user also goes to the Grantees list permanently (even though his friendly name, instead of his email address, is what shows up there).
If you log out from the AWS console and log in again, the user is still on the Grantees list and you can give him permissions for other objects.
If you remove the given user's permissions on every object, log out and log in again, the user will not show on the Grantees list anymore.
If you add a given user to the Bucket ACL (either via API or via the AWS Console), the user will always be in the Grantees list for objects on that bucket.
This makes me think the Grantees list contains the entire list of users in your bucket's ACL plus a cache of users with permissions to objects in your bucket (which is cleared upon logging out, if you remove those permissions).
So, I would try first removing the users you don't want from your bucket's ACL, and then (via API, of course) remove those user's permissions for the objects in your bucket.
If there is a specific grantee name that you can't find in IAM, it's probably the default grantee which corresponds to yourself. Its name is the same as your AWS Forum nickname.