Zero-Secret Workloads
Overview
Long-lived credentials — API keys, service account passwords, static access tokens — are convenient but carry significant risk. A single leaked secret can persist undetected for months and grant an attacker the same level of access as the pipeline it was meant to serve.
The industry has converged on a better model: federated workload identities combined with short-lived credentials that are scoped to exactly the access a workload needs for a single execution.
Britive builds on this model by acting as an authorization broker — it verifies a workload’s federated identity, evaluates access policies, and creates a short-lived service principal with only the permissions requested. That service principal is destroyed when the task completes or the session expires. No stored secrets. No standing access.
The Problem with Shared Secrets
| Characteristic | Long-Lived Secrets | Federated Short-Lived Credentials |
|---|---|---|
| Stored in CI/CD system | Yes — in secrets store or env vars | No |
| Rotation required | Yes — manually or on a schedule | N/A — new credential each run |
| Blast radius if leaked | High — credential is valid until rotated | Low — expired within minutes |
| Audit granularity | Per-key, hard to attribute to a specific run | Per-checkout, tied to a specific workload execution |
| Standing privileges | Yes | No — zero standing privileges |
How Britive Federated Access Works
Every leading CI/CD and cloud platform supports workload federation. AWS STS, GCP Workload Identity Federation, and the OIDC token issuers built into GitHub Actions, GitLab, and SpaceLift all allow a workload to assert its identity without a pre-shared secret.
Britive integrates with these mechanisms as the authorization layer on top of identity verification.
The Six-Step Flow
flowchart LR
A["Identity Assertion<br/>workload fetches a signed, short-lived JWT from its platform"]
B["Token Verification<br/>Britive verifies the JWT signature and claims"]
C["Policy Evaluation<br/>Britive evaluates access policies for the federated principal"]
D["Principal Creation<br/>Britive creates a short-lived service principal at the target cloud provider with the requested permissions"]
E["Credential Delivery<br/>Britive returns the short-lived credentials to the workload"]
F["Principal Destruction<br/>Britive destroys the service principal when the task completes or the session expires"]
A --> B --> C --> D --> E --> F
Steps 4 and 6 are what distinguish Britive from a pure identity federation provider. Rather than mapping a federated identity to an existing long-lived service account, Britive creates and destroys the service principal on demand — eliminating any standing account that could be taken over.
Step-by-Step Detail
Identity Assertion
The workload requests a signed identity token (JWT) from its platform. This token is short-lived, created fresh for each execution, and cryptographically signed by the platform’s OIDC issuer. It asserts who the workload is — not what it can do.
| Platform | Token Source |
|---|---|
| GitHub Actions | ACTIONS_ID_TOKEN_REQUEST_URL — requested per job via id-token: write permission |
| GitLab | CI/CD OIDC token issued per pipeline job |
| SpaceLift | Built-in OIDC token per run |
| AWS (EKS / EC2) | Instance metadata service or projected service account token |
| GCP | Workload Identity Federation token exchange |
Token Verification
Britive validates the JWT against the issuer’s public keys and checks the claims — audience, subject, expiry. If validation fails, the request is rejected before any access is granted.
Policy Evaluation
Britive evaluates the configured access policies for the verified principal. Policies can restrict access by time of day, IP range, require approval, or limit the maximum session duration. Only if all conditions are met does Britive proceed.
Short-Lived Service Principal Creation
Britive creates a new, scoped service principal at the target cloud provider (e.g. an AWS IAM role session, a GCP service account key, an Azure managed identity token) with only the permissions defined in the profile. This principal does not exist before the checkout request and cannot be reused across runs.
Credential Delivery
The short-lived credentials are returned to the workload — via the Britive CLI, PyBritive, or the REST API — and injected into the pipeline environment for use.
Destruction
When the profile’s expiration duration passes (or an explicit check-in occurs), Britive destroys the service principal. There is no residual account, no key to rotate, and no standing privilege to attack.
Supported Platforms
Britive federated workload access has been validated with the following platforms:
| Platform | Federation Mechanism | Notes |
|---|---|---|
| GitHub Actions | OIDC (id-token: write permission) | Requires permissions: id-token: write in the workflow job |
| GitLab CI/CD | OIDC CI token | Available from GitLab 14.7+ |
| SpaceLift | Built-in OIDC token per run | — |
| AWS EKS | Projected service account tokens (IRSA) | — |
| GCP | Workload Identity Federation | — |
Integration Methods
| Method | Description | Best For |
|---|---|---|
| Britive CLI | Shell command — britive checkout | Standard pipeline script steps |
| PyBritive | Python library wrapping the CLI and REST API | Python-based automation, Lambda functions |
| REST API | Direct HTTP calls to the checkout endpoint | Non-shell runtimes, custom tooling |
A working GitHub Actions example using PyBritive — checking out AWS permissions to update an S3 bucket with no stored secrets — will be linked here once the examples repository is published.
Platform-Specific Guides
For configuration details, CLI flag references, and example workflow files for each supported CI/CD platform: