1. All IAM policies/roles and InstanceProfile's should be managed in CloudFormation, no exception.
2. Policies should not be inlined into the IAM role policy document, rather they should be attached (excepting item 3 and 4).
3. IAM roles which are used for signing S3/CloudFront/... requests which are subsequently made public should should have all policies inlined AND the explicit resource should be defined.
4. IAM roles granting access to an external (non-AWS service) principal should generally inline all statements unless the relationship to the principal can be considered secure.
5. Policies should have multiple statements, one statement per AWS service.
6. Most non-administrative policies dealing with persistent storage (DynamoDB/S3) should be constrained to a limited number of resources.
7. Glob-Star is not permitted for any `Action` statement (ie: no `s3:*`).
8. Absolutely no AWS_ACCESS_KEY's are permitted on EC2 instances.
Without even having to dive into userdata or metadata, just (a) create the role for the ec2; (b) attach the trust and permission policies; (c) create an "instance profile"; (d) attach the instance profile to your target instances.
If via console, that gets done behind the scenes when attaching the role. But ya roles use the security token service behind the scenes which allow for temp creds vs. storing sensitive stuffs on the instances.
I work on multiple AWS installations and we use the approach you describe of only defining IAM Policies and avoiding resource-based policies where possible. The one exception is KMS Keys, which require a KMS Key Policy.
That being said, I've found IAM's power impressive but ultimately complex. If you're really serious about isolating users from certain resources, separate AWS accounts for each environment may well be the best way to do this. This way, you can grant "admin" access to users in your "stage" AWS account, they get all the permissions they need to do their work, and have no permissions to the more sensitive "prod" account.
> I've found IAM's power impressive but ultimately complex
Honestly, as a not-a-security-guy, I can count on the fingers of one hand the number of times I've had to learn something around security and it's been easy.
> separate AWS accounts for each environment may well be the best way to do this
A thousand times yes. There is so much to do in IAM, that it's just easier to let the devs have access to a 'test' account, and keep the 'prod' account out of their mitts.
That's what we've done, and it's been a huge help. There are a few areas where it's a little complex (things like build servers; does each environment get its own? That makes it so we have to duplicate effort on the build server rather than knowing it really -is- the same build. But if it's shared across environments, it has -accounts- across all environments. So tradeoffs). But in general shooting for isolated environments has definitely been of benefit.
If the multi account pattern with its higher level of isolation suits your organizational needs, this new AWS offering may be helpful: https://aws.amazon.com/organizations/
Out of curiosity, do you keep 1-1 mapping among users/groups/roles(/resources?) across different accounts? Because that's another possible source of complexity.
We (http://gruntwork.io) are still establishing best practices around managing multiple AWS accounts, but so far having a single "admin" account where all IAM Users are managed seems like a best practice. You can then implement a nifty dropdown that allows IAM Users to easily switch accounts. [1] I'm not sure about how IAM Groups fits into this.
For IAM Roles, we use Infrastructure-as-Code (Terraform) to create all those anyway, so I still prefer to create those in the AWS account that contains the resources to which they apply.
Just for anyone wondering, as per joshpadnick's great suggestions, you can specify other AWS account's users/roles via Principal in a policy as well. Just use the other AWS account in the ARN. edit: if you want to do so via policies that is
I'd be interested to see your team's workflow for multiple accounts @joshpadnick.
One account per service per region per deployment stage (e.g. dev, test, production) is the best practice. How you define "service" is up to you, but I usually divide them by trust/dependency footprints.
This significantly reduces the risk that an account-level problem or throttle will disrupt your entire business.
Fortunately, AWS finally seems to be getting serious about building management tools for multiple accounts. AWS Organizations is way better than the old consolidated billing stuff.
Who calls that a best practice? If you're a very small company, that might be fine. With thousands of employees and tens or hundreds of applications, you'll run into serious problems if you want to use e.g. VPC peering for shared services. You'll also run into major cost issues if for example you have per-VPC or per-account commercial appliances.
That's interesting, because their consultants discourage it for their customers. For companies that want to keep most of their traffic internal, I don't think it's a working model. I suppose Amazon's internally used services are the same ones they expose to customers, so it probably works fine.
It's honestly going to depend. In some cases you don't really have a choice. For example if you want to limit an S3 bucket to an IAM group, since S3/Resource Policies don't support IAM groups ARNs in the principal, the only solution is to apply the permissions around access to that S3 bucket to the IAM group (as opposed to the bucket).
As for which direction, this is going to be a bit of preference and need. Do you want permissions to begin at the user or at the resource? For scenarios, like a bucket controlling access to non-aws users, it makes sense to have it on the resource. For others, like delegating bucket access to certain EC2 instances, it makes more sense to keep it on the role user.
The fuzzy lines of gray are only exaggerated by the fact that the docs love doing stuff like: "These two policies are equivalent!" And showing examples that accomplish both.
Tl;dr, (a) pick the permission direction that makes sense (b) set a standard for your team and infrastructure and stick with it (c) try to not use NotVersions of actions
We have both out of necessity. IAM policies on roles/users/groups are a given, but here are some concrete examples of what we're using resource policies for:
- Granting cross-account access to resources without requiring an explicit sts:AssumeRole on the other side (in some cases for things like CloudTrail and billing reports this is the only option)
- Enforcing SSE on S3 buckets (implemented as a DENY in the bucket policy with conditions to check for missing SSE headers)
We use an IAM Role for each type/role of vm and per environment/region. I am using more and more inline-policies because in most cases is hard to reuse a managed policies. Also, there is a very low limit for managed policies within a Role: 10.
How do we maintain mental sanity? We define all our infrastructure on code (terraform) and we have found the right abstraction in the tool: modules. One module output is used as input on another module. Let's say you have a module to create and configure a bucket exporting the arn of the bucket, then another module to create the autoscaling-group along with its security groups, IAM Role and Policy. All changes are made through pull-requests and reviewed.
If you want to know who has access to a resource you read the dsl. I havent seen any tool to query aws api that way. It might be complex to build because policies can have all sort of wildcards.
Oh wow. That's an interesting case for inline policies. Now that I think about it, yes there's plenty of cases for reusable ones, and there seem to be just as many cases where a policy is unique to exactly that one service/situation.
There's been lots of griping about AWS and IAM, which I'm sure is at least in part due to AWS' popularity, but how does it compare to permissions management from other major cloud providers, e.g. google and azure?
Haven't dealt with Google much but Azure and AWS have good and bad points with identity.
Azure is much easier to define RBAC access for individual resources in the portal, but doesn't give a unified view of what a user has access to (that I've found).
AWS IAM provides a much more consistent experience across services - I have a key pair or role and that key pair/role works across all the AWS services according to the policies defined. Compare to Azure Storage Account access for example.
AWS IAM can get frustrating when you take into consideration interaction between things like user policy, bucket policy and VPC endpoint policy when trying to access S3 from an EC2 instance in a VPC.
AWS IAM policies can make it difficult to express some use cases, mostly relying on tags and the console doesn't support tags on resource creation for many services. I've also run into bugs in cloudformation where it ignores or doesn't support putting tags on redshift clusters, meaning the only way I could give someone access to create a redshift cluster with tags was either through the CLI or APIs directly.
AWS IAM Roles and Instance Profiles are amazing for granting access to EC2 instances, and they added similar functionality for containers in ECS recently also.
Overall I like the AWS approach better because I find it much easier to implement as code and also probably because I've been using it for much longer.
When you switch roles in the console, you don't have to enter in your credentials. So, if I get access to the account, I have access to all the roles. So, what additional protection is provided by separating out permissions into roles that are trivially accessible?
I can see how if conditions are added to the AccessRole action, such that I can only switch roles based on time of day or IP address, then that might be useful (although those conditions could be applied directly to policies as well).
So, absent the conditions mention above (which is still questionable), is there any point to using roles in the console?
This is where users come in. You should be setting up users other than the root user which have significantly fewer permissions. We essentially use our root user to set up the account and then throw away the MFA key (not really, but you get the idea).
This allows you to use your company's own identity provider instead of IAM users (or in conjunction with). In this scenario, users access the console by assuming a role. You essentially say "Users within this Active Directory group are allowed to access the console by assuming this role."
Isn't the "Principal" element only a part of S3 permission policies, not IAM? In IAM the "principal" is implied, it's the user to which the policy is attached. Edit: I see you explain well into the article, but I believe the title of the article could be improved.
Yeah, I mention that in the "Who" aka Principal section. It's like that for any resource based policy (i.e. like S3). So IAM Users/groups have it implied, but Resource based ones like S3 do not have it implied.
The thing is, an S3 bucket policy is not an IAM policy. It's a bucket policy. They use the same language, format, and syntax, but they are not called the same thing.
Indeed, they're just a "resource" policy. They're still talked about and share the so many same attributes that it became more character saving to say AWS IAM Policies vs. AWS IAM, S3, SNS, SQS, Glacier Policies =P
We use 1 base policy + 1 policy/role, and so for each role it's easy to see what are its permissions.
We have no policy on resources, so it's hard, e.g., given a bucket to know who has access to it. We're building tooling for that.
edit: grammar/typos