Skip to main content

Secrets and ConfigMaps

OpenBox does not prescribe a secrets-management pattern. Three common options — pick per your compliance and tooling.

Option A — Plain K8s Secrets (simplest)​

Create secrets before install:

kubectl create secret generic openbox-backend-db-credentials \
  --from-literal=username=openbox \
  --from-literal=password='<generated-strong-password>' \
  -n openbox

Reference in values:

openbox-backend:
  db:
    userSecretRef: openbox-backend-db-credentials

Downside: secrets are only base64-encoded (not encrypted) in etcd unless you enable etcd encryption at rest at cluster level.

Option B — External Secrets Operator (recommended for AWS)​

Sync secrets from AWS Secrets Manager / HashiCorp Vault / GCP Secret Manager.

Prerequisites: ESO installed + IRSA role for pulling from Secrets Manager (see Terraform snippet 04-iam-irsa-roles.tf).

# externalsecret-openbox-db.yaml — apply BEFORE helm install
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: openbox-backend-db-credentials
  namespace: openbox
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: ClusterSecretStore
    name: aws-secretsmanager
  target:
    name: openbox-backend-db-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef: { key: openbox/rds-master, property: username }
    - secretKey: password
      remoteRef: { key: openbox/rds-master, property: password }

Chart references the synced K8s Secret via userSecretRef (same as Option A).

Option C — Sealed Secrets​

For GitOps workflows that want secrets committed to Git (encrypted).

# Install sealed-secrets controller once:
helm install sealed-secrets sealed-secrets/sealed-secrets -n kube-system

# Create + seal:
kubectl create secret generic openbox-backend-db-credentials \
  --from-literal=username=openbox \
  --from-literal=password='<pw>' \
  --dry-run=client -o yaml > secret.yaml

kubeseal --format yaml < secret.yaml > sealed-secret.yaml
git add sealed-secret.yaml && git commit -m "seal openbox db creds"

Chart references the resulting K8s Secret name (once unsealed).

What OpenBox chart secrets look like​

The chart creates the following secrets on install (populated from your values):

SecretPurpose
identity-service-secretsKeycloak DB password + bootstrap admin password
openbox-backend-envBackend env vars (KMS ARN, S3 bucket, etc.)
openbox-core-envCore env vars
postgresqlIn-cluster Postgres passwords (Bitnami-managed)

For prod, override each via values.yaml — don't rely on chart-generated random values (they change on helm upgrade).

Rotation​

  • Plain K8s Secrets — kubectl create secret --dry-run=client -o yaml | kubectl apply -f - (rolls Pods automatically if annotations set)
  • ESO — rotate in source (AWS SM) → ESO syncs within refreshInterval
  • Sealed Secrets — commit new sealed secret → ArgoCD syncs

For DB passwords: rotate in source, helm upgrade OpenBox with new secret, pods restart, connections re-auth.

Never commit unencrypted secrets​

.env files with plaintext passwords should NEVER be committed to Git. Use .gitignore:

values-prod-secrets.yaml
*.env
*.pem

Verify​

kubectl get secrets -n openbox
kubectl get secret openbox-backend-db-credentials -n openbox -o jsonpath='{.data.username}' | base64 -d
# Should print the username; empty means secret is missing or malformed
Last updated on