I am looking for a S3 bucket policy which can grant/restrict specific federated users access to the bucket. Federated users in aws uses IAM roles. Is there some way I can limit the access to a user even if the user has assumed the role. Is there a way I can specify federated users in a bucket policy? Also the S3 bucket is in a different account.
When a user is assuming a role, they are assigned a role-session-name. This can be used to track the identity of the user assuming the role.
From AWS JSON Policy Elements: Principal - AWS Identity and Access Management:
Specific assumed-role user
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
Related
In short: if I create an IAM policy containing a cross-account Principal, but the account in question is the one I'm already operating in, is that a no-op?
My understanding (from here) is that an IAM statement like the following can be used for cross-account access, i.e. to delegate to another account, allowing it to allow access to the resource in question:
{
Action = "kms:*"
Effect = "Allow"
Principal = {
AWS = "arn:aws:iam::XYZXYZXYZXYZ:root"
}
Resource = "*"
}
(where XYZXYZXYZXYZ is some account ID, obviously).
But what if the account ID isn't another account? I'd hope this does nothing. I'd fear it grants full access. Latter option seems insane: can anyone confirm?
I am assuming this is in a KMS key policy otherwise specifying the principal would not make sense / would be disallowed by IAM anyway.
Therefore I am quoting https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html:
The following default key policy statement is critical.
It gives the AWS account that owns the KMS key full access to the KMS key.
Unlike other AWS resource policies, an AWS KMS key policy does not automatically give permission to the account or any of its users. To give permission to account administrators, the key policy must include an explicit statement that provides this permission, like this one.
It allows the account to use IAM policies to allow access to the KMS key, in addition to the key policy.
Without this permission, IAM policies that allow access to the key are ineffective, although IAM policies that deny access to the key are still effective.
It reduces the risk of the key becoming unmanageable by giving access control permission to the account administrators, including the account root user, which cannot be deleted.
The principals within the account do not immediately have access to the key but just adding a policy to them will grant them access. KMS is one of the few services with where both the resource and the identity policies need to grant the access.
I'm developing a mobile application & i want to upload/get/delete a file in AWS S3 bucket.
But I'm very concern about the security problem.
S3 Bucket: It should not be public and only authorize IAM user can access who have the permission to access my bucket.
So, need help to configure permission of my S3 bucket & create an IAM user.
That is not how you authorize access for mobile applications. Yes, you can create IAM user, generate access key and secret access key, store those keys in the application code and configure right permissions for the IAM user. Then you don't even need to configure bucket policy. By default, bucket is private and only IAM users in your account with appropriate permissions are able to access it. If you allow IAM user to access specific S3 bucket then you would need to configure explicit deny on bucket policy to override it.
But the above approach is against every security good practice. What you really want to do is to create IAM role that allows access to the bucket and assume that role from within the application. You can set up Cognito + web federation (or some other web federation provider) for your users and ask STS service to generate short lived credentials using sts:assumeRoleWithWebIdentity command.
As for the IAM permissions, you will need to allow s3:PutObject, s3:GetObject and s3:DeleteObject so the policy can look something like this.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "<arn-of-your-bucket>"
}
]
}
You can be even more granular and allow Cognito users to access only "their" folder inside of a bucket if you need to.
As for the role, you just need to attach the above policy to it and configure trust relationship between the role and web identity provider (as mentioned above, this can be Cognito or any OpenID provider).
You define policies that Grant access to resources generally but can I use a policy that grants access to the IAM user it's applied to?
I guess I want a bucket access policy but for an IAM user. I want to attach a policy to a user that says give a specific iam role access to me.
I am trying to add a bucket policy to my bucket because my bucket is in a root aws account, and I want to restricts other users, roles, etc. under the root account from accessing my bucket except for a specific Cognito user in my User Pool.
I do not want to also use an identity pool -- I would just like to refer to the Cognito user as the principal in my bucket policy. Is there any way to do this without using an identity pool? I can't find any example policies that do this.
You can set the Principle of your bucket policy as the auth role of your Cognito user. In my case, the Principle looks like
"Principal": {
"AWS": "arn:aws:iam::123456789000:role/NAME_OF_MY-authRole"
},
Then, you can further control the access by changing the Resource. Here is the example from AWS docs.
"arn:aws:s3:::bucket-name/cognito/application-name/${cognito-identity.amazonaws.com:sub}",
"arn:aws:s3:::bucket-name/cognito/application-name/${cognito-identity.amazonaws.com:sub}/*"
I am trying to create IAM Policy which restricts passing the IAM Role to an EC2 instance that if instance id does not equal to i-1234567890abcd
There is no error in the policy but there is no effect of this policy either. If I remove Condition from the below policy, it works but it restricts the role to be attached to any EC2 instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["iam:PassRole"],
"Resource": ["arn:aws:iam::000000000000:role/MyEC2InstanceSpecificRole"],
"Condition": {
"ArnNotEquals": {
"ec2:SourceInstanceARN": "arn:aws:ec2:us-east-1:000000000000:instance/i-1234567890abcd"
}
}
}
]
}
I suspect that this is not possible.
The Granting a User Permissions to Pass a Role to an AWS Service documentation states:
To pass a role (and its permissions) to an AWS service, a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, you must grant the PassRole permission to the user's IAM user, role, or group.
When a user passes a role ARN as a parameter to any API that uses the role to assign permissions to the service, the service checks whether that user has the iam:PassRole permission. To limit the user to passing only approved roles, you can filter the iam:PassRole permission with the Resources element of the IAM policy statement.
Also on Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances it states:
PassRole is not an API action in the same way that RunInstances or ListInstanceProfiles is. Instead, it's a permission that AWS checks whenever a role ARN is passed as a parameter to an API (or the console does this on the user's behalf). It helps an administrator to control which roles can be passed by which users.
The normal use-case for PassRole is to ensure that users do not grant AWS Services any more permissions that they should be allowed to use themselves. It tries to avoid a situation where a non-Admin user passes an Admin role to a service with the sinister intention of then using that service to access resources that they would not normally be allowed to access. For example, launching an Amazon EC2 instance with an Admin role, so that they can then login to that instance and issue Admin commands that they would not normally be entitled to use.
The above documentation suggests that the PassRole permission is evaluated to confirm their permission to pass a certain role to a certain service, rather than how that service is going to use the role itself (eg by then assigning it to an EC2 instance to generate STS credentials).