Our organization is planning to use AWS Managed services like Rekognition, Textract etc. Since these services uses S3 buckets for Face comparison and analyzing documents. The concern is end users shouldn't be able to access buckets outside our organization, is there any way I can limit the access for only S3 buckets in my organization? Buckets can be created on the fly by the user, so the access control should cover all the buckets in the account.
We're also using VPC endpoints for these services.
There is no capability to configure Rekognition such that it can only use buckets within the specific AWS Account.
Objects in Amazon S3 are private by default. IAM Users in your organization will only have access to buckets for which they have been granted access via a policy on their IAM User, or via a Bucket Policy on the bucket itself.
If a user references an S3 object in a call to Amazon Rekognition, the user must have access to the bucket via an IAM Policy or Bucket Policy. If they can access the object, then they can use the object with Rekognition.
In other words, if they have general access to an object (eg to download the object), then they can use Rekognition with it.
Related
I've one AWS root account, if I need to grant the S3 bucket access to our application resides in Dev, Test and Prod environments. These S3 bucket will be accessed only by application and not by individual / manual user. I can refer multiple approaches, not sure which one is best approach here? Could you pls suggest on this?
Option-1: Create IAM user account for each environment with programmatic access only. Provide the Access KeyId and Secret Access key to respective environment(Dev, Test and Prod) to access the S3 resource. Separate S3 bucket will be created for each environment, S3 bucket policy will only allow the access to specific IAM user account only.
Option-2: Three separate AWS accounts. Not sure how to proceed on this further, will be having three root accounts to manage and separate billing, one S3 bucket for each AWS account.
Option-3: I can refer the landing zone concepts that comes with AWS organization account, Shared Services account, Log Archive Account and Security Account. Not sure where to specify / create the resources and IAM user account.
I am trying to move client data from clients S3 bucket(s3://client-bucket) to our organizations S3 bucket(s3://org-bucket) I was given access keys to the clients S3 bucket.
Using AWS CLI i am able to access S3 bucket of client as see all files. I cannot however use aws s3 mv because the profile that has access to client-bucket does not have permissions set up for org-bucket.
I am not allowed to move data to an intermediate public bucket bc of security issues/sensitivity of data.
What is the best way of making this transfer go thru? Is there a way to set up a profile in aws cli config/credentials with both the access keys to org-bucket and client-bucket?
The best way is to use the access keys in your organization to access your client's S3 bucket. Since you need to copy objects directly via the CopyObject API, your IAM user/role needs to have access to both the S3 bucket in your org AND your client's S3 bucket. Therefore, your current approach doesn't work and even AssumeRole would not work either. You can follow this guide to configure proper resource-based policies in S3.
Is there an easy way to see what are the effective access permissions for a specific bucket? To be more specific about the environment, access to buckets is granted through identity policies, there are more than 170 IAM roles and users and 1000+ policies (not all of them are attached to IAM role or user). I need to see who has the s3:GetObject, s3:PutObject and s3:DeleteObject permission on a specific bucket. Is there some tool that can give me that kind of report? I can write a script that goes through all roles, policies attached to them, pulls out statements that contain specific bucket and then I can cross reference allows and denys, but I'm sure there is some smarter way of doing this.
I am not aware of any better way than you described. You can export your IAM settings (unless you already have them in CloudFormation or CDK scripts) as described at https://aws.amazon.com/blogs/security/a-simple-way-to-export-your-iam-settings/.
Then you can scan (manually or programatically) for policies of interest and to what users or roles are they attached.
From Using Access Analyzer for S3 - Amazon Simple Storage Service:
Access Analyzer for S3 alerts you to S3 buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization. For each public or shared bucket, you receive findings into the source and level of public or shared access. For example, Access Analyzer for S3 might show that a bucket has read or write access provided through a bucket access control list (ACL), a bucket policy, or an access point policy. Armed with this knowledge, you can take immediate and precise corrective action to restore your bucket access to what you intended.
I have a couple of S3 buckets and I want to access them from an app. How do I generate AWS credentials with access restricted to those buckets? I suppose it would require using IAM users and groups.
I have an application on an EC2 Instance that I wish to put on the AWS Marketplace. The application uses AmazonS3 and on startup requires users to enter an Access Key, Secret Key, and a BucketName. It then uses the Accekey, and secretkey to create a bucket (specified by BucketName). However, this isn't allowed on the AWS Marketplace.
However, for AWS Marketplace,we require application authors to use AWS
Identity and Access Management (IAM) roles and do not permit the use
of access or secret keys.
Question
I am confused as to how to get around this and still put my AMI on the AWS Marketplace. My goal is for users to create their own S3 buckets in their own AWS Environments.
Your customers can create AWS IAM roles with access to the required resources (S3 buckets), and allow your account to use those roles.
The reasoning behind this mechanism is that your customers can follow the principle of least privilege and limit access to very specific resources and actions on those resources (instead of providing unsecured / root access to their entire account)