Declarative Access

The Principle

Define identity in configuration, not in consoles. Users, groups, roles, memberships, and permissions are described in structured configuration files. These files declare the desired state, not the steps to achieve it. A new team member is not a sequence of actions. They are a declaration of who they are and what they should access.

Why Imperative Fails

The traditional model is imperative: open a console, click “create user,” select permissions from a dropdown, click save. This works for one user in one system. It fails beyond that. The admin interprets a ticket differently each time. Two admins produce different results from the same request. The action is ephemeral: once the clicks are done, the only record is a log entry buried in an admin console that few people read.

Declarative definitions address this class of problems. The configuration is precise, reviewable, and produces the same result regardless of who applies it or when. There is no room for interpretation, no variation between executions, no gap between what was intended and what was done.

Beyond Individual Systems

In a multi-platform environment, declarative identity means that a single set of configuration files describes a person's access across all the services they touch. The declaration is abstract: “this person is a senior engineer on the payments team”, and the concrete permissions in each downstream platform are derived from that abstraction. The person is defined once; the systems interpret that definition according to their own rules.

Upstream: People Come From Somewhere

The configuration repository is the authoritative record of access state, but it is not the origin of identity data. A person's name, manager, department, and employment status come from upstream systems: HR platforms, directories, employment databases. The declarative access model consumes these as inputs. When someone's employment ends in the HR system, the access system detects the change and triggers revocation. When someone transfers departments, the new team assignment flows through.

The repo owns what access a person has. The HR platform owns who the person is and where they sit in the organization. These are different responsibilities and they must not be conflated.

Antipatterns

• Access is provisioned by clicking through admin consoles, not by editing configuration.
• Two admins interpret the same request and produce different results.
• The only record of an access change is a log entry buried in an admin console.
• No one can reproduce a person's access without opening each system individually.