I just have created an AWS EC2 AMI for my EC2 instance.
I wanted to give restriction to that AMI(user level,not account level).
For example User1 have created AMI named ami-123.
User1,User2,User3 are present in that account.
I want only User1 should have permission to create EC2 instance using ami-123.
Please help me to sort it out?
By default, users in an AWS Account have no permissions to do anything.
You then grant them permissions for actions they are allowed to call, such as RunInstances.
As part of these permissions, you can restrict the permissions they are receiving, such as the AMI they can specify:
arn:aws:ec2:region::image/*
See: Resource-Level Permissions for RunInstances
Alternatively, you could ALLOW RunInstances but then create a policy to DENY use of a particular AMI.
Related
I have rancherOS running on my bootstrap node from where I want to launch aws EC2 containers. I have to switch the roles in my aws account to launch instances eg: I will be logged in as a user and have to change to admin role. On the rancher UI I can give my access and secret access keys and it is directly pointing me to use the VPC and subnets of 'user' IAM role instead I want to use 'admin' IAM role VPC and subnets. How can I change the roles in this case?
Following is where I got stuck, there I want to switch to another role in aws
You can use the same role switch same as you do with other linux systems,
http://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html
Append your rolename in the configuration and cli takes care from there.
In your cli use which profile you want to use, it will assume his role.
Hope it helps.
I am owner of one EC2 instance. I can ssh to virtual server by key.pem. My question is to print security-group content (inbound and outbound in one page) of this EC2 instance, do I have to attach IAM role to this instance (so that I can use aws ec2 command) ?
I just wondering, if I am the owner of this instance, I shall be able to do anything without extra granting....
IAM permissions has nothing to do with EC2 instances and the owner of the instance is the AWS account. Just imagine what will happen if one of your IAM user can run any commands by just launching an instance.
You can run "aws ec2" command from your local machine/laptop after installing AWS CLI. If you choose to do so, you have to configure the CLI with the access keys of an IAM user with proper permission. Same applies to EC2 instances, but you can leverage IAM role so that you don't have to use access keys and instead use temporary credentials provided by the IAM role (recommended).
http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration
Any idea how to grant the admin rights for a particular VPC to a user or a group in AWS IAM?
You don't really "grant admin rights". Rather, you can control which API calls a user/group is permitted to make, and specify resources and conditions on those permissions.
For example, if you wish to control in which VPC a user is allowed to launch an instance, the policy granting use of the RunInstances command can specify a VPC.
For details, see: Supported Resource-Level Permissions for Amazon EC2 API Actions
We use CloudFormation to deploy our platform. Is here a way to allow the application instance access to the DynamoDB tables without exposing API credentials?
I read about creating an IAM role that has the right permission and use instance profile. How do I achieve this? can someone please provide more details and explain what instance profile is?
As per AWS IAM documentation, Instance Profile is:
An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts.
So, this is a feature provided by AWS so that IAM credentials don't have to be stored in EC2 instances to execute AWS APIs. Also, this feature aids in granting only the permission specified in the desired IAM role to the EC2 instance. Also, you can use the same Instance profile on multiple instances. This way, you don't have to update credentials on each EC2 instance whenever you change the credentials. So, while launching the EC2 instance, you can specify the instance profile. The instance profile is attached to an IAM role. The EC2 instance will get the IAM role and all the IAM credentials. You just need to set the AWS region before using the APIs.
How to do it:
1) Create an IAM role using: create-role
2) Create Instance Profile using: create-instance-profile. The output of this step will contain the Arn for the Instance Profile. This needs to be used in step 4.
3) Add role to Instance Profile using: add-role-to-instance-profile
4) Launch instance using run-instances. Specify the --iam-instance-profile option as below:
--iam-instance-profile Arn=instanceArn
The instanceArn is got from step 2.
The same can be achieved using AWS Console. The Screenshot below shows, how you can specify the role during launch of an EC2 instance:
For more details please see Using Instance Profiles and section 'Permissions Required for Using Roles with Amazon EC2' at page 190 of AWS IAM User Guide.
I would like to add a role to an existing (running?) instance. Is this possible programmatically?
It is not possible (not even in AWS dashboard). You can add an IAM role only when launching an instance
https://aws.amazon.com/iam/faqs/
Q: Can I change the IAM role on a running EC2 instance? No, at this
time you cannot change the IAM role on a running EC2 instance. You can
change the permissions on the IAM role associated with a running
instance, and the updated permissions will take effect almost
immediately.
Now you can attach a role to Running instance from Console and from CLI as well
aws ec2 associate-iam-instance-profile --instance-id *InstanceId* --iam-instance-profile Name=*NewInstanceProfileName*
Official Announcment here
You can now attach or replace an AWS Identity and Access Management
(IAM) role to your existing Amazon EC2 instance. IAM roles enable your
applications running on EC2 to use temporary security credentials that
AWS creates, distributes, and rotates automatically. Using temporary
credentials reduces the risk of long-term key compromise.
For more information. Click here