Introduction

With the plumbing in place I can start to think about deploying IAM Users, Roles and Groups. Yay! I can deploy stuff but hang on… What am I going to deploy? What does it look like? Where do I even begin?

To answer these great questions, lets dive into the picture below:

Roll-based Access Control Deployments

The last post covered the orange coloured resources; namely a CloudFormation StackSet that deployed two roles into the three child accounts. This post covers my approach to designing the green and red resources.

What is RBAC?

Roll-based access control (RBAC) is a method for granting permissions to do things in your system(s) to either other users or other systems.

You start doing this by identifying the job functions that need to be performed. Next you identify the required permissions and finally aggregate them as named roles. On AWS, these are implemented as IAM Roles.

A job function could be broad like Developer and Auditor or small like LogShipper or CostAndUsageAggregator. For human access to AWS an IAM User and then added to an IAM Group which contains the permissions to assume the role.

Remember: An IAM User can assume an IAM Role in another account which is how cross-account access works. 😛

Why do it at small scale?

It’s tempting when starting out on AWS to hand-roll IAM resources. As you add new accounts into the mix, you start copying and pasting roles between accounts and manually gluing bits together. It works ok until you forget to add a required permission into an account that you hardly go into. This will bite you 6 months later after something has gone 💥 and you can’t get in there to fix it.

Or you forget to remove a permission that you temporarily granted 6 months ago. You pop in to do something and remembered that you needed to remove them. You remove them and suddenly something stops working for a random reason and you don’t know why.

So, avoid the pain and just use infrastructure-as-code and automate it all away!

What about AWS SSO?

I’ll confess that, at the time of writing, I have no administration experience with AWS SSO. I do like the idea of it, however from what I can see in the documentation there is zero support for automation. Instead, the crafting of permissions sets and the deployment across accounts is done via the AWS Console.

Heading deep into opinion territory; I’d much prefer to use automation and IaC than point-and-click inside the console. I feel it gives better control, auditing, and documentation (aka what did I do 6 months ago?) than via the console. Very happy to be corrected if you think otherwise, you may even be able to change my mind 😉.

Approach

Below is my high-level my approach to modelling RBAC for small-scale usages of AWS. I have used this approach successfully by running short sessions with key stakeholders to flesh out each of the steps below. I do recommend breaking this up into short sessions as it can quickly become draining.

  1. The first step is to identify all the AWS accounts which is pretty easy if you can see the accounts through AWS Organisations
  2. The next step is to identify all the job functions that will interact with your AWS accounts. These are not the job titles on your organisational structure, although they may overlap. Typical job functions include auditors, read-only (aka visitor), developer, network administration etc. Do not forget to include non-human functions such as shipping logs or querying for AWS billing information.
  3. Create a matrix with the accounts across the top and job functions down the side (direction doesn’t matter, switch axis if that’ll work better)
    Management Account Child #1 Account Child #2 Account Child #3 Account
    Visitor
    Developer
    Administrator
  4. Where are job function has no access, put in a ❌.
  5. For each job function design a “generic” IAM Role and Policy (i.e. what the “typical” permission set looks like). These permissions cover what the function does across the most number of accounts.
  6. Complete the matrix using the “generic” role as much as possible. The gaps will represent corner cases, e.g. a developer job function will have more restrictive permissions in a production account versus the non-production account(s).
  7. Design the corner-case roles and fill out the matrix.
  8. It might take a few iterations, but eventually you’ll end up with a complete matrix like this. The IAM role name fills out the cells in the matrix
    Management Account Child #1 Account Child #2 Account Child #3 Account
    Visitor ❌ ReadOnly ❌ ReadOnly
    Developer ReadOnly ReadOnly Developer ReadOnly
    Administrator Administrator Administrator Administrator Administrator

Wrapping Up

Tune in next week for the final instalment in this series where I go all technical and show how I implemented the diagram above in code.