Skip to content

Security Model

The security model defines how the tenant classifies privileged access, and how changes are delivered safely at each level of privilege. It sets the rules that every other platform engineering page applies. It covers what makes something Tier 0, 1 or 2, and why Tier 0 change is never applied by a pipeline.

Read these pages in order. The first defines the tiers, the second maps real roles onto them, and the last two define how each tier is delivered:

Where the model is applied:


Tiers and lanes at a glance

Tier EAM plane Examples Delivery lane Apply by
Tier 0 Control plane Tenant root and intermediate root management groups, Entra directory roles and PIM, service principal vending, tenant root state Lane A A PIM-elevated human, locally, after MR review
Tier 1 Management plane mg-platform, connectivity and management subscriptions Lane B CI on merge, with a scoped OIDC identity
Tier 2 Data/Workload plane mg-landingzones and workload subscriptions Lane B CI on merge, with a scoped OIDC identity

Principles

  • Classify by function, not breadth. A role is Tier 0 if it can control identity or access itself, not because its scope covers many subscriptions.
  • Anything that can control Tier 0 is Tier 0. A pipeline with Tier 0 write access makes GitLab, its runners and its templates Tier 0 too. That is why Tier 0 CI is plan-only.
  • No standing privilege at Tier 0. Tier 0 access is activated just-in-time through PIM, with justification, approval and an audit record.
  • Separate review from activation. Merging an MR proves the code is correct. Applying it at Tier 0 needs a separate, logged PIM elevation by a named person.
  • Automate everything else. Tier 1 and 2 changes use full GitOps, so the human gate is kept for the few changes that need it.