Imagine you start a new job and receive a keycard. It opens the front door, your floor and the kitchen. Over the next year people add the server room “just for a project”, the finance corridor “for one afternoon” and a back gate “because it was faster”. Nobody removes anything. After twelve months your card opens half the building. Now replace the building with a cloud account and the card with a role, and you have the problem that IAMOps tries to tackle. It is an informal name for managing permissions as code, so they get designed, tested and tidied like any other part of your system.
The xOps School team covers this topic in the Ops Atlas, in a long entry on IAMOps. The Atlas itself says the word is a working label, not a formal field, so do not worry about getting the vocabulary perfect. The ideas matter more.
Four questions behind every door
When a card reader decides whether to open, it effectively asks four things. Who are you? What are you trying to do (open, or copy the key)? Which door is it? And what is the situation, such as the time of day? Cloud systems ask the same four, and the Atlas calls them principal, action, resource and context. If you can state these for any request, you can reason about nearly any access rule.
Two kinds of rules: ones that open and ones that block
Some rules give access. A policy attached to your role saying you may read a storage folder is like programming the card to open a door. Other rules only restrict. Think of a building-wide notice that says nobody enters the lab after 8 p.m. That notice never opens a door for anyone; it only closes some. In cloud terms, organisation-level caps work this way. A common mistake is to think that such a cap “allows” things. It does not. And if a clear deny exists, it overrides the rest, wherever it applies.
Why starting small beats starting big
It is tempting to hand out a master card on day one and promise to review it. The problem, as the Atlas explains, is that after a few weeks the usage history shows the master card in constant use, which seems to prove it was needed. Reversing the habit is easier: give a narrow card, watch which doors people bump into, and open them one at a time. This is the loop of setting, checking and trimming that sits at the centre of the whole subject.
Passes that expire
Cloud keys that never expire are like a card with no end date. If someone leaves, loses it or posts it by accident, it works until somebody notices. The better approach is a pass that lasts an hour and is issued only after the system has verified who is asking. Engineers call this federation, and for automated pipelines it replaces stored secrets. One point to watch: if the rule for issuing passes says “any project in the company may ask”, you have recreated the problem. Be exact about which project and which environment.
If you are just starting out and wondering where this skill fits in a career, the walkthrough in moving up from a junior to a senior DevOps role shows how responsibilities grow, and permission design usually appears around the mid-level stage.
A special case: Kubernetes
Kubernetes adds a twist worth knowing even at beginner level. Its role-based access rules are purely additive: you can add permissions, but you cannot subtract them with another rule. So if you need a guardrail that says “never do X”, you need a different mechanism, usually a check that runs when a request is admitted. Another surprise from the Atlas is that being allowed to list secrets means being able to read their contents, not merely see their names. In keycard terms, being allowed to see the list of safes also opens them.
Small traps that catch everyone
- Exemptions by name. If a rule says “this role is exempt”, anyone who can create something with the same name may inherit the exemption. Protect the name with a companion rule.
- Allow with NotAction. It sounds careful but can grant nearly everything else on the menu.
- Missing information. A rule that says “deny unless the tag equals X” behaves unexpectedly when there is no tag at all.
How teams keep it tidy
Good teams store the rules in a repository, require someone else to review each change, and run tests that try both allowed and forbidden requests. Then they look at the numbers once a month: how many permissions are never used, how old the oldest key is, how many refusals followed the last release. Nothing here needs special talent, just a regular rhythm. Certifications and courses can help you learn the vocabulary, and the case made in the practical benefits of becoming DevOps certified is a fair overview of what formal learning adds.
What good looks like after a year
The Atlas sketches a five-stage ladder, and the top stage is wonderfully dull: removing a permission causes no incident because the team already knows what depends on it. Reaching it takes patience rather than cleverness. People ask for access through a request, get a narrow card that expires, and a monthly look keeps old cards from piling up. If that sounds like a quiet office, that is exactly the goal.
Your first small step
Pick one role in your own sandbox account, and set aside twenty minutes. Write down in plain words what it should be able to do. Compare that sentence with the actual policy, and delete one permission you cannot explain. If something breaks, you have learned what the permission was for, and the change was reversible. Repeat next week. When you want a wider map of skills to learn around this, a roadmap covering skills, projects and certifications for DevOps engineers can point you toward the next topics.