Roles in Entitlements as Code
Who asks, who approves, who runs it and who checks it, and what each role never does.
Entitlements as Code works because each decision sits with the person best placed to make it, and because nobody decides on their own access. These are the roles, in the order a grant meets them.
The five roles
Requester
Anyone who needs access. They ask for one group, write why and until when, and follow their request. They can ask to leave a group the same way. Never: approves their own request.
Owner
The people responsible for a group, usually the lead of the team or the project the group gives access to. They approve or decline requests to join, review the members on a schedule, and remove access that is no longer needed. A group has at least one owner; sensitive groups have two. Never: approves a request they asked for, edited or benefit from.
EaC admin
The people who look after the access process itself: the approval rules, the checks, which organizations observe and which enforce, and the drift report. Switching an organization from observe to enforce is a change they propose and others review. Never: acts as a shortcut that approves access to every group.
IT team
The team that runs the identity provider and the platforms. They connect platforms to groups, keep the automation running, and handle the cases the process does not cover. With Entitlements as Code they stop copying approved changes by hand into each tool. Never: changes access by hand without that change showing up as drift.
Auditor and security
The people who check that access is granted properly. They read the history in Git: who asked, who approved, when it was applied, when it ended, and what the reviews decided. Never: needs a spreadsheet built for them before an audit.
Who does what
| Step | Who | What they do |
|---|---|---|
| Request | Requester | Asks, with a reason and an end date |
| Approve | Owner | Approves or declines |
| Approve | EaC admin | Sets the approval rules |
| Apply | IT team | Keeps the automation running |
| Reconcile | Owner | Decides on drift in their groups |
| Reconcile | EaC admin | Watches the drift report, chooses observe or enforce |
| Review | Owner | Keeps or removes each member |
| Review | EaC admin | Schedules the reviews |
| Review | Auditor | Checks that reviews happen |
| End | Requester | Asks to leave a group |
| End | Owner | Removes access that is no longer needed |
| End | Auditor | Checks that access ends |
| Audit | Auditor | Reads the history in Git |
Changes that need two people
Some changes decide who decides. Adding or removing an owner, or an EaC admin, needs the approval of two different people, none of whom proposed it. Changing an approval rule or switching an organization to enforce needs an EaC admin who did not propose it. Either way, nobody can give themselves the power to approve their own access later.
Where to go next
- The framework: the lifecycle these roles act on.
- Maturity model: how the roles grow as a team moves from observing to enforcing.