I am following the aws documentation and created 3 security groups needed.
master
core
task
Now I am creating the cluster and it fails saying
Terminated with errorsAmazon EC2 permissions error when configuring required rules on securityGroup XXXXX.
What IAM permissions or other permissions I need to achieve this ?
Also how does a AWS service adds rules to the SG dynamically ? What permission does it need to achieve this ? Can it be more restrictive like the IAM roles/resources access?
Thanks,
If the service needs to modify security group rules, it must have the following permissions for the respective security groups:
"Effect": "Allow",
"Actions": [
"ec2:DescribeSecurityGroups",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress"
],
"Resources": [
"1st-security-group-arn",
"2nd-security-group-arn",
...
]
Note: Depending on what you're trying to do, it might also need "ec2:CreateSecurityGroup" and "ec2:DeleteSecurityGroup".
You can find the default permissions for the Amazon EMR Service Role in the documentation.
Related
I am learning AWS and I have the following task in an online training course:
Configure the MongoDB VM as highly privileged – configure an instance
profile to the VM and add the permission “ec2:*” as a custom policy.
I am trying to work out what that means. Is the task asking for a role that enables the VM instance to have full control over all EC2 resources?
If I understand it correctly, then I think the following policy would implement it.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:*"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:*:*:instance"
}
]
}
My understanding is that this policy is saying any EC2 instance can perform any EC2 action. Is that right?
I would say you are almost correct. Roles are attached to individual services which means your particular VM can perform any Ec2 action on this resource arn:aws:ec2:*:*:instance.
There is a difference in saying any ec2 can perform ec2 action instead that ec2 instance can perform any ec2 action to which this role is attached.
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.
Im trying to use EC2 Container service. Im using terraform for creating it.
I have defined a ecs cluster, autoscaling group, launch configuration. All seems to work. Except one thing. The ec2 instances are creating, but they are not register in the cluster, cluster just says no instances available.
In ecs agent log on created instance i found logs flooded with one error:
Error registering: NoCredentialProviders: no valid providers in chain
The ec2 instances are created with a proper role ecs_role. This role has two policies, one of them is following, like docs required:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:DeregisterContainerInstance",
"ecs:DiscoverPollEndpoint",
"ecs:Poll",
"ecs:RegisterContainerInstance",
"ecs:StartTelemetrySession",
"ecs:Submit*",
"ecs:StartTask"
],
"Resource": "*"
}
]
}
Im using ami ami-6ff4bd05. Latest terraform.
It was a problem with trust relationships in the role as the role should include ec2. Unfortunately the error message was not all that helpful.
Example of trust relationship:
{
"Version": "2008-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Principal": {
"Service": ["ecs.amazonaws.com", "ec2.amazonaws.com"]
},
"Effect": "Allow"
}
]
}
Make sure you select the correct ECS role in the launch configuration.
You might want to add AmazonEC2RoleforSSM (or AmazonSSMFullAccess) to your EC2's role.
apparently this error message also occurs when an invalid aws-profile is passed.
I spent 2 days trying out everything without any luck. I have a standard setup i.e. ecs cluster instance in private subnet, ELB in public subnet, NAT and IGW properly set up in respective security groups, IAM role properly defined, standard config in NACL, etc. Despite everything the ec2 instances wouldnt register with the ecs cluster. Finally I figured out that my custom VPC's DHCP Options Set was configured for 'domain-name-servers: xx.xx.xx.xx, xx.xx.xx.xx' IP address of my org's internal DNS IPs...
The solution is to have following values for the DHCP Options Set:
Domain Name: us-west-2.compute.internal (assuming your vpc is in us-west-2),
Options: domain-name: us-west-2.compute.internal
domain-name-servers: AmazonProvidedDNS
I got this error today and figured out the problem: I missed setting the IAM role in launch template (it is under Advanced section). You need to set it to ecsInstanceRole (this is the default name AWS gives - so check if you have changed it and use accordingly).
I had switched from Launch Configuration to Launch Template, and while setting up the Launch Template, I missed adding the role!
if you use taskDefinition , check that you set execution & taskRole ARN's and set correct policies for that roles.
I have created a policy for restricting access of a user to a single instance as:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1392113879000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"arn:aws:ec2:us-east-1:account:instance/instance_id"
]
}
]
}
But I am getting this error:
You are not authorized to describe Running Instances
You are not authorized to describe Elastic IPs
You are not authorized to describe Volumes
You are not authorized to describe Snapshots
You are not authorized to describe Key Pairs
You are not authorized to describe Load Balancers
You are not authorized to describe Placement Groups
You are not authorized to describe Security Groups
I cant see the instance in the console. If i cant implement this thing then what is the use of policies!!
Im stuck please help
from iam-policies-for-amazon-ec2
Currently, not all API actions support individual ARNs; we'll add
support for additional API actions and ARNs for additional Amazon EC2
resources later. For information about which ARNs you can use with
which Amazon EC2 API actions, as well as supported condition keys for
each ARN, see Supported Resources and Conditions for Amazon EC2 API
Actions.
So, wiritng ec2:* is not going to help you. Instead, you should provide exact API actions that you wish to grant to this user.
Also, quoting from the same link referred above:
To specify all resources, or if a specific API action does not support ARNs, use the * wildcard in the Resource element as follows:
Assigning restrictive EC2 IAM polices is a bit complicated. You may want to read above referred link in detail as well as this link.
Check your region. Your policy uses US-East-1, but where are your instances? US-West-2?
I have read the AWS documentation and it wasn't helpful... at least not for me. I have read about IAM and the user policy on the EC2.
I want to make users have full access/(or just some actions allowed) only on ONE ec2 instance.
The region I'm using is eu-west-1(Ireland). I made this policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/INSTANCE_ID"
}]
}
and when I login as the user, I see that I'm not authorized:
You are not authorized to describe Running Instances
You are not authorized to describe Elastic IPs
You are not authorized to describe Volumes
You are not authorized to describe Snapshots
You are not authorized to describe Key Pairs
You are not authorized to describe Load Balancers
You are not authorized to describe Placement Groups
You are not authorized to describe Security Groups
If I apply the following policy for the resource attribute:
"Resource": "arn:aws:ec2:*"
it's Ok but it's not what I need because users have access on all EC2 instances.
I want to know if this is a bug of AWS or there are problems with eu-west-1 region or this policy isn't supported already? Or maybe I'm wrong, if so, please help me how to do
The recently introduced Resource-Level Permissions for EC2 and RDS Resources are not yet available for all API actions, but AWS is gradually adding more, see this note from Amazon Resource Names for Amazon EC2:
Important Currently, not all API actions support individual ARNs; we'll add support for additional API actions and ARNs for additional
Amazon EC2 resources later. For information about which ARNs you can
use with which Amazon EC2 API actions, as well as supported condition
keys for each ARN, see Supported Resources and Conditions for Amazon
EC2 API Actions.
You will find that all ec2:Describe* actions are indeed absent still from Supported Resources and Conditions for Amazon EC2 API Actions at the time of this writing.
See also Granting IAM Users Required Permissions for Amazon EC2 Resources for a concise summary of the above and details on the ARNs and Amazon EC2 condition keys that you can use in an IAM policy statement to grant users permission to create or modify particular Amazon EC2 resources - this page also mentions that AWS will add support for additional actions, ARNs, and condition keys in 2014.
Possible Workaround/Alternative
Instead of or in addition to constraining access on the individual resource level, you might want to check into (also) using Conditions combined with Policy Variables, insofar ec2:Regionis one of the supported Condition Keys for Amazon EC2 - you might combine your policy with one that specifically handles Describe* actions, e.g. something like this (untested):
{
"Statement": [
{
"Action": [
"ec2:Describe*"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:Region": "eu-west-1"
}
}
}
]
}
Please note that this would still allow the user to see all instances in eu-west-1, even though your original policy fragment would prevent all API actions that already support resource level permissions (e.g instance creation/termination etc.).
I've outlined yet another possible approach in section Partial Workaround within my related answer to How to hide instances in EC2 based on tag - using IAM?.
Good Luck!