Secrets

Our approach

Secrets are the one thing that must never live in Git, even though everything else does. The platform resolves this with a simple rule: Git holds references to secrets, never the secret material itself. Actual values live in the Engineering Vault in 1Password, and workloads obtain short-lived AWS credentials at runtime through scoped identities — so a leaked repository is never a leaked secret.

A leaked repo should never be a leaked secret. If you are about to commit a key, token, or password, stop — it belongs in 1Password with a reference in Git, not in the diff.

The diagram below shows how secret values, Git references, and short-lived AWS credentials flow together so that no single leaked artifact exposes a working credential.

flowchart TD
  subgraph HumanWork["Human work"]
    OP["1Password Engineering Vault"]
    Git["Git repo"]
  end
  subgraph Automation["Automation"]
    AWS["AWS IAM / IRSA"]
  end
  subgraph Runtime["Runtime"]
    Pod["Running workload"]
  end
  OP -->|"sync at runtime"| Pod
  Git -->|"reference only"| Pod
  AWS -->|"short-lived credential"| Pod
  style Pod fill:#dcfce7,stroke:#16a34a,color:#14532d

Where secrets actually live

The Engineering Vault (1Password)

The Engineering Vault in 1Password is the system of record for credentials and service tokens. It enforces role-based access, encryption, and audit logging for every secret-access event — so each read is attributable. Git references a secret; 1Password holds it; the value is synced to the workload at runtime rather than baked into an image or a manifest.

AWS service accounts and short-lived credentials

For access to AWS services, workloads use AWS service accounts with scoped IAM roles and short-lived credentials rather than long-lived keys. This minimizes exposure and aligns with Zero Trust: a credential that lives for minutes and grants only what one task needs is a small target.

How workloads get AWS access: IRSA

Inside the clusters, pods authenticate to AWS through IAM Roles for Service Accounts (IRSA) (IAM Roles for Service Accounts — a mechanism that lets a Kubernetes pod assume an AWS IAM role without a stored credential). Each runner or workload assumes a scoped IAM role granting access only to the AWS services its operation requires — and nothing more. There are no static cluster-wide AWS keys to leak; the identity is bound to the Kubernetes service account and brokered by AWS. This is the same mechanism that keeps the deployment runners environment-scoped (see Environments).

GitHub-to-cluster trust works the same way: the self-hosted runners connect over TLS using OIDC federation rather than stored credentials (see the boundary-and-ports table in Networking).

The principles

Git holds references, not values. No plaintext secret is ever committed — encrypted-at-rest repository or not.
Short-lived over long-lived. Prefer credentials that expire in minutes (IRSA, service accounts) to static keys that live until someone remembers to rotate them.
Scoped to the task. Every identity grants the least privilege its operation needs, validated continuously rather than assumed.
Every access is audited. 1Password logs each secret read; IAM logs each role assumption. Access to a secret is attributable to an actor and a time.
Federated identity. Human access is centralized through central SSO; machine access is federated through IRSA/OIDC — neither relies on shared passwords.

Examples

Do / Don’t

Do	Don’t
Store secrets in the 1Password Engineering Vault, reference them from Git	Commit a key, token, or password to a repo
Use IRSA / scoped service accounts for AWS access	Mint long-lived static AWS access keys
Let credentials be short-lived and auto-rotated	Reuse one credential across environments
Grant the minimum scope a task needs	Attach broad policies “to be safe”
Rely on SSO (central SSO) and OIDC federation	Share a password between people or services

Where it’s enforced

Pre-commit secret scanning stops a key, token, or password from ever reaching the diff — the first line of defense behind “a leaked repo should never be a leaked secret.”
1Password access controls and audit logs enforce role-based access and make every secret read attributable to an actor and a time.
IAM / IRSA / OIDC broker short-lived, scoped machine credentials so there are no static cluster-wide keys to leak, and log each role assumption.
Rotation cadence. Credentials are short-lived and auto-rotated where possible; longer-lived material is rotated at least annually, and immediately after suspected exposure, role change, or vendor offboarding.

Verification

How we confirm these controls are real, not aspirational. These checks run on a recurring basis — 1Password and IAM reports are reviewed quarterly; the credential checklist is completed annually as part of the compliance cycle:

Evidence	Confirms
1Password audit reports	MFA enforcement and credential rotation
AWS IAM Access Analyzer reports	Least-privilege role configuration
Annual credential review checklist	Compliance with NIST AC (Access Control) and IA (Identification & Authentication) controls

ATO evidence

Secret-management evidence should show that credentials are created, stored, accessed, rotated, and retired through controlled systems. Retain secret-scan results, 1Password access reports, IAM role-assumption logs, credential rotation records, and exception approvals for any remaining long-lived credential.

Evidence	Supports
Secret-scan result	`IA-5`, `SI-2`
1Password access and MFA report	`AC-6`, `IA-5`
Rotation record and IAM assumption log	`SC-12`, `SC-13`