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:
You can create Custom Managed Policies of your own, with AWS’ Policy Editor or you can use one of a multitude of AWS Managed 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.