token-policy

All,


There have been questions about access to AWS resources, and how to gain tokens to make API requests. In order to reduce some of this friction, here is some context around how the system works.

Amazon Web Services uses a high-level identity management based on tokens, called IAM, or Identity and Access Management. There are several objects in this model: Groups, Policies, and Users. Each "User" is tied to a unique Access Key and Secret Key, analogous to a username and password on a Unix-like environment. These will henceforth be referenced as "Tokens" for sake of brevity. "Groups" are a logical grouping of users. One user may belong to many groups, and one group may have many users. "Policies" are pemission(s) granted to either Groups or Users. One policy may be granted to any number of these entities. 

A "Policy" allows a Token pairing to make API calls. These policies, at a high level, consist of "Resources" and "Actions", which dictate who is allowed to do what on what resources. These are analogous to setting permission bits in Unix.

If you are working on a project that requires you be able to make requests against an AWS resource, you will need a Token with a Policy attached to it, or to be added to a Group that already has those permissions. Automated systems like Wercker also need AWS Tokens to perform requests. 

Starting now, the proper way to request these tokens will be through the Operations support system. Because many kinds of Policies and Tokens have the potential to introduce security holes or allow increased resource consumption (and spending), please allow a full business day (24 hours during the week) for review and issuance of the Token(s). 

Some more specific instructions:
Begin ticket names with "AWS TOKEN REQUEST:"
State the most specific possible resource you need to utilize
GOOD: "I need access to development neiman configs"
GOOD: "I need to be able to make new client config environments for client X"
GOOD: "I need to be able to read the CPU usage on production Sora"
BAD: "I need to push to CDN"
BAD: "I need to be able to manage sora"
State the exact minimal actions you need to be able to perform on said resources(s)
GOOD: "I need directory listing and GET ability for _____"
GOOD: "I need scale triggering permissions"
BAD: "I need to do everything on Sora"
BAD: "I need to be able to manage production configs"
Justify why you/a system needs this access. You will be denied access without good reason, especially for production.
GOOD: "Here's the ticket #, I'm finishing up monitoring support. I looked into cost and it will be about this number."
GOOD: "The client needs to go live this week, I'd like to provision them" (the process is well-defined for other clients, no costing needed)
BAD: "I want to make a server" (why? how big? $$$?)
BAD: "Why can't I do this? " (Because principle of least-access)
If you require create/write access to production, or read/list access to a production that may add significant load or cost, it may take more than 24 hours to get budget approval. This is unavoidable, as risk is high, both from a security and an expenditure standpoint. A wildcard EC2 token can cost the business a debooking, service outage, or thousands in unneeded costs.
This may seem like a pain, but by standardizing the issuance of these tokens, we get an extra layer of security and financial auditability. Furthermore, this process should greatly improve access to development and testing resources, since we can let people go and handle their own slice of the cloud!

If you have any questions, please remember to only reply-all if pertinent to every department :)


Best,

Andrew Templeton