I am trying to have my lambda full access restricted to a particular region.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"dynamodb:*",
"events:*",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:PassRole",
"lambda:*",
"logs:*",
"s3:*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
}
]
}
This is my policy.
but currently, it is not working user is still able to access lambda and it's full access in another region.
what am I missing here?
Your IAM user(s) are probably allowed to perform your actions in different regions, because your policy is Allow only and they have other policies that allow unrestricted access.
To overcome the issue you can use Deny statement in the policy, as explained in AWS: Denies access to AWS based on the requested Region. Deny always wins, which means that the policy will have precedence over any allows.
So your policy, based on the AWS docs linked, could be:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"cloudwatch:*",
"dynamodb:*",
"events:*",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:PassRole",
"lambda:*",
"logs:*",
"s3:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
}
]
}
Note, that in the AWS docs they also use NotAction, instead of Action. So you have to take into account what you wish your users to be able to do, or not do. But in your case, I think Action is fine.
Related
I'm trying to create an AWS IAM Policy that gives access to everything that a Power User has (arn:aws:iam::aws:policy/PowerUserAccess) but only in a specific region.
I started with the existing Power User policy and found this article: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_region.html
So I added the "condition" to the Power User Policy and the result is:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": "*",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Condition": {
"StringEquals": {
"ec2:Region": "us-east-2"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
This does not seem to be working as I can create EC2 instances only in the specified region... but other services are not available:
When you use the ec2:Region in the Condition key, that's EC2 specific
You'll want to try the aws:RequestedRegion for the condition key.
Beware though,
Some global services, such as IAM, have a single endpoint. Because this endpoint is physically located in the US East (N. Virginia) Region, IAM calls are always made to the us-east-1 Region
Give it a try with
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": "*",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-2"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
I just tried adding tags to some buckets and then I created an inline IAM role policy that'd give that role access to the S3 buckets however that didn't work. I tried both iam:ResourceTag/tagName and s3:ResourceTag/tagName as conditionals but neither worked.
As everything looked just fine I started thinking that AWS might not have implemented this yet for S3. Is that the case? I tried reviewing documentation and indeed I didn't find anything about this use of tags working with S3.
For example the role HumanResources should have to all buckets tagged with HR, Recruitment etc. but no other buckets.
In looking at Actions, Resources, and Condition Keys for Amazon S3 - AWS Identity and Access Management, there does not appear to be the ability to specify a Bucket Tag in an IAM Policy.
One alternative is to use a wildcard in a bucket name. For example, you could grant permission to access:
acme-hr-1
You could grant permissions based on a bucket name of acme-hr-*.
Yes you can but you will need do on each S3 Resource Policy.
Here is an S3 Policy to grant access to the bucket for only IAM users and roles with a Tag department set to "hr".
To ensure HR employee only have access to these buckets you will need to remove all S3 access from their IAM user/role access polices.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyObjectOthers",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts",
"s3:DeleteObject*",
"s3:PutObject*",
"s3:GetObject*",
"s3:RestoreObject*"
],
"Resource": [
"arn:aws:s3:::BUCKET_NAME/*"
],
"Condition": {
"StringNotLike": {
"aws:PrincipalTag/department": [
"hr"
]
}
}
},
{
"Sid": "DenyListOthers",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:ListBucket*"
],
"Resource": [
"arn:aws:s3:::BUCKET_NAME"
],
"Condition": {
"StringNotLike": {
"aws:PrincipalTag/department": [
"hr"
]
}
}
},
{
"Sid": "AllowObject",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AWS_ACCOUNT_NUMBER:root"
},
"Action": [
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts",
"s3:DeleteObject*",
"s3:PutObject*",
"s3:GetObject*",
"s3:RestoreObject*"
],
"Resource": [
"arn:aws:s3:::BUCKET_NAME/*"
],
"Condition": {
"StringLike": {
"aws:PrincipalTag/department": [
"hr"
]
}
}
},
{
"Sid": "AllowList",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AWS_ACCOUNT_NUMBER:root"
},
"Action": [
"s3:ListBucket*"
],
"Resource": [
"arn:aws:s3:::BUCKET_NAME"
],
"Condition": {
"StringLike": {
"aws:PrincipalTag/department": [
"hr"
]
}
}
}
]
}
Previous Wrong Answer
From: IAM Policy Elements: Variables and Tags - AWS Identity and Access Management
"Resource": ["arn:aws:s3:::bucket/${aws:PrincipalTag/department}"]
Also make sure to include the version at 2012-10-17.
I have a Elastic Beanstalk application running on an EC2 instance, currently I have given admin privileges to all my co-workers. However now I want to add other environments and web applications that I don't want my co-workers to have access to. I've been looking at Resource-Level Permissions but I'm pulling my hair out trying to get it to work. Sometimes It works intermittently and I'm looking for advice on how I can achieve this from anyone with previous experience.
In a nutshell: I have [Application A] that I want users to have access to. I also have [Application B] and [Application C] that I want to restrict access to so only I can see and make changes to it.
Here is my current IAM Policy JSON;
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:*",
"ecr:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"sns:*",
"cloudformation:*",
"dynamodb:*",
"rds:*",
"sqs:*",
"iam:GetPolicyVersion",
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:ListInstanceProfiles",
"iam:ListRoles",
"iam:ListServerCertificates",
"acm:DescribeCertificate",
"acm:ListCertificates",
"codebuild:CreateProject",
"codebuild:DeleteProject",
"codebuild:BatchGetBuilds",
"codebuild:StartBuild"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"arn:aws:ec2:myregion:myaccountid:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Name":"mytag"
}
}
},
{
"Effect": "Allow",
"Action": [
"elasticbeanstalk:*"
],
"Resource": [
"arn:aws:elasticbeanstalk:myregion:myaccountid:environment/myapp/myenv"
],
"Condition": {}
}
]
}
Derived from here. I would really appreciate if someone with more experience with IAM policies could identify what I'm doing wrong and how to do it properly & If there is a simpler way of doing this I would love to hear it also!
Thanks!
Since your co-workers already have admin access, you need a Deny policy.
The following policy explicitly denies access to all Amazon EB resources other than the listed resources
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "elasticbeanstalk:*",
"NotResource": [
"<Application A ARN>"
]
}
}
I'm following the tutorial found here to use an on-premise server with CodeDeploy. I'm a little confused with the first couple of steps. When I'm creating a role for the on-premise server to assume, what should I choose as the service that will use this role (in the console)? I do understand what policy the role should have, allowing actions s3:Get and s3:List for all resources. To provide additional info, I want to use the aws-codedeploy-session-helper tool to periodically refresh the session credentials for me, and the policy for the IAM user this tool uses is as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:CreateUser",
"iam:DeleteAccessKey",
"iam:DeleteUser",
"iam:DeleteUserPolicy",
"iam:ListAccessKeys",
"iam:ListUserPolicies",
"iam:PutUserPolicy",
"iam:GetUser",
"iam:AddRoleToInstanceProfile",
"iam:CreateInstanceProfile",
"iam:CreateRole",
"iam:DeleteInstanceProfile",
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:GetInstanceProfile",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListInstanceProfilesForRole",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:PassRole",
"iam:PutRolePolicy",
"iam:RemoveRoleFromInstanceProfile",
"autoscaling:*",
"codedeploy:*",
"ec2:*",
"lambda:*",
"elasticloadbalancing:*",
"s3:*"
],
"Resource": "*"
}
]
}
You would need to allow the on-premise server to call the STS assume role API, so the service should "STS"
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<ACCOUNT-ID>:role/<ROLENAME>"
}
}
Then in the IAM Role, add a "Trust" Policy for the server.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT-ID>:user/<USER-NAME>"
},
"Action": "sts:AssumeRole"
}
]
}
I am trying to make a IAM policy to restrict user access to all the instances in a specific VPC. Following policy I made but not working.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1450441260778",
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "arn:aws:ec2:region:Account_num:vpc/vpc-id"
}
]
}
I have filled the corresponding account_num and vpc-id in the policy.
You want to restrict the user access and you have used the allow attribute which will give permission to access the instance . Is that the desired behavior ?
If you really want to restrict try "Effect": "Deny" in same policy .
However if you want to give access to certain users here's how you can do it .
The following below policy works for me well in that case. I use it for the developers to restrict the access to start stop the instances . You can add as many permissions as you want in the second block .
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances*",
"ec2:StopInstances*"
],
"Resource": "arn:aws:ec2:ap-southeast-1:ACCOUNT_ID:instance/i-32ds2a29"
}
]
}
ap-southeast-1 is the region for my case .
To control an instance in a specific vpc you can simply use its id .There is no separate arn for vpc+instance_id instead you can use arn:aws:ec2:region:account-id:instance/instance-id as arn refer this .
Similarly you can use the same policy to restrict the users in specific vpc by using arn:aws:ec2:region:account-id:vpc/vpc-id as arn, adding Action ec2:* and deny in effect .
There are certain permissions that cant be applied to a specific resource. These permissions will show an error when you check the policy in IAM.
In order to restrict a user to a specific VPC and allow all EC2 actions, the following policy can help you in achieving that:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "NonResourceBasedReadOnlyPermissions",
"Action": [
"ec2:Describe*",
"ec2:CreateKeyPair",
"ec2:CreateSecurityGroup",
"iam:GetInstanceProfiles",
"iam:ListInstanceProfiles"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "IAMPassroleToInstance",
"Action": [
"iam:PassRole"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::123456789012:role/VPCLockDown"
},
{
"Sid": "AllowInstanceActions",
"Effect": "Allow",
"Action": [
"ec2:RebootInstances",
"ec2:StopInstances",
"ec2:TerminateInstances",
"ec2:StartInstances",
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
"Condition": {
"StringEquals": {
"ec2:InstanceProfile": "arn:aws:iam::123456789012:instance-profile/VPCLockDown"
}
}
},
{
"Sid": "EC2RunInstances",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
"Condition": {
"StringEquals": {
"ec2:InstanceProfile": "arn:aws:iam::123456789012:instance-profile/VPCLockDown"
}
}
},
{
"Sid": "EC2RunInstancesSubnet",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:123456789012:subnet/*",
"Condition": {
"StringEquals": {
"ec2:vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-7bcd371e"
}
}
},
{
"Sid": "RemainingRunInstancePermissions",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:volume/*",
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1::snapshot/*",
"arn:aws:ec2:us-east-1:123456789012:network-interface/*",
"arn:aws:ec2:us-east-1:123456789012:key-pair/*",
"arn:aws:ec2:us-east-1:123456789012:security-group/*"
]
},
{
"Sid": "EC2VpcNonresourceSpecificActions",
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkAcl",
"ec2:DeleteNetworkAclEntry",
"ec2:DeleteRoute",
"ec2:DeleteRouteTable",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:DeleteSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-7bcd371e"
}
}
}
]
}
In order to understand in detail what each statements are doing, I would recommend reading this blog from AWS. This policy, allows the user to:
Sign in to the AWS Management Console and go to the Amazon EC2 console.
Launch an EC2 instance as long as they:
Specify a subnet in the proper VPC.
Specify the allowed instance profiles.
Start/stop/reboot/terminate/attach volume/detach volume on an instance as long as they:
Specify an instance launched with the proper instance profiles.
Delete security groups, routes, route tables, network ACLs, and ACL entries as well as authorize and revoke security group ingress and egress rules, as long as they are in the proper VPC.