CI/CD and Kubernetes

Run provider APIs from pipelines and pods without spreading raw keys.

VaultProof gives jobs and workloads VaultProof-routed values instead of original provider credentials. Your existing secrets manager can keep handling infrastructure secrets while VaultProof narrows exposure for outbound third-party API keys.

Start setup Security model
Where it fits
  1. 1Protect provider keys with vaultproof-init.
  2. 2Store VaultProof values in CI variables or Kubernetes Secrets.
  3. 3Route SDK traffic through provider-compatible base URLs.
  4. 4Monitor usage, errors, and unusual traffic from the dashboard.

Model

VaultProof protects provider API credentials, not every secret in the cluster.

Use VaultProof for third-party API keys such as AI, payments, email, observability, and SaaS providers. Keep using your current secrets platform for database passwords, workload identity, TLS material, and infrastructure credentials.

Before

Raw provider keys sit in CI variables, build logs, copied env files, deployment manifests, and pod environments.

After

Jobs and workloads receive VaultProof values and provider-compatible base URLs instead of original provider credentials.

Result

An exposed pipeline variable or pod env dump no longer directly reveals the provider credential that can be used outside VaultProof.

Plain-language boundary A VaultProof token is still a runtime credential. Protect it, scope it, monitor it, and rotate provider keys if the original provider key was ever exposed.

Setup

Run init before you publish values into CI or Kubernetes.

The hosted init handles provider detection and writes the VaultProof values your app needs. Do the setup from a trusted local checkout or controlled setup job, then move the generated values into your deployment system.

  1. 1

    Install the hosted init

    Run the installer from the project folder that contains your app environment files.

    Project root
    curl -fsSL https://vaultproof.dev/install | sh
vaultproof-init
  2. 2

    Review the generated values

    Confirm the VaultProof token and provider base URLs were written for the providers your workload actually calls.

  3. 3

    Publish only VaultProof values

    Move the generated VaultProof values into CI/CD variables, Kubernetes Secrets, or your deployment platform. Remove the old raw provider keys from those places.

Pipelines

CI jobs should receive the VaultProof token, not the original provider key.

For SDK-compatible providers, keep the environment variable names your app already expects, but point them at VaultProof-managed values and base URLs.

Before

Pipeline variables contain the raw provider secret.

Avoid this
OPENAI_API_KEY=sk-proj-...
ANTHROPIC_API_KEY=sk-ant-...

After

Pipeline variables contain VaultProof-routed values.

Use this pattern
VAULTPROOF_PROJECT_ID=vp-proj-...
OPENAI_API_KEY=vp-proj-...
OPENAI_BASE_URL=https://init.vaultproof.dev/p/openai/v1
GitHub Actions example
env:
  VAULTPROOF_PROJECT_ID: ${{ secrets.VAULTPROOF_PROJECT_ID }}
  OPENAI_API_KEY: ${{ secrets.VAULTPROOF_PROJECT_ID }}
  OPENAI_BASE_URL: https://init.vaultproof.dev/p/openai/v1

Kubernetes

Store VaultProof values in Kubernetes, then map them into the workload.

The deployment pattern stays familiar: create a Secret, mount the values as environment variables, restart the Deployment, and watch one request in Activity before broad rollout.

Create a workload Secret
kubectl create secret generic app-env \
  --from-literal=VAULTPROOF_PROJECT_ID=vp-proj-... \
  --from-literal=OPENAI_API_KEY=vp-proj-... \
  --from-literal=OPENAI_BASE_URL=https://init.vaultproof.dev/p/openai/v1
Reference from a Deployment
envFrom:
  - secretRef:
      name: app-env
Server-side workloads If a workload does not send browser Origin headers, do not rely on browser-origin rules alone. Use environment scoping, budgets, alerts, provider rotation, and workload-level network controls.

Controls

Use operational controls around every pipeline and workload token.

VaultProof reduces raw-key spread, but the generated runtime values still need normal operational discipline.

Separate environments

Use separate VaultProof values for development, staging, and production so a lower environment cannot quietly spend production budget.

Watch request patterns

Review Activity for provider, endpoint, status, latency, and error changes after a deployment.

Budget and alert

Set practical usage limits and alerts before giving a job or workload sustained customer-facing traffic.

Rotate when exposed

If a raw provider key reached CI variables, logs, or manifests, rotate it at the provider before treating cleanup as complete.

Boundaries

Threat coverage is strongest where raw provider keys used to spread.

This is the clearest way to position VaultProof next to your current CI/CD, Kubernetes, and secrets-management controls.

Class How VaultProof helps Still required
Env leaks Raw provider keys are removed from common runtime env values. Protect VaultProof tokens and remove old raw values.
CI logs Accidental variable dumps should not reveal original provider credentials. Mask variables, restrict logs, and rotate exposed provider keys.
Pod compromise An attacker does not immediately receive the raw upstream provider key. Runtime isolation, egress control, least privilege, and incident response.
Business abuse Usage visibility and limits can help spot unusual patterns. Application authorization, fraud controls, and provider-side controls.

Rollout

Roll out one provider and one environment first.

Start with the lowest-risk provider path, confirm traffic in the dashboard, then repeat for the next service or environment.

  1. 1

    Pick a narrow path

    Choose one app, one provider, and one non-production environment. Avoid changing every pipeline and cluster at once.

  2. 2

    Run a real request

    Trigger the normal job or pod code path and confirm Activity shows the expected provider call.

  3. 3

    Remove old provider keys

    Delete raw provider keys from CI variables, Kubernetes Secrets, deployment manifests, hosting settings, and old local env files.

FAQ

Common deployment questions.

Does VaultProof replace Vault, KMS, or cloud Secrets Manager?

No. Use those systems for infrastructure secrets and workload identity. VaultProof adds a provider-key runtime layer for outbound third-party API calls.

Should CI run vaultproof-init on every build?

Usually no. Run init during setup or controlled rotation. CI jobs should receive the generated VaultProof values, not repeatedly discover and rewrite credentials.

What should I do if a raw provider key was already in CI?

Rotate it at the provider, remove it from variables and logs where possible, deploy the VaultProof values, then monitor the replacement traffic.