I am confused with the policy variable "${aws:username}" i.e. whether it is the IAM username from which i logged in the AWS account or
is it the tag value that i manually entered in tags while creating instances.
Actually, i wanted to achieve that only owner of the ec2 instance should be to perform actions & othershould be denied. should the below policy works?
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
The policy variable ${aws:username} is replaced with the friendly name of the current IAM user when the policy is evaluated by IAM.
https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/
Your policy should work.
Related
I am trying to create an SCP policy to disallow creation of iam user in member accounts other than Admin (assumed role with SSO), however its not letting even the admin create the user, below is the policy I am using,
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:DeleteUser"
],
"Resource": [
"*"
],
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": [
"arn:aws:sts::*:assumed-role/AWSReservedSSO_AWSAdministratorAccess*/*"
]
}
}
}
]
}
Not sure what's wrong in it, please help
The PrincipalArn should be:
arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSAdministratorAccess*
To get an valid ARN for SSO assumed roles, you need to change arn:aws:sts::*:assumed-role by arn:aws:iam::*:role.
Additionally, this represents the SSO group, so you do not need to add /* after the group name. So the following ARN is incorrect and will not work:
arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSAdministratorAccess*
Reference:
Implement service control policy (SCP) for accounts in AWS Organizations
I need to create a cross account role to access the resources of S3 bucket from another aws account that I owns.
Please help me to implement this using the cross account IAM role without using Access or secret keys.
Let's say you have:
Role A in Account A
Instance A in Account A that is associated with Role A
Bucket B in Account B
You wish to allow an application on Instance A to access the content of Bucket B.
The Request Information That You Can Use for Policy Variables documentation has a table showing various values of aws:userid including:
For Role assigned to an Amazon EC2 instance, it is set to role-id:ec2-instance-id
Therefore, you could use the Role ID of the role associated with the Amazon EC2 instance to permit access OR the Instance ID.
For example, this bucket policy is based on a Role ID:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SID123",
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::MYBUCKET",
"arn:aws:s3:::MYBUCKET/*"
],
"Principal": "*",
"Condition": {
"StringLike": {
"aws:userid": [
"AROAIIPEUJOUGITIU5BB6*"
]
}
}
}
]
}
To obtain the Role ID, use:
aws iam get-role --role-name ROLENAME
This bucket policy is based on an Instance ID:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SID123",
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::MYBUCKET",
"arn:aws:s3:::MYBUCKET/*"
],
"Principal": "*",
"Condition": {
"StringLike": {
"aws:userid": [
"*:i-03c9a5f3fae4b630a"
]
}
}
}
]
}
The Instance ID will remain with the instance, but a new one will be assigned if a new instance is launched, even from the same Amazon Machine Image (AMI).
Of course, you'd probably want to restrict those permissions to just s3:GetObject rather than s3:*.
(This answer based on Granting access to S3 resources based on role name.)
I have an IAM user that launches a CloudFormation stack containing an
- EC2 Instance with an
- IAM Instance Profile associated with an
- IAM Role
in the AWS::CloudFormation::Init block, the EC2 instance performs some actions that require it to call some ec2:* API actions. However, this instance should ONLY be able to call these actions for that instance itself.
The user that launches the stack has the permission to attach only a set of predefined policies and to create roles. Something like this
"CloudFormationStackLauncher": {
"Type": "AWS::IAM::ManagedPolicy",
"Properties": {
"Description": "Allows attached entity to attach and detach required policies from roles it creates.",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:DetachRolePolicy"
],
"Resource": "*",
"Condition": {
"ArnEquals": {
"iam:PolicyArn": [
"arn:aws:iam:::policy/InstanceThatCanManageItself",
]
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole"
],
"Resource": "*"
}
]
}
}
}
So I need a definition for the policy InstanceThatCanManageItself (which needs to be defined ahead of time by a user with full admin permissions). Ideally, it would look something like:
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"${ec2:SourceInstanceARN}"
]
}
But it says this policy isn't valid because the policy variable ec2:SourceInstanceARN isn't in the format of a valid ARN. I've tried using tags on the EC2 instance and adding Conditions to the policy, but it doesn't seem to work when the condition is dynamic, like this:
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/role" : "${aws:userid}"
}
}
}
in the above, I'm dynamically adding a tag to the launched EC2 instance with the format "RoleId:InstanceId" as defined for the value specified for {aws:userid}, based on the description here: http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html. This approach validates, but doesn't work...either because it's dynamic...or because the action types aren't supports for the ResourceTag context key maybe...
Is there any way to accomplish this?
Thanks.
Resource tag-based authorizations will work only for certain operations. See, for example: EC2 Supported IAM actions. For example, all Describe operations are not supported and would have to be permissioned via a separate policy statement.
As an example of operations that support resource tags, attaching/detaching volumes (see same link above for supported operations and their requirements), so the following policy would work:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ec2:ResourceTag/policyuser": "${aws:userid}"
}
}
}
]
}
, provided both the volume and ec2 instance are tagged with tag 'policyuser' and value equal to role-id:ec2-instance-id (see IAM User Guide Reference Policy Variables), where role-id is the unique identifier of the role, obtained via e.g.
aws iam get-role --role-name rolename
I have a AWS S3 already associated with all the instances for read privileges to all S3 buckets. Now I need to add a policy to the roles for write privileges(Put object) so that a few of these instances can have write permissions to certain folders in the S3. Is there any way to achieve it through instance tag(better option for me) or instance id.
I tried adding an IAM policy but when I set the condition, my instances are not getting the required privileges.
The IAM policy I used is:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1456567757624",
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::testbucket/testfolder1/*",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:ec2:eu-west-1:<accountno>:instance/<instanceid1>"
}
}
},
{
"Sid": "Stmt1456567757625",
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::testbucket/testfolder2/*",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:ec2:eu-west-1:<accountno>:instance/<instanceid2>"
}
}
}
]
}
Here's an alternative, based on hints given in Granting access to S3 resources based on role name...
Instead of using aws:SourceArn, use aws:userid!
The Request Information That You Can Use for Policy Variables documentation has a table showing various values of aws:userid including:
For Role assigned to an Amazon EC2 instance, it is set to role-id:ec2-instance-id
Therefore, you could use the Role ID of the role that is used to launch the Amazon EC2 instance to permit access OR the Instance ID.
For example, this one is based on a Role ID:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SID123",
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"aws:userid": [
"AROAIIPEUJOUGITIU5BB6*"
]
}
}
}
]
}
Of course, if you are going to assign permission based on a Role ID, then you can just as easily grant permissions within the Role itself.
This one is based on an Instance ID:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SID123",
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"aws:userid": [
"*:i-03c9a5f3fae4b630a"
]
}
}
}
]
}
The Instance ID will remain with the instance, but a new one will be assigned if a new instance is launched, even from the same Amazon Machine Image (AMI).
The IAM Policy Elements Reference documentation says:
aws:SourceArn – To check the source of the request, using the Amazon Resource Name (ARN) of the source. (This value is available for only some services.)
However, the documentation does not state which services can use it.
There are examples available for its use with SQS and SNS, with a sourceARN of an Amazon S3 bucket and also using sourceARN with Lambda. However, it does not appear to be supported with Amazon EC2.
I have one S3 bucket in one AWS account (say arn:aws:s3:::my-test-bucket), that needs to be accessed by a IAM group that is defined in another AWS account (say arn:aws:iam::1111222333444:group/mygroup). The following access policy refuses to save, and tells that arn:aws:s3:::my-test-bucket is an invalid principal.
{
"Statement": [
{
"Action": [
"s3:ListBucket",
"s3:PutObject",
"s3:List*",
"s3:Get*"
],
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::1111222333444:group/mygroup"
},
"Resource": [
"arn:aws:s3:::my-test-bucket",
"arn:aws:s3:::my-test-bucket/*"
],
"Sid": "allow-put-for-dedicated-group"
}
],
}
I have tested by replacing the group with one of the users of the other account and this works:
{
"Statement": [
{
"Action": [
"s3:ListBucket",
"s3:PutObject",
"s3:List*",
"s3:Get*"
],
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::1111222333444:user/me"
},
"Resource": [
"arn:aws:s3:::my-test-bucket",
"arn:aws:s3:::my-test-bucket/*"
],
"Sid": "allow-put-for-dedicated-user"
}
],
}
The group is existing, I do not understand why it says it is an invalid principal. In fact it does not accept any group of my other account.
Does anyone have an explanation (and possibly a solution) to this behaviour?
Thanks in advance,
Cheers
IAM groups are not valid principals in S3 bucket policies. See this AWS forum post and this SO post for more discussion.
Here's one idea: create an IAM role (for example cross-account-s3) in account #1 (the account with the S3 bucket). That role should have a policy that allows the appropriate S3 bucket access and it should have a trust relationship that says account #2 is trusted for sts:AssumeRole. Then in account #2, delegate permission to assume the cross-account-s3 role to the relevant IAM group. This requires you to trust the IAM admins in the 2nd account to not allow the wrong users to assume the cross-account-s3 role.
As jarmod said, IAM groups are not valid principles. Also jarmod's solution will work. However it is possible to reference the role that is assumed in the S3 bucket policy. This allows you to deny actions unless they are performed by that role, which then provides the visibility of who has access that you wanted or could be used to further limit the access provided. The role reference is via the Role ID, which can be obtained by the following AWS CLI command: aws iam get-role --role-name ROLE_NAME --profile PROFILE_NAME, where ROLE_NAME is the name of the role created with sts:AssumeRole and PROFILE_NAME is the AWS profile setup to access the role.
Something like the following could then be used for the S3 bucket policy:
{
"Statement": [
{
"Action": [
"s3:ListBucket",
"s3:PutObject",
"s3:List*",
"s3:Get*"
],
"Effect": "Deny",
"Principal": "*"
"Resource": [
"arn:aws:s3:::my-test-bucket",
"arn:aws:s3:::my-test-bucket/*"
],
"Sid": "deny-put-for-anyone-but-dedicated-role",
"Condition": {
"StringNotLike": {
"aws:userId": [
"ROLE_ID:*"
]
}
}
}
],
}
More details about this can be found in this blog post, which includes using userId to limit access to a user.