Restricting Access to EC2 Instances Based on Tags
The principle of least privilege is key when it comes to securing your infrastructure on AWS. For example, an engineer should only be able to control EC2 instances that are in scope for her day-to-day work. But how do you make sure an engineer is only allowed to …
- start, stop, and terminate specific instance?
- create, attach and delete specific volumes?
- create, restore and delete specific snapshots?
As illustrated in the following figure you can restrict access to EC2 instances, EBS volumes, and EBS snapshots by making use of …
- tags attached to EC2 instances, EBS volumes, and EBS snapshots.
- an IAM role or user to authenticate an engineer.
- an IAM policy restricting access to the EC2 instances, EBS volumes, and EBS snapshots based on tags.
- a customer-managed CMK (KMS) to encrypt and decrypt data stored on EBS volumes and snapshots.
Attach the following IAM policy to a user or role to restrict access to instances, volumes, and snapshots based on a tag.
Replace <TAG_KEY> with the key you want to use for the tag (e.g. owner). Replace <TAG_VALUE> with an identifier of the user or role (e.g. andreas). Replace <KMS_KEY_ARN> with the ARN of the customer-managed CMK which only the user or role is allowed to use.
** Note: I’ve added # comments to the IAM policy to explain the details. Please remove all # comments before making use of the policy. The JSON is not valid otherwise.**
Hej, Andreas & Michael here!
We launched the cloudonaut blog in 2015. Since then, we have published 325 articles: small tips and tricks, best practices, and service reviews. We enjoy writing about all things AWS a lot.
Do you like our blog posts and podcast episodes? Have you learned something new? Consider supporting us create in-depth and independent AWS content. Please help us with a monthly or one-time payment through GitHub Sponsors.
Start supporting us today!{ |
As the IAM policy references a tag and a customer-managed CMK, it is necessary to use a separate policy per user or role.
Please note, AWS extended the IAM conditions for EC2 heavily during the past months and years. The following information is no longer correct.
Why do we need to use a customer-managed CMK? Because it is not possible to restrict who can restore an EBS snapshot by using tags. Therefore, any engineer could access the data stored on any snapshot. Encrypting all volumes and snapshots with a customer-managed CMK (KMS) is a workaround allowing you to control very fine-granular which engineers can access data stored on volumes and snapshots.
It is also important to note, that it is not all action support conditions by tags. For example, it is not possible to restrict engineers from attaching a networking interface (ec2:AttachNetworkInterface) to any of the instances. If you want to be able to isolate your resources without any limitations, choose a multi-account strategy instead.
For details about IAM policies for EC2 go to the official AWS Documentation or our Complete IAM Reference.
Andreas Wittig
I'm an independent consultant, technical writer, and programming founder. All these activities have to do with AWS. I'm writing this blog and all other projects together with my brother Michael.
In 2009, we joined the same company as software developers. Three years later, we were looking for a way to deploy our software—an online banking platform—in an agile way. We got excited about the possibilities in the cloud and the DevOps movement. It’s no wonder we ended up migrating the whole infrastructure of Tullius Walden Bank to AWS. This was a first in the finance industry, at least in Germany! Since 2015, we have accelerated the cloud journeys of startups, mid-sized companies, and enterprises. We have penned books like Amazon Web Services in Action and Rapid Docker on AWS, we regularly update our blog, and we are contributing to the Open Source community. Besides running a 2-headed consultancy, we are entrepreneurs building Software-as-a-Service products.
We are available for projects.
Feedback? Questions? Drop me a line: Email, Twitter, LinkedIn.
