Entitlements as Code by MoreThanOps

The Entitlements as Code maturity model

Three levels, from access written down in Git to access that is requested, enforced, reviewed and ended.

Last reviewed

Nobody adopts Entitlements as Code in one go, and nobody should. The maturity model describes three levels, each useful on its own. A company can sit at different levels in different organizations: one enforcing, another still observing.

Level In one sentence Typical length
1. Recorded Access is in Git and requests go through it; nothing is written to the platforms yet Weeks
2. Enforced Approved changes are applied, and hand changes go back to what Git says, one organization at a time Months
3. Governed Every platform follows the groups, access ends on time, and owners review it on a schedule Ongoing

Level 1: Recorded

Signs. The groups that exist today, with their members and owners, are files in Git. People ask for access through the new process and owners approve there. Nothing is written to the identity provider by the process: it only reads, and reports differences.

Practices.

  • Import the current state of each organization into Git, one file per group.
  • Make sure every group has an owner, and sensitive groups have two.
  • Route new requests through pull requests, even if the change is still applied by hand.
  • Read the drift report weekly and decide what each difference means.

Metrics. Share of groups in Git; share of groups with an owner; number of differences between Git and the platforms, and its trend.

Ready to move up when the files match the platforms, owners answer requests, and the drift report is short and understood.

Level 2: Enforced

Signs. In the organizations that enforce, approved changes are applied automatically and changes made by hand go back to what Git says. Other organizations may still be at level 1.

Practices.

  • Switch one organization at a time, with a reviewed change, starting with the one whose owners are most ready.
  • Decide, per organization, whether a hand change is put back at once or becomes a request for its owner.
  • Keep automated checks on every request: naming, sensitive groups, owners present.
  • Tell people that access changed by hand will not last, and why.

Metrics. Share of grants with an approver who is not the requester; time from request to access; number of hand changes put back, by group.

Ready to move up when every organization enforces, hand changes are rare, and owners trust the process.

Level 3: Governed

Signs. Every platform that matters follows the groups. Temporary access carries an end date and ends on its own. Owners review their groups on a schedule, and the history answers an auditor's questions without extra work.

Practices.

  • Connect the remaining platforms to groups, so that no access is granted outside the process.
  • Ask for an end date on every temporary grant, and set a maximum for sensitive groups.
  • Run access reviews on a schedule, with each owner keeping or removing each member.
  • Use the history in Git as the evidence for audits.

Metrics. Share of grants with an end date; share of reviews completed on time; members removed per review; access that ended on its end date; time to answer an audit question.

How to measure

The metrics come from the history in Git and the drift report, so they cost nothing extra to collect:

  • Coverage: groups in Git divided by groups on the platforms.
  • Ownership: groups with at least one owner (two for sensitive groups) divided by all groups.
  • Separation of duties: grants approved by someone other than the requester divided by all grants.
  • Drift: differences found per week, and how long each one lasts.
  • Lead time: time from request to access applied.
  • Hygiene: grants with an end date, reviews completed on time, members removed per review.

Where to go next