Roles and access¶
Attest has four roles. They are assigned in your identity provider, never inside Attest. A person's role decides what they see; GitLab decides what they can do.
The four roles¶
| Role | Lands on | Sees | Can |
|---|---|---|---|
| Viewer | Security posture | Security posture, every application, every evidence view, every decision. | Read. Never offered the GitLab connect step. |
| Engineer | My applications | Their own applications, gate findings, the worklist, base images, reviewer feedback verbatim. | Update, fix, and submit through their pipeline. No authorize controls. |
| Reviewer (SCA) | Review | The queue, every package, every evidence view, security posture. | Claim, accept or reject each finding with a basis, authorize by approving the merge request as themselves, reject with a reason. |
| Administrator | Review | Everything above, plus system health, the registry, the audit view of all decisions and claims, and recon. | Release a stuck claim with a visible note, trigger a refresh, select the Explainable AI model. Cannot approve for anyone else. |
Role names in the identity provider: attest-viewer, attest-engineer, attest-sca, attest-admin. A person with none of them can sign in and sees a page saying they have no role in Attest.
Three powers, kept apart¶
| Power | Held by | How |
|---|---|---|
| Console access and role | The identity provider | Single sign on. Roles are realm roles carried in the token. |
| Acting in GitLab as a person | The person's own GitLab identity | Per user consent, once. Every approval, comment, and close runs on the person's own short lived token. GitLab enforces its permissions regardless of console role. |
| Reading the fleet | A project owned read only token | No human identity, cannot write anywhere. |
Humans hold zero long lived keys. No bot ever approves on behalf of anyone.
Sessions¶
Sessions are server side and expire on a fixed schedule. The console never holds a token. A session that expires mid page sends you back to sign in and returns you to where you were.
Who sees which containers¶
An engineer sees the containers their group claims match: the organization and application declared in each container's cdso_config.yml. A reviewer sees every submission in the security groups they review for. A viewer and an administrator see everything.
GitLab permissions¶
For reviewers: Developer access or above on the security repository for their security group. Nothing on the application repositories. For engineers: whatever access they already have on their own repository; the pipeline and the security repository are read for them.