Can You “ec2:Describe” Your Problem?

Sometimes a blog post can be used to inform or instruct. Sometimes it can be used to inspire. Other times, it can be used to commiserate, as in “Are you seeing what I’m seeing, or am I going crazy?” This is the latter type. Let me explain …

We are a small startup that relies heavily upon AWS to run our SaaS application (ParkMyCloud). Like many startups, we also contract with development shops to help keep costs down while we organically grow our business. And while we appreciate their help, we set out to find a way to prevent access by the “hired help” into our production environment. I was drawn inexorably to AWS’ policies as the best solution.

First, hats off to AWS for all the thought and work they put into these. I imagine that to a control freak, this is like dying and going IT heaven. (Hmmm…IT heaven…cloud…nah!)

AWS Policies Looked Simple

For those who are neophytes to AWS policies (like me), these policies allow you to place very granular permissions and restrictions on just about every service AWS offers. Here is what the core syntax of a policy looks like:

And you can have several of these “Sid” blocks in a single “Statement”. (For those familiar with JavaScript Object Notation (JSON), you’ll recognize that format is being used here.)

You can create CustomManaged Policies of your own, with AWS’ Policy Editor or you can use one of a multitude of AWSManaged Policies. You can apply these to Identity and Access Management (IAM) users, groups or roles; or, you can create Inline Policies specific to a user, group or role.

AWS allows you validate the policies you create for proper syntax before applying them, and they have a Policy Simulator so that you can verify that the policy does what you expect it to do.Great! So far, so good.

And, Then, This Happened

So, armed with knowledge I wrote what I thought was a simple inline group policy to fence my contract developers into the us-west-2 region, with access only to EC2 services, and not allow them to have any access into the Virginia region (us-west-1) at all, where my production was running. I didn’t even want them to see that I had a production environment in AWS, let alone know where it was.

Here is what it looked like:

It all seemed so simple. The only problem: It didn’t work! Can you spot the problem?

I couldn’t! After researching this on the web and poring through the AWS documentation for hours, I discovered there is a problem with ec2:Describe. This EC2 action cannot be limited in scope by the ARN string. It has to have complete access to the account. Are you kidding me?!

So, I had to revise my policy as follows:

This meant that my contract developers could see every EC2 instance in the account, though, fortunately, they could only take actions on the instances in us-west-2.

What’s That Saying About Misery and Company?

As it turns out, I am not alone in this. Many of our larger customers have the same frustration. They want to limit the visibility of some of their teams to the resources of other teams. For those who are security conscious, this is a logical first step. Unfortunately, it seems like the only workaround is to open numerous AWS accounts, one for each team or environment. That makes cost tracking and stewardship a bit more challenging.

So, how about it, AWS? When are you going allow the scope of the “*:Describe” actions to be limited by ARN strings and or other conditions, such as tagging in your policies? It would truly help bolster the great work you have already done with your policy engine.

Would you like to see this happen? Comment below – I would be interested in your feedback.

Free Newsletter

Cloud Optimization Blog

Cloud Management

Cost Optimization Techniques

DevOps & ITOps How-To Guides

Cloud Industry Analysis

Technology Trends

Email Never Shared
Cancel Any Time

About Dale Wickizer

Dale brings over 30 years of technology and engineering experience to his role as co-founder and Chief Technology Office (CTO) at ParkMyCloud. After experiencing the problem of growing cloud spend first-hand, and discovering that there was no simple way to solve it, Dale teamed up with co-founder Jay Chapel to create ParkMyCloud to solve the problem of cloud waste.
Before founding ParkMyCloud, Dale was the CTO of the U.S. Public Sector at NetApp, Inc. where he set the future technology and product direction and managed key customer relationships. Prior to NetApp, Dale was an Associate Partner and IT Infrastructure Architect at Accenture, where he helped large enterprises plan and execute IT transformations, data center consolidations, and application deployments. Dale holds both a Bachelor's and a Masters Degree in Electrical Engineering from the Georgia Institute of Technology. He and his wife, Barbara, reside in Springfield, VA.
View all posts by Dale Wickizer →