Identities and access
On Airframe, nobody’s everyday account can change production infrastructure, and no machine holds a password that works forever. Pipelines get identities that last an hour and only fit one job; people can look, and when they truly need to change something by hand, they ask for access that is time-boxed, approved by someone else and written down. This page explains how both work, one level deeper than the zero standing privilege page.
Who acts on the platform
Section titled “Who acts on the platform”Three kinds of identity touch Google Cloud:
- Pipeline identities are Google service accounts that Terraform runs as. Each platform root has its own, such as the project factory’s, and each product has its own plan and apply identities in each of its projects.
- Runtime identities belong to a product’s running services. Each service gets its own, with exactly the secrets, database and topics it uses.
- People sign in with their organization accounts. Their access comes through Google groups that the catalog’s reconcilers fill, such as the group of a team or the group of a product’s users.
How a pipeline job gets an identity
Section titled “How a pipeline job gets an identity”A pipeline job never holds a key. Instead it uses workload identity federation:
- The job asks GitLab for a signed token. The token states which repository the job belongs to, which environment it deploys to, and whether its branch is protected.
- Google Cloud’s identity provider checks the token. A token from outside the
projectairframegroup in GitLab is refused before anything else is read, so a copy of a repository in someone’s personal namespace gets nothing. - The provider combines the three facts into one value, for example the orders repository, the environment
prodandtruefor protected. Each identity is bound to exactly one such value. - If the value matches, the job receives an access token for that one identity, valid for an hour.
A job on an unprotected branch, in another repository or in another environment matches no binding and gets nothing. A renamed repository loses its bindings, and the path of a removed product is never reused, so a new repository cannot inherit an old one’s access.
Plan identities and apply identities
Section titled “Plan identities and apply identities”Each product has two pipeline identities in each of its projects:
- The plan identity can read the project and the Terraform state, and change nothing. It is bound to no repository at all: only the executor can use it, when the gate starts a run at a merge request’s approval.
- The apply identity can change the project. The production one answers only to a job of the product’s own repository, on a protected branch, in the environment
prod, orgrafanafor the root that publishes the product’s dashboards. The non-production one answers tonp, and the executor also uses it to build a merge request’s preview.
The executor can use every plan identity and every non-production apply identity, and no production apply identity. So nothing that runs before a merge can change production.
What people get
Section titled “What people get”People’s standing roles are viewer roles: they can read a project and its logs, not change it. The one narrow exception is that a product’s team may add a new version of one of the product’s secrets; it can never read one.
When a person needs more, they request a Privileged Access Manager grant with a written reason. Airframe has four kinds:
| Grant | What it gives, who approves it and how long it lasts |
|---|---|
| Level 1 | Read access to the logs, metrics and state of a non-production project, today only the platform’s runtime project, lk-runtime-np. Approved by: the requester, with a reason. Lasts: 1 hour. |
| Level 2 | Administrative roles on the demo organization’s folder, for a fix by hand. Approved by: another member of the platform group. Lasts: 2 hours. |
| Platform apply | The roles for the few platform roots that are still applied from a laptop. Approved by: another member of the platform group. Lasts: 2 hours. |
| Organization | The roles for changes at the organization level. Approved by: another member of the platform group. Lasts: 2 hours. |
Members of the break-glass group, lk-breakglass@, can request the first three grants. The organization grant is requested by members of the platform group, lk-platform@, and every approver comes from that group too. Privileged Access Manager never lets a requester approve their own request for the grants that need approval. Every grant is in the audit log.
Level 1 exists today only on the platform’s non-production runtime project. No project factory creates it for a product’s non-production project yet, so level 1 grants on product projects are designed.
Three platform roots are still applied from a laptop under such a grant: the organization’s policies, the audit configuration, and the root that creates the identity provider and every platform root’s identity. A pipeline that could rewrite the identity model would be the platform’s most powerful one, so it stays behind a second person. Each of these roots is planned every day by a scheduled pipeline whose identity can only read, so a change made under a grant shows up as drift within a day.
Today one person runs the platform, and the second approver is the maintainer’s second account: the mechanism is enforced, but the separation between two people is not yet real.
No keys
Section titled “No keys”A service account key is a long-lived password for a machine identity, and Airframe does not allow one. Organization policies on the demo organization’s folder forbid creating or uploading keys, and a deny policy blocks key creation for everyone except the break-glass group, the bootstrap administrator account and Privileged Access Manager’s own service agent. The policy pack also refuses a key declared in Terraform. Credentials come from a job’s token or, for a running service, from the metadata server of the place it runs.
The one administrator account
Section titled “The one administrator account”One dedicated account holds Organization Administrator, the role at the top of the organization. It is used only for the bootstrap and for exceptional procedures, and is otherwise signed out. A scheduled job in the landing-zone repository asks Google’s Policy Analyzer every day who holds which role at the organization, and fails if any person holds a role there other than that account’s Organization Administrator, or if any group holds one.
Where it lives
In the landing-zone repository: