CI/CD & DevOps

Integrate Britive with pipelines, deployment workflows, and zero-secret workload patterns.

Britive can be embedded directly into automated pipelines to issue short-lived cloud credentials at job runtime — no long-lived secrets stored in your CI system.

New here? Start with Zero-Secret Workloads — it explains the federated identity model that underpins all CI/CD integrations.

The two integration methods are:

Method	Best For	How It Works
Britive CLI	Scripted pipelines, shell-heavy workflows	Call `britive checkout` in a pipeline step; credentials are written to env vars or a named profile
REST API	Custom tooling, non-shell runtimes, advanced orchestration	Call the checkout endpoint directly; parse the JSON response and inject credentials into the job environment

The Core Pattern

Regardless of platform, every pipeline integration follows the same lifecycle:

    flowchart LR
    A["Authenticate<br/>workload asserts its identity via a federated JWT token"]
    B["Verify<br/>Britive verifies the token and evaluates access policies"]
    C["Checkout<br/>Britive creates a short-lived service principal with scoped permissions"]
    D["Use<br/>credentials are available for the duration of the job"]
    E["Destroy<br/>Britive destroys the service principal when the session expires"]

    A --> B --> C --> D --> E

Each job run gets a fresh service principal. There is no credential reuse between runs and no standing account that persists after the session ends.

Authentication in Pipelines

Pipelines authenticate to Britive as a service identity. Store the service identity token as an encrypted secret in your CI platform and pass it via the BRITIVE_API_TOKEN environment variable.

Environment Variable	Required	Description
`BRITIVE_API_TOKEN`	Yes	Service identity token for the pipeline
`BRITIVE_TENANT`	Yes	Your Britive tenant subdomain (e.g. `company`) — see Finding Your Tenant Name