I am reading up on creating IAM policies for EMR and am a little confused on the use of the Resource: section in the JSON declaration.
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fine-grained-cluster-access.html
For instance in the below example the use of * would imply all resources in the AWS account, but since the specific permission is elasticmapreduce:CreateEditor does that really just imply that it ends up only affecting the editor resource in EMR assuming the conditional block is satisfied?
In the below link there is a resource type definition that for the editor arn:${Partition}:elasticmapreduce:${Region}:${Account}:editor/${EditorId}.
Would resource:* essentially equal arn:${Partition}:elasticmapreduce:${Region}:${Account}:editor/*?
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html#amazonelasticmapreduce-studio
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/creatorUserId": "${aws:userid}"
}
}
}
]
}
Another area of confusion is that in this example below there is a specific resource type declared. Why isn't Resource:* used here? I see in my second link that the StartEditor permission has a required resource type of cluster or editor but wouldn't Resource:* and the use of elasticmapreduce:StartEditor be specific enough to mimic how elasticmapreduce:CreateEditor can use Resource:*?
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": "arn:aws:elasticmapreduce:*:123456789012:editor/*",
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"owner1",
"owner2"
]
}
}
}
]
}
There are a few things going on here, I will reply to your questions in order:
since the specific permission is elasticmapreduce:CreateEditor does that really just imply that it ends up only affecting the editor resource in EMR assuming the conditional block is satisfied?
The CreateEditor action only applies to the Resource Type cluster*, so with it, you basically restrict for which clusters the IAM entity can create an editor. It would not make sense to be able to restrict CreateEditor to a specific editor since that editor would not yet exist. That also means that resource:* doesnt equal rn:${Partition}:elasticmapreduce:${Region}:${Account}:editor/* in this case since it only applies to clusters.
Another area of confusion is that in this example below there is a specific resource type declared. Why isn't Resource:* used here?
In your second example the goal is explicitly to only allow access to editors that have a specific "owner" tag. Putting Resource:* in that policy would also extend the tag requirement to clusters (since elasticmapreduce:StartEditor can apply to both clusters and editors). That would mean that both the editor and the cluster would need to have the tag for the IAM entity to be able to start the editor.
As you can see in the two examples that follow your second code in your link (section Limit the ability to start a notebook based on tags), the example is then extended to specify a different tag requirement for the cluster.
Related
I want to block access to certain resources that I create as a base set up in new AWS account in my Organization. I want to do this for all users except Admins. The access only for admin part is solved with this design:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/myadminrole",
"arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/sso-region/AWSReservedSSO_myrolename"
]
}
}
}
]
}
As you can see in the above role everything is denied for everyone except the admins, this not i want to do I want to block access to certain resources. The simplest way to do so is just to list the resources I want to block access to under "Resource". But this will resolve in manual work to keep this SCP up to date and this is something I try to avoid. So my second idea was to use tags and base the deny of access on them with a condition like this:
"Condition": {"ForAllValues:StringEquals": {"aws:TagKeys": ["mytagkey"]}}
But when I ran into this issue where some AWS services don't support authorisation based on tags, see link:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html#:~:text=Yes-,AWS%20Lambda,Partial%C2%B2,-Amazon%20Lightsail
Does anyone know a good way to solve my issue? Or does I just have yo accept that I have to manually update my SCP?
After investigation both from me and AWS support this is not possible at the moment. So the answer is that you need to manually update your SCPs.
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
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 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/*
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!