The term IAM is one of the common you hear in cloud-native environments. What does such a system do, though? And if you do know, how long did it take you to understand the full purpose? I will explain the main concepts behind this massive software family, having the busy engineer in mind.
The fundamentals described here are vendor agnostic. Though most of my experience derives from AWS's implementation.
IAM stands for Identity Access Management. It is a complex system of entities (humans, applications, etc) that request access to a system, on the one hand. And also, there is a complex hierarchical set of rules, to grant or deny the requested access. Before we go any further, below are the main terms you will encounter.
Its main usage roams in the realms of authentication, authorization, granular access, governance. Let's see what those things are:
Are you a company of 1-3 people? Then, setting up a full-blown IAM solution is overkill and a burden to maintain. But if you are more than that or you are planning to scale, then you should start considering it
I believe you can see the benefits of an IAM solution. Let's see what are some common problems organizations face in the absence of it.
Have you heard of cases where an employee had more access than they should? And additionally, no one knew? This can be prevented with a properly set-up IAM solution.
With a properly set-up IAM solution, this is a matter of a few clicks. Namely, set up the users, add them to the IAM groups their teams use. And that's all.
But without it? You need to do all the permission settings from scratch. You might have a reference user to "copy from". But do we need all the permissions this reference user has? Do we want to have special handling for users that are less than 6 months in the company? Does the reference user have superuser permissions that should not accidentally be assigned to the new hire?
Here you have problems of a similar nature to the "new hire case". But you also need to change the password to all the accounts they potentially used. This can turn ugly very fast, not to mention the side effects it has on other team members.
For example, one will have to update all the password occurrences on every offboarding. In every script and application. What if you have a team change 2-3 times per month? How productive this will be?
By commodity, I mean tasks like, resetting a password or re-enabling an account that was locked. The top-tier IAM solutions have a way to resolve such issues fast without much hassle.
Below are some best practices I have derived. It is far from being a full list, it is only my personal experience. I have seen them in more than one team though, so they are probably good enough.
In a real-world scenario, you don’t want every user to have unlimited access to the account. Ideally, no one should have (apart from the account owner). If Jack is working on monitoring logs, they should have read access to that tool. They should not be able to restart a service. Or the accounting team should only view billing information.
Knowing how the VM scalability rules are set is not gonna help anyone.
Prefer a single group to multiple users when you have a choice. The groups make administration exponentially easier.
When you have the choice, prefer assigning a role to a user, rather than creating a new user. For example, don't create an admin user and share the password between 10 people. Create an admin role and assign it to whoever needs it for a limited amount of time.
It is easy to make mistakes or perform malicious actions. At the very least, a company should audit that only the proper people have access and this is at the minimum level.
You could also send an email to a certain team when a suspicious action happens. For example, assigning an Admin role to a new hire.
If the IAM solution allows it, add boundaries to your ecosystem. Copying from Amazon's documentation ( I know, I promised vendor-agnostic :) )
A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.
In layman's terms, you can define the "maximum" permissions that can be assigned to anyone. For example, a user will at most be able to view the logs from the relevant tool and restart a service. If someone attempts to get a role to create a new virtual machine they will be disallowed.
Thank you for reading this far. I hoped you enjoyed the introduction to the IAM technologies. Any questions, please reach out.
Also published here: https://perigk.github.io/post/iam-intro-wish-i-had/