Learn OpenClaw - Config Management & Secrets

#Introduction

In episode 10 you successfully separated tenants with namespaces, scoping, and per-tenant ingress/egress. But all that separation depends on one very expensive asset: configuration — including the secrets inside it. TLS certificates, API keys, and policy configuration are stored in the cluster, and if they're managed carelessly, all the security fences you built are just decoration.

Episode 11 closes Phase 3. Its roadmap has three items: storing OpenClaw configuration securely, managing secrets for TLS and API keys with a proper lifecycle, and validating configuration changes in the pipeline before they touch production. This is the most "administrative" episode, but it's exactly where security incidents most often happen.

#Storing OpenClaw Configuration Securely

#Types of Configuration

OpenClaw configuration can be grouped into three types based on sensitivity. Public configuration like MeshConfig and ServicePolicy is safe in git — in fact it should be in git so it can be reviewed. Semi-confidential configuration like database credentials should go into a secret store. And highly confidential configuration — CA keys, admin tokens, signing keys — should only exist in dedicated secret systems.

apiVersion: openclaw.io/v1
kind: CARotationConfig
metadata:
  name: mesh-ca
  namespace: openclaw
spec:
  signingKeys:
    keyRef:
      secretName: openclaw-ca-key
      secretKey: ca.key
  rotation: 90d
  intermediateLifetime: 24h
  rootLifetime: 1y

Note the pattern above: the most secret part (the signing key) isn't written directly in the configuration — it's referenced via keyRef pointing to a Secret. This is the first principle of secure configuration management: separate secrets from configuration, and let configuration only store references.

#Avoiding Secrets in Git

The most common and most expensive mistake is committing secrets to a repository — whether from rushing, an env file already staged, or example config that wasn't cleaned up. Once a secret enters git history, it's considered leaked forever, and the only correct fix is rotation, not deleting the commit.

git log --all --oneline -S "BEGIN PRIVATE KEY"
git log --all --oneline -S "api_key="

The two commands above scan the entire commit history for lines containing private key material or credential keywords. Run them periodically on your configuration repos. If there are hits, that's an alarm — immediately rotate the leaked values and install scanning tools like gitleaks or trufflehog in the pipeline.

#Managing Secrets for TLS and API Keys

#Secret Store and External References

In production environments, a regular Kubernetes Secret isn't enough: its contents are stored base64 (not encrypted), and anyone who can read the namespace can read it. The recommended solution is an external secret store like Vault or a cloud secret manager, with a controller like the External Secrets Operator pulling secret values into Kubernetes Secrets only when needed.

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: billing-tls
  namespace: billing
spec:
  secretStoreRef:
    name: vault-secret-store
    kind: SecretStore
  target:
    name: billing-tls
  data:
    - secretKey: tls.crt
      remoteRef:
        key: billing/tls
        property: cert
    - secretKey: tls.key
      remoteRef:
        key: billing/tls
        property: key

The ingress policy in episode 10 referenced a secret named billing-tls. That secret is no longer created manually by humans — it's provided by the External Secrets Operator from Vault. If an admin deletes the entry in Vault, the controller syncs that deletion to the cluster. Secrets have one source of truth.

#Scheduled Rotation

A secret isn't a static object — it has a lifespan. TLS certificates expire, API keys can leak, and best practices force periodic rotation. The key to successful rotation is automation: never wait for a human to remember the rotation schedule. Set warnings before expiry and automate re-issuance.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: billing-cert
  namespace: billing
spec:
  secretName: billing-tls
  issuerRef:
    name: openclaw-ca-issuer
    kind: ClusterIssuer
  dnsNames:
    - billing.example.com
  renewBefore: 30d

With cert-manager and an issuer from the OpenClaw CA, certificates are issued automatically, renewed 30 days before expiry, and written to the same secret the ingress policy uses. No human needs to touch the secret. For API keys, set expiry warnings in monitoring and automate rotation with a script that runs the re-issuance pipeline.

#Validating Configuration Changes in the Pipeline

#Static Validation and Schema Compliance

Configuration changes are cheapest to fix before they enter the cluster. A CI pipeline can catch two classes of problems: syntax problems (wrong schema, unknown fields) and logic problems (a policy pointing to a service that doesn't exist, an undefined secret reference). Both can be checked without a running cluster.

openclawctl config validate --path config/openclaw
openclawctl policy validate --all --strict

The command openclawctl config validate --path config/openclaw checks schema and references across the entire configuration folder, while openclawctl policy validate --all --strict makes validation failures hard errors rather than mere warnings. In a pipeline, fail the build on any error output — don't let broken configuration flow to Argo CD.

#Secret Scanning in the Pipeline

Validation isn't complete without secret scanning. Tools like gitleaks run on every commit and pull request, looking for credential patterns before code reaches the main branch. If found, the pipeline stops — and even better, connect it to an automatic rotation system for cases where material was leaked.

name: secret-scan
on:
  pull_request:
  push:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan secrets
        run: |
          curl -sSfL https://raw.githubusercontent.com/gitleaks/gitleaks/master/gitleaks.sh | bash
          gitleaks detect --redact --verbose

The YAML pipeline above runs gitleaks on every pull request and every push to main. A detect result that finds a match returns a non-zero exit code so the workflow fails and prevents the merge. This is the last layer before configuration containing secrets races into production.

#Wrap-Up

In episode 11 you completed Phase 3: storing configuration by separating secrets from config files, managing TLS and API key secrets through an external secret store with scheduled rotation, and closing the pipeline gates with configuration validation, strict policy validation, and automatic secret scanning.

Key takeaways:

• Separate secrets from configuration — configuration only stores references, not values.
• A secret that ever entered git is considered leaked forever; the only fix is rotation.
• Use an external secret store (Vault) with the External Secrets Operator as the single source of truth.
• Rotation must be automatic and scheduled; create the new one, verify, then retire the old one.
• The pipeline must validate schema, run strict policy validation, and scan for secrets on every pull request.

With Phase 3 complete, in the next episode, episode 12, we enter Phase 4 — networking and security: secure service mesh integration. You'll integrate OpenClaw with Istio, Linkerd, and Cilium, and enforce policies across mesh boundaries. See you there!