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.
What is IAM
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.
Resource: Anything worth protecting. A storage service a virtual machine etc
Policy: A set of rules which dictate "who can what" on which resource. And of course, who cannot
Action: Anything someone can do, inside the cloud environment. For example, creating a virtual machine
User: Well...a user :)
Group: A group of users, with the same permissions, applied
Principal: A user or an application requesting access
Role: A set of powers assigned to a principal. Usually for a limited amount of time.
Why it is useful
Its main usage roams in the realms of authentication, authorization, granular access, governance. Let's see what those things are:
Authentication: We have verified who you are
Authorization: We want to identify if you can perform the action you ask for. Usually, combined with Authentication but not necessary.
Granular access: Each action that can happen in a resource, is controlled by permission. Having access to see the firewall rules doesn't mean you can change them. This is implemented with Role-Based Access Control
Governance: The actions you take to know what the f@ck is happening to your environment. Mostly from a budget, compliance, proper access scope.
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
Problems from the lack of one
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.
Hard to audit and administer access
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.
Setting up new hire accounts is a pain
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?
Offboarding people
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?
Commodity identity tasks need human intervention
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.
Best practices
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.
No full access...EVER
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.
Groups vs multiple users
Prefer a single group to multiple users when you have a choice. The groups make administration exponentially easier.
Roles vs multiple groups vs a new user
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.
Permissions should be frequently audited
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.
Setup boundaries beforehand
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.
Conclusion
Thank you for reading this far. I hoped you enjoyed the introduction to the IAM technologies. Any questions, please reach out.
Top comments (0)