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):

Secret	Purpose
identity-service-secrets	Keycloak DB password + bootstrap admin password
openbox-backend-env	Backend env vars (KMS ARN, S3 bucket, etc.)
openbox-core-env	Core env vars
postgresql	In-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