Skip to content

IAM Hero to Console Zero

How to dispose of your users and get away with it

The problem

Over half of cloud breaches start with the leak of static credentials.

The solution

Don't have static credentials.

The other problem

How do you solve the problem of the security trifecta? ec:RunInstances, iam:PassRole and iam:CreatePolicy, no amount of right sizing solves this, but it's a legitimate use case.

Be reasonable, this is a progress over permission journey. The journey starts with JIT access, by default you have nothing, you only request it when you need it. Before even thinking, start with implementing SSO and hardware 2FA everywhere.

A model like this already exists, and it's called sudo. Here comes the sudo for cloud story. You can have lots of access, sometimes. You can start by giving users both ReadOnly and Admin access, but make admin less friendly. Require approvals, closed Jira tickets, whatever to push users to ReadOnly. Make the duration of the admin role shorter, expire the credentials after a couple hours. In this flow, there's potential failures, like a broken Jira system.

When implementing this, you will impact everyone on how they do their daily job. When your system is bad, this creates friction and eliminates trust. Users don't hate you, but they hate when things are done to them. Lead by example, use your own restricted role. When users find out that your job is easier because you have more permissive roles, this creates friction.

Make friends by helping with the pain. When you create Deny policies on certain actions, also alert on it. When a user tries to create an IAM User in the console, this impacts user experience, so alerting on it, helps you in guiding them.

Build a way out! In the account that hosts the JIT system, you'll need an IAM user to troubleshoot. Create an IAM User with MFA. Only after that, deploy the DenyUser SCP in all accounts.

Lessons learned

  • Don't get in the way of people's jobs
  • Helpt them, hurt them, help them
  • Use GitOps and OIDC