Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Within IAM, can I restrict a group of users to access/launch/terminate only certain EC2 AMIs or instances?

What the title says.

Within the master AWS account, I have several personal accounts, i.e. AWS Identity and Access Management (IAM) users. I would like to assign certain IAM users to groups and prevent them from terminating certain Amazon EC2 instances, de-registering certain Amazon Machine Images (AMIs), etc.

I don't mind if they're playing with their own stuff, but I don't want them to touch my stuff.

Is that possible?

like image 831
Florin Andrei Avatar asked Mar 22 '12 19:03

Florin Andrei


People also ask

How do I restrict access to a specific EC2 instance?

Open the Amazon EC2 console, and then add tags to the group of EC2 instances that you want the users or groups to be able to access. If you don't already have a tag, create a new tag. Note: Be sure to read and understand the tag restrictions before tagging your resources. Amazon EC2 tags are case-sensitive.

Can I restrict the access of IAM users to specific EC2 resources?

Most essential Amazon EC2 actions don't support resource-level permissions or conditions, and isolating IAM users or groups of user's access to Amazon EC2 resources by any criteria other than AWS Region doesn't fit most use cases. Instead, consider linking multiple different AWS accounts through AWS Organizations.

Can I restrict the access of IAM users to specific Amazon RDS resources?

IAM starts with no permission, unless you defined explicitly, this IAM user will not be able to see other resources, like EC2. 3. Tagging Amazon RDS Resources: You will need to tag your RDS resources, so they can be used with IAM policies.

Is it possible to restrict AWS users accounts to a specific region?

You can now use the aws:RequestedRegion global condition key in your IAM policies to specify the region to which the IAM principal (user or role) can invoke an API call.

How do I restrict users'access to launch EC2 instances using Amis?

To restrict users' access to launch EC2 instances using tagged AMIs, create an AMI from an existing instance—or use an existing AMI—and then add a tag to the AMI. Then, create a custom AWS Identity and Access Management (IAM) policy with a tag condition that restricts users' permissions to launch only instances that use the tagged AMI.

How do I restrict users from launching an instance with Ami?

Then, create a custom AWS Identity and Access Management (IAM) policy with a tag condition that restricts users' permissions to launch only instances that use the tagged AMI. In this example IAM policy, there are three statement IDs (Sids):

What access can I control with an IAM policy?

When you create an IAM policy, you can control access to the following: Principals – Control what the person making the request (the principal) is allowed to do. IAM Identities – Control which IAM identities (user groups, users, and roles) can be accessed and how.

Is it possible to isolate IAM users from Amazon EC2 resources?

Most essential Amazon EC2 actions don't support resource-level permissions or conditions, and isolating IAM users or groups of user's access to Amazon EC2 resources by any criteria other than AWS Region doesn't fit most use cases. Instead, consider linking multiple different AWS accounts through AWS Organizations.


1 Answers

Update

AWS has just announced Resource-Level Permissions for Amazon EC2 and Amazon RDS to address this long standing shortcoming of IAM support within EC2 and RDS (in comparison to other AWS services, see my original answer below for details/background):

Today we are making IAM even more powerful with the introduction of resource-level permissions for Amazon EC2 and Amazon RDS. [...]

On the EC2 side, you can now construct and use IAM policies to control access to EC2 instances, EBS volumes, images, and Elastic IP addresses. [...]

Here are just a few of things that you can do:

  • Allow users to act on a limited set of resources within a larger, multi-user EC2 environment.
  • Set different permissions for "development" and "test" resources.
  • Control which users can terminate which instances.
  • Require additional security measures, such as MFA authentication, when acting on certain resources.

This solves a plethora of security complications and enables quite a few new use cases as well.

Furthermore, EC2 policy statements can include reference to tags on EC2 resources, which allows to use the same tagging model and schema for permissions and for billing reports. Finally, there's an expanded set of condition tags [...] including ec2:Region, ec2:Owner, and ec2:InstanceType, see Condition Keys for Amazon EC2 for details.

Solution

Here's a variation of Example 3: Allow users to stop and start only particular instances for the use case at hand, which allows users to start and stop [and terminate] only the instances that have the tag "department=dev":

{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": [
        "ec2:StopInstances", 
        "ec2:StartInstances",
        "ec2:TeminateInstances"
      ],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/department": "dev"
        }
      }
    }
   ]
}

Caveat

Support for resource-level permissions is restricted to the following set of actions on the indicated resources still, which excludes parts of the use case (e.g. de-registering AMIs) - the confidence in the foundation for this complex and far-reaching feature is apparently high enough though to announce that they plan to add support for additional APIs throughout the rest of 2013 (AWS doesn't usually publish any roadmaps):

  • Instances - Reboot, Start, Stop, Terminate.
  • EBS Volumes - Attach, Delete, Detach.

Original Answer

I'm afraid this isn't possible the way you'd like to do it (and many others for that matter, including myself).

Problem

You want to restrict access to a particular service's resources rather than its actions - while AWS Identity and Access Management (IAM) supports both in principle, not every AWS product/service offers restrictions based on resources yet; unfortunately Amazon EC2 is one of these and even featured as an example for this very difference, see Integrating with Other AWS Products:

The following table summarizes whether you can grant IAM permissions that control access to a service's actions, resources, or both. For example, you can use IAM to control which Amazon EC2 actions users have access to, but you can't use IAM to control users' access to AMIs, volumes, instances, etc. [emphasis mine]

(Partial) Workaround

Depending on the needs of the other accounts, you might still be able to at least limit their ability to perform those actions considered destructive - you can explore the available actions via the AWS Policy Generator, for example:

  • ec2:DeregisterImage - obvious effect, when denied for a user/group
  • ec2:ModifyInstanceAttribute - this would help via Enabling Termination Protection for an Instance, when denied for a user/group:

By default, you can terminate any instances you launch. If you want to prevent accidental termination of the instance, you can enable termination protection for the instance.

That is, once you've enabled termination protection, anyone without permission to use ec2:ModifyInstanceAttribute cannot terminate these instances at all.

Obviously the respectively restricted accounts won't be able to facilitate those calls for their own resources anymore.

Furthermore this won't prevent them from running a fancy Cluster Compute Eight Extra Large Instance or so, incurring respective costs in turn ;)

Alternative Approach

Depending on your setup/environment you might want to look into Consolidated Billing instead, which essentially provides a way to gather one or many AWS accounts under another one, which is paying for the resources used by the others.

While this is primarily an accounting feature, it can be used to separate areas of concern as well - for example, it's quite common to facilitate separate development and production accounts to achieve respectively independent operation, not the least regarding IAM rights and the like.

The introductory blog post New AWS Feature: Consolidated Billing provides a good overview, and here is the relevant topic from the AWS Consolidated Billing Guide regarding your apparent use case:

The paying account is billed for all costs of the linked accounts. However, each linked account is completely independent in every other way (signing up for services, accessing resources, using AWS Premium Support, etc.). The paying account owner cannot access data belonging to the linked account owners (e.g., their files in Amazon S3). Each account owner uses their own AWS credentials to access their resources (e.g., their own AWS Secret Access Key). [emphasis mine]

Obviously this functionality is targeted at larger customers, but depending on your scenario you might be able to come up with a solution to separate your AWS accounts and resources as needed still.

like image 125
Steffen Opel Avatar answered Sep 19 '22 12:09

Steffen Opel