Argo CD

Overview

Argo CD integration with Britive follows a different pattern from push-based CI platforms. Because Argo CD is a GitOps controller that continuously reconciles cluster state, the integration points are:

Integration Point	Pattern
Pre-sync hooks	Check out credentials before a sync operation that requires elevated access
Post-sync hooks	Check in or confirm expiry after sync completes
Argo CD Notifications	Trigger Britive access requests in response to sync events
CLI / API in Init Containers	Inject short-lived credentials into application pods at startup

Prerequisites

Requirement	Details
Britive service identity	Create a service identity; store the token as a Kubernetes secret in the Argo CD namespace
Britive profile	Profile must be active with an expiration duration and a policy granting the service identity access
Argo CD sync hooks enabled	Resource hooks (`PreSync`, `PostSync`) must be permitted in your Argo CD configuration
Access to Argo CD namespace secrets	The hook `Job` or init container must be able to read the Kubernetes secret holding `BRITIVE_API_TOKEN`

Environment Variables

Variable	Required	Where to Set	Description
`BRITIVE_API_TOKEN`	Yes	Kubernetes secret (referenced in hook Job or init container)	Service identity token — PyBritive reads this automatically
`BRITIVE_TENANT`	Yes	Kubernetes ConfigMap or secret	Britive tenant subdomain (see Finding Your Tenant Name)
`BRITIVE_PROFILE`	No	Hook Job spec `env`	Profile to check out, as `Application/Environment/Profile`

Pre-Sync Hook Pattern

Use an Argo CD PreSync hook to check out credentials before the sync operation runs. The hook is a Kubernetes Job that runs the Britive CLI or calls the REST API.

hook-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: britive-presync-checkout
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: britive-checkout
          image: python:3.12-slim
          command: ["/bin/sh", "-c"]
          args:
            - |
              pip install --quiet pybritive==2.3.2
              pybritive checkout "$BRITIVE_PROFILE" -m json > /dev/null
          env:
            - name: BRITIVE_PROFILE
              value: "AWS Production/Prod Account/argocd-sync"
            - name: BRITIVE_TENANT
              valueFrom:
                configMapKeyRef:
                  name: britive-config
                  key: tenant
            - name: BRITIVE_API_TOKEN
              valueFrom:
                secretKeyRef:
                  name: britive-credentials
                  key: token

Hook Jobs run in the same namespace as the Argo CD application. Ensure the service account for the hook Job has only the permissions needed to read the Britive secret — nothing more.

Init Container Pattern

For applications that need cloud credentials injected at pod startup, use an init container that checks out a Britive profile and writes credentials to a shared emptyDir volume.

deployment.yaml

spec:
  initContainers:
    - name: britive-checkout
      image: python:3.12-slim
      command: ["/bin/sh", "-c"]
      args:
        - |
          pip install --quiet pybritive==2.3.2
          pybritive checkout "$BRITIVE_PROFILE" -m json > /var/run/britive/credentials.json
      env:
        - name: BRITIVE_PROFILE
          value: "AWS Production/Prod Account/app-runtime"
        - name: BRITIVE_TENANT
          valueFrom:
            configMapKeyRef:
              name: britive-config
              key: tenant
        - name: BRITIVE_API_TOKEN
          valueFrom:
            secretKeyRef:
              name: britive-credentials
              key: token
      volumeMounts:
        - name: britive-creds
          mountPath: /var/run/britive
  volumes:
    - name: britive-creds
      emptyDir:
        medium: Memory   # store credentials in RAM, not on disk

Using emptyDir with medium: Memory keeps credentials out of node disk storage. Credentials in the volume are lost when the pod terminates.

REST API Usage

When a shell isn’t available in the hook container, call the Britive REST API directly. Authenticate with the service identity token in the Authorization: TOKEN <token> header. See the Britive API documentation for endpoint details.

Argo CD Notifications Integration

Argo CD Notifications can call a webhook when a sync event occurs. Pointing this webhook at the Britive API enables event-driven checkout and checkin tied directly to application lifecycle events.

Notification Trigger	Britive Action
`on-sync-running`	Check out the target profile
`on-sync-succeeded`	Check in the profile (or allow it to expire)
`on-sync-failed`	Alert on access that may still be active

Security Considerations

Practice	Why It Matters
Store `BRITIVE_API_TOKEN` in a Kubernetes secret, not a ConfigMap	Secrets are base64-encoded and can be restricted with RBAC; ConfigMaps are not
Use a dedicated namespace for hook Jobs	Isolates the blast radius of the service identity
Set `hook-delete-policy: HookSucceeded`	Cleans up hook Jobs after success, reducing noise in the cluster
Use short expiration durations	Credentials should expire before or shortly after the sync completes

Last updated on July 8, 2026