Entitlements as Code by MoreThanOps

Blog

Drift: what happens when someone grants access by hand in Entra

By ·

Git is only the source of truth for access if Entra agrees with it. Sooner or later, someone with admin rights adds a person to a group directly in the Azure portal: a quick fix during an incident, a favour for a colleague, a step skipped under pressure. That change has no request, no reason and no approver. This post follows one such change and shows what Entitlements as Code does with it, depending on how the organization is set up.

The scenario

Ana works at ACME, a fictional company. She has asked for Contributor on the web-platform project, and her request is waiting for Marco, the group's owner. Someone decides not to wait and adds Ana to the WebPlatform Contributors group by hand in the Azure portal. Through the group, she now has the access.

Git does not list her. Entra and Git now disagree, and that difference is drift.

One change made by hand, two outcomes: put back to what Git says, or reported for a person to decide.

If the organization enforces: back to what Git says

In an organization in enforce mode, Git is the record, and anything else is a mistake by definition. The membership Ana got by hand is removed on the next check of the group, about a minute in our tests, and the audit log in Entra shows that Entitlements as Code removed it.

Ana is not stuck. The way to get the access is the one already open: her request, approved by Marco.

Owners work the same way. An owner added by hand is removed, and the group's owners go back to the ones on record. A group with no owners on record is the exception: its Entra owners are left alone, so a team can bring owners under Git one group at a time.

If the organization observes: reported, and a person decides

Observe mode is read-only. Nothing is written to Entra, so Ana keeps the access she was given by hand. What changes is that it is no longer invisible: the web app's Drift page lists it, with who added it, to which group, and when.

From there, a person decides, with one click:

  • Bring into Git, if the access is right. It opens a pull request that adds Ana to the group's file, and the group's owner approves it like any request. From then on the access has a record.
  • Remove, if it is not. It opens a pull request that removes her, approved the same way.

Either way, nothing is removed by a job on its own. Taking access away from someone is a decision, so it stays with the owner, made with a request and recorded like any other.

Drift is not only additions. A member removed by hand, or a group created in Entra that Git does not know about, shows up too.

Side by side

Situation A member added by hand
The organization enforces Removed, back to what Git says, about a minute in our tests
The organization observes Kept for now, listed on the Drift page, brought into Git or removed by its owner

An organization can move from one to the other over time. Observe suits the period when access is still partly granted by hand and Git is catching up. Enforce suits an organization whose records are trusted.

Access that should end, ends

Drift covers access granted outside Git. The other half of keeping access clean is access that was granted properly but is no longer needed.

  • End dates. A request can say until when. When the date comes, the access ends on its own. The approval already covered the end date, so nobody has to approve it again or remember it, and a pull request tidies the expired line out of Git.
  • Access reviews. Owners review their groups on a schedule. For each member they choose to keep or remove, and every removal is a request with a reason, recorded like any other.
Reviews and end dates: access that is no longer needed is removed through Git, like any other change.

Together they answer the questions an audit asks: who has access, who approved it, until when, and who checked that it is still needed.