I have used AWS for many years but one of the concept I really struggled initially was AWS IAM — and permission control in general. I wrote this introduction to ease into the main concepts and help you tackle the overwhelming documentation on the subject.
When you log into AWS console — you gain access to your AWS account. Account is identified by a number such as 785321230321. It can also have a text alias.
Some organisations will use multiple accounts as an added security measure like so:
- production account
- qa account (preprod testing)
- resource account (holds your code repos)
- 3rd party developer account
AWS allows and encourages cross-account solutions.
AWS Resources and Actions
The first resource AWS introduced was a S3 bucket but later it was expanded to general-purpose computing with EC2. Now anything — bucket, instance, user or even role itself — is a resource. All resources have a unique ARN. Each resource is of a particular type and attributed to a specific service (type=instance, service=ec2). Each service has an API.
There are multiple things you can do with every resource like Create, Delete, Update, etc.
This is a pair of Access key and Access secret used for authenticating. Credentials may be permanent or temporary.
Every single API of AWS will require a valid credentials. Not only credentials must be valid, but must be suitable to perform “Action” on a specific “Resource”.
Finally, service itself may have to send additional request and normally it would carry the same credentials as the initial request.
Assuming the Role
Lets say that the credentials that you are used have unlimited access to all resources within given account. Sometimes you want to use a more “strict” credentials when carrying out a task.
Start by creating a Role. It is a special resource which describes list of permissions/actions/resources. Once role is created, you can “assume the role” and this operation gives back new, unique and temporary credentials.
Finally — new credentials are used to carry out the task. When IAM verifies API request, it will check it against the role.
Quite often a service would need a specific permissions and It makes sense to associate it with a specific role rather than embedding credentials. For example — as you create “CodeBuild” project, it will be executing your instructions every time it is triggered. If you supply it with credentials it would be insecure but those credentials may also expire.
Instead a Service role can be used to generate fresh credentials every time when CodeBuild runs.
Groups and Policies
So far the system described seems elegant, but it relies on repeating individual set of permissions.
In reality it makes sense to reuse those permissions, so naturally things can be grouped.
Often it makes sense to create a group of resources, then allocate permissions to a group. For example IAM Users can be arranged into groups.
Policy groups permissions and those can be attached to Roles, Users but also to some resources, like a bucket. Even account can have policies.
Furthermore limiting access of identities (user or roles).
Together with everything else each request will determine “Effective Permissions” which will lead to a decision to allow or deny the action.