I am trying to write an IAM policy which will control access to EC2 instances. All EC2 instances will have a custom tag called username and only if the tag value matches the logged in user's user name, will that user have access to that EC2 instance. This is what I came up with:
{
"Version": "2012-10-12",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/username": "arn:aws:iam::account-number-without-hyphens:user/username1"
}
}
}
]
}
I am sure you see the problem here. I don't want to hard code the username value on the right hand side. I want to be able to get that information at runtime or policy evaluation time.
Is it possible to do so?
The IAM user can be referred to in policy documents by ${aws:username}.
There is a list of other IAM policy variables and their uses here:
http://docs.aws.amazon.com/IAM/latest/UserGuide/PolicyVariables.html
Related
I am planning to implement AssumeRole scenario so below is scenario
user will have ability to create/stop Ec2 instances but not terminate.
To terminate he has to assume role (role to be assumed Ec2FullAccess)
I have done the following
Create a user Test1 with permission to start/stop/launch Ec2 instance and have provided permission to assume role (EC2FullAccess) below is the Policy for user
{
"Version": "2012-10-17",
"Statement": [<br>
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "ec2:TerminateInstances",
"Resource": "*"
},
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::226904037275:role/EC2FullAccess"
}
]
}
Create a role in same account with name EC2FullAccess which would give permission to terminate Ec2 instance
Ec2FullAccess uses AmazonEC2FullAccess Permission Policy below is its Trust Policy
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Now when i login as IAM user Test1 and then click on switch role ,i provide below details
Account: 1234
Role: EC2FullAccess
When i click on Switch Role i get Below error
Invalid information in one or more fields. Check your information or contact your administrator.
What is that I am missing
You can create the Role this way:
Create Role
For Type of Trusted Entity, select Another AWS Account and enter the Account ID for the same account (it is displayed in the same menu as the 'Switch Role' command) -- This might seem odd, but it creates the correct principal in the Trust Policy.
Attach desired policies and Save
Then, use Switch Role.
By the way, assigning EC2FullAccess is probably overkill -- it gives permission to do anything in EC2, including deleting VPCs, deleting Amazon EBS volumes, changing network settings, etc. I suggest you create a specific policy that grants TerminateInstances permission, and possibly even reduce that down to specific instances (eg by tag or VPC).
I want to restrict access for a specific user to see just few EC2 instances. I created a new user in IAM Roles and I attached a new Policy to it. The content of that Policy is attached below. I tried to look over documentation and to do it myself like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": [
"arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/i-INSTANCE_ID1",
"arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/i-INSTANCE_ID2"
]
}
]
}
I placed my region,ACCOUNT_ID(the owner id, not of the new user created) and instance-id, but when I connect with that user and I go to list all Instances I got this An error occurred fetching instance data: You are not authorized to perform this operation..
After I placed the code in JSON editor, in Policy Review step I got this message:
This policy defines some actions, resources, or conditions that do not
provide permissions. To grant access, policies must have an action
that has an applicable resource or condition. For details, choose Show
remaining Learn more
The AWS documentation mention exactly the same configuration or these examples.
I assume you connect as that user in the console (but it would be the same with CLI) Here is what I think is happening:
To list all the instances, the console most probably calls the DescribeInstances API. As per the list of action/resources/tags that can be used in IAM policy, this API does not support the resource filter in IAM.
This means your user has no authorization to list instances and they will not be shown in the console. You can validate this theory by using the CLI to request the details of a specific instance id, if my hypothesis is correct, it will be authorized.
As DescribeInstances can not be restricted by resource or tags, I don't think it is possible to filter the instance list for a user.
To have the console working, you'll need to add the following statement in your IAM policy
"Statement": [
{ your existing statement },
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
}
]
Please report if I was right :-) The example you mentioned in your question shows exactly that : Resources = * on DescribeInstances and Resources specific InstanceId on other operations.
The previous answer is wrong, you can Conditionally allow access to ec2:DescribeInstances by tag names. It's an AWS best practice as well. Also explicitly deny access to the ec2:CreateTags and ec2:DeleteTags actions to prevent users from creating or deleting tags to take control of the instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/UserName": "${aws:username}"
}
}
},
{
"Effect": "Deny",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": "*"
}
]
}
DescribeInstances action does not support condition.
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html
Is it possible to create an IAM rule or an SCP (organization rule) to enforce MFA for all users in a certain group or with certain rights (e.g. administrators or power user)?
To the best of my knowledge you can attach a deny portion to any policy or create a deny policy and attach it to any group.
For example you have "Administrators" group that has many roles added as well as "MultifactorAuthForce" policy:
Example of "MultifactorAuthForce":
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllWithoutMFA",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
Update:
Just tested it on my account and the policy works. Created an account without MFA, added password and assigned to the group above. When logged as that user I was denied all actions on all resources. After, I added MFA to the user and logged in again. I was able to see the resources.
I have tried to limit access to a VPC without success. Maybe approaching the issue from the other side is a better idea, but I can't get that to work either.
I have tried:
Limit by tags as shown here:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/client": "<client>"
}
}
}
]
}
Limit by VPC as suggested here:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1508450090000",
"Effect": "Allow",
"Action": [
"ec2:Describe*"
],
"Resource": [
"arn:aws:ec2:<region>:<account>:subnet/*"
],
"Condition": {
"StringEquals": {
"ec2:Vpc": "arn:aws:ec2:<region>:<account>:vpc/<vpc_id>"
}
}
}
]
}
Both policies result in not even listing any instances, see screenshot.
This seems to be a very obvious and commonly needed policy to me.
Any help is appreciated.
According to the documentation: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html#readonlyvpciam
The following policy grants users permission to list your VPCs and
their components. They can't create, update, or delete them.
{
"Version": "2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":["ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeInternetGateways",
"ec2:DescribeEgressOnlyInternetGateways",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeNatGateways",
"ec2:DescribeCustomerGateways",
"ec2:DescribeVpnGateways",
"ec2:DescribeVpnConnections",
"ec2:DescribeRouteTables",
"ec2:DescribeAddresses",
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkAcls",
"ec2:DescribeDhcpOptions",
"ec2:DescribeTags",
"ec2:DescribeInstances"],
"Resource":"*"
}
]
}
Further, if you have multiple VPCs that you do not want them to even see, perhaps you should consider creating a sub-account with only the portion of your network that they should have visibility across:
Setup Consolidated Billing
As a first step, log into your AWS account and click the "Sign up for Consolidated Billing" button.
Create a new account
From a non-logged in browser, you will then want to sign up again to AWS again like this:
Give this new account the appropriate name for your client. Note the email address you signed up with.
Link the accounts
In your main account, head back to ConsolidatedBilling and click the Send a Request button. Provide the email address for your new sub-account.
You should receive an email to the email address for your new sub-account. Copy the activation link and paste it into your browser logged in to the sub-account.
Your accounts are now linked!
Create your clients VPC and enable the services that the client requires.
Next, you can create the VPC & services the client requires, and restrict their access via the policy above.
You cannot restrict Describe* calls in the manner you want.
Calls that create resources can be restricted (eg give permission to launch an instance in a particular VPC), but calls that list resources cannot be restricted.
If you require the ability to prevent certain users from listing resources, then you'll either need to build your own front-end that filters the information before presenting it to users, or use multiple AWS accounts since they are fully isolated from each other.
I have a cloudformation template up in an S3 bucket (the url follows the pattern but is not exactly equal to: https://s3.amazonaws.com/bucket-name/cloudform.yaml). I need to be able to access it from CLI for a bash script. I'd prefer that everybody in an organization (all in this single account) has access to this template but other people outside of the organization don't have access to the template. A bucket policy I've tried looks like:
{
"Version": "2012-10-17",
"Id": "Policy11111111",
"Statement": [
{
"Sid": "Stmt111111111",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::7777777777:root"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}
With this policy, I and a couple other people in my office are unable to access the url. Even when I'm logged in with the root account I'm getting Access Denied.
Also, this change (only setting Principal to *) makes the bucket accessible to anybody:
{
"Version": "2012-10-17",
"Id": "Policy11111111",
"Statement": [
{
"Sid": "Stmt111111111",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}
Obviously the signs point to my Principal field being misconfigured. 777777777 is the replacement for the Account ID I see under the My Account page.
So, do I need to worry about this on the IAM front? Considering that I am logged in as the root user, I'd guess I should have access to this as long as I put in a bucket policy. Any help would be much appreciated.
Short and sweet:
The bucket policy doesn't allow you to do what you want because of a wildcard limitation of the Principal element. Your best bet is to create an IAM group and put all IAM users into that group if they need access.
Long version:
Just to make it clear, any request to https://s3.amazonaws.com/bucket-name/cloudform.yaml MUST be signed and have the necessary authentication parameters or the request will be rejected with Access Denied. The only exception is if the bucket policy or the bucket ACL allows public access, but it doesn't sound like this is what you want.
When you say "everybody in an organization (all in this single account)" I assume you mean IAM users under the account who are accessing the file from the AWS console, or IAM users who are using some other code or tool (e.g. AWS CLI) to access the file.
So what it sounds like what you want is the ability to specify the Principal as
"Principal": {
"AWS": "arn:aws:iam::777777777777:user/*"
}
since that is what the pattern would be for any IAM user under the 777777777777 account id. Unfortunately this is not allowed because no wildcard is allowed in the Principal unless you use the catch-all wildcard "*". In other words "*" is allowed, but either "prefix*" or "*suffix" is not. (I wish AWS documented this better.)
You could specify every IAM user you have in the bucket policy like so:
"Principal": {
"AWS": [
"arn:aws:iam::777777777777:user/alice",
"arn:aws:iam::777777777777:user/bob",
"arn:aws:iam::777777777777:user/carl",
...
"arn:aws:iam::777777777777:user/zed",
}
But you probably don't want to update the policy for every new user.
It would be easiest to create an IAM group that grants access to that file. Then you would add all IAM users to that group. If you add new users then you'll have to manually add them to that group, so it is not as convenient as what you originally wanted.