I have a policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1429817158000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"arn:aws:ec2:*"
]
}
]
}
That is attached to a group. That group has one user. When I log in to myloginthing.signin.aws.amazon.com with that user's credentials I can't do anything related to EC2. It gives me messages such as "You are not authorized to describe Running Instances" for every action on the page.
the IAM Policy Simulator tells me any action is denied because
Implicitly denied (no matching statements found).
What am I missing?
This actually took me a while to figure out.
It turns out that you have to match each action (in your example, ec2:*) with a set of allowable resources (in your example, arn:aws:ec2:*).
The problem is that not every action has the same set of allowable resources - so while you can use a number of different resources for RunInstances, DescribeInstances ONLY supports *.
The whole list is available here
(Note: Link is posted because a) the list is very large, and b) it will probably change significantly over time.
It's actually fine to use ec2:* as Allow Action, but "arn:aws:ec2:*" is an invalid Amazon Resource Name.
Replace "arn:aws:ec2:*" with "arn:aws:ec2:::*" or just "*" should work.
See Amazon Resource Names (ARNs) and AWS Service Namespaces
You have to fill out all Resources:
arn:aws:ec2:*::image/*
arn:aws:ec2:*::snapshot/*
arn:aws:ec2:*:*:subnet/*
arn:aws:ec2:*:*:network-interface/*
arn:aws:ec2:*:*:security-group/*
arn:aws:ec2:*:*:volume/*
arn:aws:ec2:*:*:instance/*
arn:aws:ec2:*:*:network-interface/*
arn:aws:ec2:*:*:key-pair/*
Related
I'm facing some very weird issues when it comes to policies and managed instances. For example, one of my users is getting this error:
User: arn:aws:iam::708332864XX:user/XXXX is not authorized to perform: ssm:StartSession on resource: arn:aws:ssm:us-east-2:708332864XX:managed-instance/mi-055c2be5596fXXXXX
However, when looking at the policies, I don't have the ability to select a managed-instance as a resource:
If I try to just simply replace instance with managed-instance, then it says the ARN is invalid:
How would I give a user ssm:StartSession permission on managed instances then in this case? The following policy does nothing:
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-2:708332864587:managed-instance/*"
]
}
Apparently this doesn't do anything:
Notice how the managed instance ARN is for the arn:aws:ssm namespace:
arn:aws:ssm:us-east-2:708332864XX:managed-instance/mi-055c2be5596fXXXXX
You are trying to add permission for the arn:aws:ec2 namespace, which is why it isn't working.
TLDR; I would suggest to use the instance ARN instead. I would also verify that your role have access to all documents or at least to SSM-SessionManagerRunShell.
The long explanation:
If you read about StartSession in https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html you can learn that
for StartSession you have in the Resrouce column three different Resource types
Actions
Description
Access Level
Resource
StartSession
Grants permission to initiate a connection to a specified target for a Session Manager session
write
document instance task
Each of them has a different ARN structure:
document - arn:${Partition}:ssm:${Region}:${Account}:document/${DocumentName}
instance - arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId}
task - arn:${Partition}:ecs:${Region}:${Account}:task/${TaskId}
You can put any other ARNs in the rule, but they will have no effect. But in one they or other the user need access to all the required resources.
For example (mentioned in the other answer as well): In your question you have
aws:arn:ec2:.....:managed-instance with quote: "If I try to just simply replace instance with managed-instance, then it says the ARN is invalid". Yes, because it is. You cannot just combine the parts of ARNs randomly. Valid ARNs are only the documented ones: https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html
When you describe your "managed instance" you should see in it an id of an EC2 instance. This is the only instance which does exist. The ssm "managed instance" is a structure which stores only the ssm-related data for that particular EC2 instance.
`
If you read the example policy in the AWS documentation for StartSession you see there:
https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-restrict-access-quickstart.html
So you you need to figure out how to get the ec2 instance id from the managed instance id like for example with
https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:region:987654321098:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:region:account-id:document/SSM-SessionManagerRunShell"
],
"Condition": {
"BoolIfExists": {
"ssm:SessionDocumentAccessCheck": "true"
}
}
},
--cut--
Keep in mind that in AWS you may not be able to limit access per resource level for all services. That's especially for newer services. Or you may not be able to do it easily. For example you can create a lambda function which will start your ec2 instance and will create a policy for it (I don't say that you should do it that way, but it is possible).
Sometimes you can use conditions or you can use PassRole/AssumeRole mechanism to allow access to the resource by a mechanism which is outside of the IAM service. You may need to be creative and/or sometimes compromise.
I am trying to use the AWS IAM Policy simulator however I can't figure out one thing, I didn't find a clear answer in the documentation.
When I simulate a policy:
{
"Version": "2010-10-17",
"Statement": [
{
"Sid": "MyCoolID",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "*"
}]}
if I don't specify a region in the Resource field, is the simulator going to check all the regions? and if there is only one region where I can't ec2:CreateTags, then the simulator will fail? I will get Implicit Deny even though in most of the regions I can create the tags?
If so, how do I simulate something like "return true if there is at least one region where you can ec2**:CreateTags**"
If you have specified region condition in the policy then same can be simulated by setting region name in Global settings and then run the simulation. it will evaluate access only for that particular region
if I don't specify a region then simulator is going to check all the regions
We've been using a template for bucket policies that worked well until we tried to enable replication. The first thing in the policy is a deny statement that has exceptions for a specific vpce, and three IP network ranges. The deny statement is followed by some allow statements. This worked well. When we tried to configure replication, we get replication failed status for any object added or updated. So we added the IAM role created for this replication to the deny exceptions and also to the allow statements as a principal. This still cause replication failure. We know the issue is the policy because removing the policy results in replication completing normally. Here's the format of the deny statement...
"Statement": [
{
"Sid": "Stmt1587152999999",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"<Bucket ARN>",
"<Bucket ARN>/*"
],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"x.x.x.x/xx",
"x.x.x.x/xx",
"x.x.x.x/xx"
]
},
"StringNotEquals": {
"aws:SourceVpce": "<VPCE ID>"
},
"ArnNotEquals": {
"aws:SourceArn": "<IAM role created for replication>"
}
}
},
Is the source arn of the IAM role used for replication the correct way to exclude it from the deny statement? Is there another approach to limit access while still allowing replication?
Deny statements are always difficult. They often end up denying more than expected.
I think the above statement is saying:
Access to this S3 bucket is denied if:
You aren't coming from one of these IP addresses, AND
You aren't coming through that VPC Endpoint, AND
You aren't using that IAM Role
This should effectively be saying "Don't deny if any of the above are True" (that is, they are using one of the IPs, OR the VPC Endpoint OR the IAM Role).
See: Creating a condition with multiple keys or values - AWS Identity and Access Management
This means that your statement should be correct, but you report having problems. I can't see an immediate problem with what you are doing, but try starting by only having the IAM Role condition, test whether it is working correctly, then add the other conditions one-at-a-time to identify the cause of the conflict.
The issue with my policy was in the Role ARN.
I used "aws:SourceArn" but should have used " "aws:PrincipalArn"
I'm pretty sure I got SourceArn from the policy generator. I ended up opening a case and after a few iterations with support I got the "aws:PrincipalArn". That worked!
Is it possible to create a sub-account or sub-user that is limited in what he can see and/or do in AWS based on tags for example?
I have tried using policies, but for instances this wouldn't work, because you can't limit it on a resource level.
This makes it that either they can controll and see everything, or nothing at all.
is there anything that I have missed?
The question scope just too wide. Please study the IAM Guides and play around with IAM policy generator condition.
Even playing around with ARN that allow wildcard, you still need to define some explicit prefix/suffix for those wildcard values. For EC2, you need to understand EC2 resource ARN and possible need to mix with "Condition" to add restriction.
Here is an example of using policy generator for a policies that only allow run,start and stop instance, and it restrict to EC2 with resource tag serverX. When you attach this policy to the user, they can only do the following task. You may need to add further condition to make sure the user doesn't see instances belongs to others, by enforcing the tag name creation yourself.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1462794515000",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Condition": {
"StringLike": {
"ec2:ResourceTag/Name": "serverX"
}
},
"Resource": [
"arn:aws:ec2::1234567890:instance/*"
]
}
]
}
You can play around with AWS policy Simulator. Another good reference is AWS inline policies and managed policies
I have set a policy for an AWS user as such:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect":"Allow",
"Action": "ec2:Describe*",
"Resource":"*"
}
]
}
The intent was to allow a user with this policy to view EC2 instances on the console, but not to actually do anything with them. The problem is, once this policy is applied, the user can start, stop, terminate and launch new instances even though none of those permissions are addressed in the above policy, AFAIK.
Why is this happening with the above policy, and what can I do to prevent it (i.e. achieve the "view but not touch" result I'm after)?
Amazon IAM policies are Deny by default, which is not identical to Explicit Deny, see The Difference Between Denying by Default and Explicit Deny for details.
Accordingly, the observed behavior wouldn't be possible by default, so there must be another policy in place for this user explicitly granting the undesired actions like ec2:RunInstances. You have the following options to remedy this:
Identify/Remove Explicit Allow
You can analyze which policy grants the undesired actions by means of the excellent new AWS Identity and Access Management Policy Simulator, which is utterly helpful for issues like this.
Add Explicit Deny
You can add an explicit deny for those actions the user shouldn't be able to perform , e.g.:
{
"Statement": [
{
"Action": [
"ec2:RebootInstances",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Effect": "Deny",
"Resource": "*"
}
]
}
Please note that the latter would still allow quite some other EC2 actions that you might not want, so a more complete approach to explicitly deny all but the desired ones would be to facilitate the NotAction:
The NotAction element lets you specify an exception to a list of actions. For example, you can use NotAction to let users use only the Amazon SQS SendMessage action, without having to list all the actions that the user is not allowed to perform. Using NotAction can sometimes result in shorter policies than using an Action element and listing many actions.
Warning: Please be aware that it is easy to restrict more than you intend and even lock yourself out when using NotAction for an explicit Deny - always make sure the Resource statement is only targeting the desired resources. For example, simply using the common wildcard * instead of a more specific resource selector like arn:aws:ec2:*:*:* boils down to 'deny all but these actions for every service' - for the example at hand this would include the ability to delete the erroneous policy again! This is best avoided by carefully simulating the policy upfront.
A resp. policy might look like this:
{
"Statement": [
{
"NotAction": [
"ec2:Describe*"
],
"Effect": "Deny",
"Resource": "arn:aws:ec2:*:*:*"
}
]
}
For user3086014, create a policy similar to the one below:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect":"Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RebootInstances"
],
"Resource":[
"arn:aws:ec2:us-west-1:0123456789012:instance/i-ffffffff"
]
}
]
}
Change the actions to the ones you want to allow your user to perform. Change the resource to identify your instance - i.e. change the account ID (I've written 0123456789012 above) and the instance ID (I've written i-ffffffff above). Then apply that policy to your user. If you want to allow use of two instances, add a second ARN with a comma-delimiter between the ARNs (as is required JSON form).
Please next time make a separate question. It's awkward having questions-answers in the comments themselves. Thanks!