IAM: Best practices

Posted by on Dec 2, 2013 in AWS, Cloud

The more I play with (and love) AWS as a platform, the more the significance and power of IAM becomes. This post outlines IAM and how it should be used effectively within Amazon’s cloud environment.

What is IAM?

IAM, or Identity and Access Management is the primary means of securing users, groups and permissions. IAM is complimentary to services such as security groups and Access Control Lists (which govern Instance and Subnet security respectively).

Best Practices

Amazon strongly recommends (and I completely agree) that the root/master account should not be used for anything other than administering the Amazon account and creating administrative accounts. Thereafter you should be logged in as a named user (if the master account is a company account) with the minimum required privileges to do your job.
With great power comes great responsibility, and its quite easy with AWS to inadvertently terminate the wrong instance (thus bringing a production server offline) or incorrectly route traffic to the wrong subnet for example. Therefore you should take the time to scope out what level of access each user requires, what functions they need to be able to perform to do their job and then match this up with the IAM policy generation tools. Amazon have done a fantastic job of giving granular access to the services and its contained functions – to the point where you can permit a user to reboot a server but not terminate it, or retrieve content from S3 but not upload (or vice-versa).Thus, as part of your getting started with IAM you should navigate to the IAM section of AWS and set up user(s) pertaining to the role they need to perform

Another best practice is that if a user does not need API access, do not generate the key(s) necessary to enable it. Sure, they’re inherently obscure but why risk it? Oddly enough Amazon defaults the ‘Generate and access key for each user’ checkbox to ticked, so unless you explicitly disable this they will be created. Conversely, if a user ONLY needs API access and doesn’t need to access the console, then do not generate an IAM password that would allow them to log in to the AWS console. By default new accounts do not have a login password, and thus you control who has access to the AWS console. As with all security in IT, the least required privileges, the better!

IAM roles are a relatively new addition to the IAM offering. Roles allow you to assign effective permissions to a particular role as you would a user or group, but assign this to an EC2 instance. Why would you do this? Well, prior to roles, developers would have to embed API keys & secrets in their code or user-data (or use some other mechanism for getting credentials onto an instance) in order to permit it to access another AWS service such as S3. Now, when creating an instance (or templating via CloudFormation), you can set the permitted role and permissions will automatically be effective without the need to set credentials.

A third recommendation is to enable MFA. MFA, or Multi Factor Authentication (also known as two-factor auth on services like Outlook.com or GMail for example) ties a users account to a secondary authentication device. Traditionally this is a separate token generating key-fob, but more commonly nowadays this would be tied to a users personal smart phone. That way, if your password gets compromised your account remains secure as the attacker would also need access to your smart phone. At the very least I’d recommend setting this up on the master account which holds admin access to all services and account details.

Less about security and more about maintainability, Amazon recommends you use role-based permissions in IAM as opposed to user-based permissions. AWS lets you assign permissions at either a user or group level, but the former can quickly become unwieldy and cumbersome to manage. Creating a finite number of role-based groups allow you to quickly and effectively manage users and the resources they have access to. Binding users to private policies makes it much easier to become entangled in a mess of permissions and lose track of who has access to what.

Gotchas

Some gotchas with IAM:

  • It seems counter-intuitive to me, but ALLOW permissions supercede DENY permissions in IAM!
  • IAM is limited to 100 grops – probably not a big issue unless you have a very large organisation or want to be very granular with your permissions

Overall, IAM is an amazingly powerful tool and some way ahead of Azure in terms of its capabilities.