I want a user to be able to login to an aws account and start and stop ONE specific ec2-instance.
So far I found out that ec2 describe only works with a catch -all star "*" in the resources.
The user can login, sees all the instances BUT he can't start or stop the instance because a permission denied error shows up :(
This is my policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "TheseActionsDontSupportResourceLevelPermissions",
"Effect": "Allow",
"Action": [
"ec2:Describe*"
],
"Resource": "*"
},
{
"Sid": "TheseActionsSupportResourceLevelPermissions",
"Effect": "Allow",
"Action": [
"ec2:TerminateInstances",
"ec2:StopInstances",
"ec2:StartInstances"
],
"Resource": "arn:aws:ec2:eu-central-1a:MY_ACCOUNT_ID:instance/MY_INSTANCE_ID"
}
]
}
The answer is, you can't.
The ec2:Stopinstances, ec2:StartInstances and ec2:TerminateInstances do indeed support resource level permissions, but not for the condition key of instance id. They support the condition keys:
ec2:AvailabilityZone
ec2:EbsOptimized
ec2:InstanceProfile
ec2:InstanceType
ec2:PlacementGroup
ec2:Region
ec2:ResourceTag/tag-key
ec2:RootDeviceType
ec2:Tenancy
This is highlighted in the documentation here. (Search for the API calls on the page)
The only potentially useful condition key is ec2:ResourceTag/tag-key. You could add a resource tag on the particular instance and allow the user permission to call these 3 API calls on instances with that tag.
However, unless you had the API calls related to tags denied, there would be nothing to stop the user adding the tag to another instance, and performing the API calls on that instance too. You'd need to establish if denying tagging suits your situation.
Hope this helps.
Let me provide a working example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RebootInstances"
],
"Resource": [
"arn:aws:ec2:ap-south-1:222222222222:instance/i-02222222222222ddb",
"arn:aws:ec2:ap-south-1:222222222222:security-group/sg-022222222abc"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Name": "my.dev-server.com"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeInstanceAttribute",
"ec2:DescribeNetworkAcls",
"ec2:DescribeSecurityGroups",
"ec2:ModifySecurityGroupRules",
"ec2:DescribeInstanceStatus"
],
"Resource": "*"
}
]
}
I found this link also useful in understanding this answer.
Related
I am trying to give lambda execution access to select members within a group. Users are authenticated via PingFederate. I am having issue granting this selective access to federated user.
I have a custom IAM policy (allow-lambda-invocation-selective) attached to this role. Although the policy seems to pass validation and policy simulation shows access is allowed, when I try to execute the lambda function I get message
Calling the invoke API action failed with this message: User:arn:aws:sts::123456789012:assumed-role/role-for-grp-l2/myuser1234 is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123456789012:function:my-lambda-function
Here is my policy: allow-lambda-invocation-selective
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"lambda:InvokeAsync",
"lambda:ListVersionsByFunction",
"lambda:GetFunction",
"lambda:ListAliases"
],
"Resource": "arn:aws:lambda:*:123456789012:function:my-lambda-function",
"Condition": {
"StringEquals": {
"aws:userid": "arn:aws:sts::123456789012:assumed-role/role-for-grp-l2/myuser1234"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"lambda:ListFunctions",
"lambda:ListEventSourceMappings",
"lambda:ListLayers",
"lambda:ListLayerVersions"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:userid": "arn:aws:sts::123456789012:assumed-role/role-for-grp-l2/myuser1234"
}
}
}
]
}
Am i missing something?
I'm trying to understand your problem. Correct me if I made a wrong supposition.
Every group/user already have its own role.
When you authenticate your users, they have their assumed role. myuser1234, when authenticated, will receive arn:aws:sts::123456789012:assumed-role/role-for-grp-l2/myuser1234 role, right? Is it possible to create one role for each group and remove the conditions property (check item 2 explaining why)?
// role-for-grp-l2
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"lambda:InvokeAsync",
"lambda:ListVersionsByFunction",
"lambda:GetFunction",
"lambda:ListAliases"
],
"Resource": "arn:aws:lambda:*:123456789012:function:my-lambda-function"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"lambda:ListFunctions",
"lambda:ListEventSourceMappings",
"lambda:ListLayers",
"lambda:ListLayerVersions"
],
"Resource": "*"
}
]
}
The problem with aws:userid
Reading the docs about the key aws:userid we can find this key has the value given by role id:caller-specified-role-name,
where role id is the unique id of the role and the caller-specified-role-name is specified by the RoleSessionName parameter passed to the AssumeRole request.
So aws:userid has value like AIDAJQABLZS4A3QDU576Q:SomeNameYouGive. Because this, your condition never match arn:aws:sts::123456789012:assumed-role/role-for-grp-l2/myuser1234 and then user cannot assume that actions.
Using conditions another way
Assuming RoleSessionName is the user name, you can use conditions this way:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"lambda:InvokeAsync",
"lambda:ListVersionsByFunction",
"lambda:GetFunction",
"lambda:ListAliases"
],
"Resource": "arn:aws:lambda:*:123456789012:function:my-lambda-function",
"Condition": {
"StringLike": {
"aws:userid": "*:myuser1234"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"lambda:ListFunctions",
"lambda:ListEventSourceMappings",
"lambda:ListLayers",
"lambda:ListLayerVersions"
],
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userid": "*:myuser1234"
}
}
}
]
}
if you prefer, you may remove * wildcard getting role id using AWS CLI with the command:
aws iam get-role --role-name ROLE_NAME
and changing condition as follows:
"Condition": {
"StringEquals": {
"aws:userid": "ROLE_ID:myuser1234"
}
}
I have an AWS account and have few folks added to a group, called "sales" and this group has "AmazonEC2FullAccess" IAM role assigned. My understanding is that the "sales" group is able to view all EC2 resources, create new instances and terminate any old ones.
I want to restrict this group to only view and create instances, and DONOT be able to remove any instances, How can i edit/change this AmazonEC2FullAccess role to disable the termination process of instances?
To answer your question directly, you can't change AmazonEC2FullAccess since it's a built-in policy. But you can explicitly deny EC2 instance termination by adding inline policy to this group like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1508489064000",
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1:ACCOUNT_ID:instance/*"
]
}
]
}
Assigning AmazonEC2FullAccess to sales people is a horrible idea.
I suggest you to use the minimum privilege method(provide access permission only for what is needed).
Attach the below Inline Custom policy to the Sales Group under Permissions tab.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "elasticloadbalancing:Describe*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:ListMetrics",
"cloudwatch:GetMetricStatistics",
"cloudwatch:Describe*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "autoscaling:Describe*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateImage",
"ec2:CreateKeyPair",
"ec2:CreateNetworkInterface",
"ec2:CreatePlacementGroup",
"ec2:CreateSecurityGroup",
"ec2:CreateSnapshot",
"ec2:CreateVolume",
"ec2:ModifyHosts",
"ec2:AllocateAddress",
"ec2:AllocateHosts",
"ec2:AssignIpv6Addresses",
"ec2:AssignPrivateIpAddresses",
"ec2:AssociateAddress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:AttachVolume",
"ec2:CopyImage",
"ec2:CopySnapshot",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:RebootInstances",
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": "*"
}
]
}
This will allow them to perform basic operations with ec2 instances like creating instance, create security group for that instance, tags etc, But restricts them from performing delete operations. Basically, this policy is an extension of AmazonEC2ReadOnlyAccess policy.
For example I am admin of AWS console and there is a user X to whom I need to share some test lambda functions which are created by me, so that he can test in test lambda functions instead of messing with production lambda functions and also I do not want X to see access my lambda functions.
But when I create a test user and login into his console, I am not able to see any of the admin functions in his console, below is my custom policy attached to the test user
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"cognito-identity:ListIdentityPools",
"cognito-sync:GetCognitoEvents",
"cognito-sync:SetCognitoEvents",
"dynamodb:*",
"events:*",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:PassRole",
"lambda:*",
"logs:*",
"kms:ListAliases"
],
"Resource": "*"
}
]
}
but the same thing does not happened with s3 buckets, I have attached one more policy to the test user for accessing only test s3 bucket, which is working well, below is the policy description.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::test"
]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::test/*"
]
}
]
}
I made a silly mistake, some one also might encounter it, so I would like to mention it, I have selected a different region in my aws console in testuser account, so it is not showing up, when I select back the region where I have created the lmabda functions it started showing up all the lambda functions.
I am trying to create an IAM Policy in Amazon AWS which will allow access to view or edit/modify a single security group. I have followed the AWS documentation, but am unsuccessfully able to make this policy work. The policy created is below:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt123456789123",
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:*"
],
"Resource": [
"arn:aws:ec2:us-east-1:000000000000:security-group/sg-a123a1a1"
]
}
]
}
Yes, I do realize that I have a redundant action, but I noticed you are able to specify Describe Security Group, but no option for Modify; therefore "*" was my only option; Thankfully, the resource should allow me to restrict this action to a single security group.
It is partly possible, please see https://serverfault.com/questions/575487/use-iam-to-allow-user-to-edit-aws-ec2-security-groups, it's actually possible to constrain editing to just one group, but I didn't get listing of just one group to work:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1413232782000",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstanceAttribute",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstances",
"ec2:DescribeNetworkAcls",
"ec2:DescribeSecurityGroups"
],
"Resource": [
"*"
]
},
{
"Sid": "Stmt1413232782001",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"arn:aws:ec2:us-east-1:<accountid>:security-group/sg-<id>"
]
}
]
}
Here is what I managed to put together and it works great!
Create the following policy and add it to a User Group or make one:
Update the items that are in {BRACKETS}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:DeleteSecurityGroup"
],
"Resource": "arn:aws:{REGION}:{ACCOUNT_NUMBER}:security-group/{NSG-ID}",
"Condition": {
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:{REGION}:{ACCOUNT_NUMBER}:vpc/{VPC-ID}"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroupReferences",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeStaleSecurityGroups"
],
"Resource": "*"
}
]
}
Well, it looks like the code formatter is not working right with this, but you can read the references here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html
Thanks!
You can add new rule to security group like
aws ec2 authorize-security-group-ingress --group-name MySecurityGroup --protocol tcp --port 3389 --cidr 203.0.113.0/24
And also change the tags as well.
I am trying to copy some files from my EC2 instance to S3 and using the following command
s3cmd put datafile s3://mybucket/datafile
and get the following error
ERROR: S3 error: Access Denied
I have the following IAM policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"s3:ListAllMyBuckets",
"s3:ListBucket"
],
"Resource": "*"
}
]
}
S3 Bucket Policy for mybucket
{
"Version": "2008-10-17",
"Id": "backupPolicy",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxx:user/xxxx"
},
"Action": [
"s3:ListBucket",
"s3:PutObjectAcl",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::mybucket/*",
"arn:aws:s3:::mybucket"
]
}
]
}
I am not sure what I am doing wrong. s3cmd ls s3://mybucket works fine.
I tried searching on SO for this issue, but all the posts basically ask you to add the IAM policy, which I already have.
I think you need to have write permissions for IAM in addition to List:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"s3:ListAllMyBuckets",
"s3:ListBucket"
],
"Resource": "*"
},
{
"Sid": "Stmt1406613887001",
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::mybucket",
"arn:aws:s3:::mybucket/*"
]
}
]
}
The user IAM policy needs the permissions to read/write, not (just) the bucket. AWS will always apply the more restrictive policies, and defaults to an implicit "deny".
I've found bucket policies are better suited for public access (ie. serving assets to the world), not restricting the principal. When you start combining bucket + user policies complications arise and it's often much easier to manage the user end.