security: migrate from Helm values secrets to External Secrets Operator

[omattsson]

Problem

Sensitive values (JWT_SECRET, ADMIN_PASSWORD, KUBECONFIG_ENCRYPTION_KEY, database credentials) are currently stored directly in Helm values.yaml and the Secret template. This means:

• Secrets are visible in Git history if values are committed
• helm get values exposes all secrets in plaintext
• No secret rotation mechanism
• No audit trail for secret access

This is a critical security gap for production deployments.

Proposed Solution

Phase 1: External Secrets Operator (ESO)

Add optional ESO integration to the Helm chart:

1. Add templates/backend/external-secret.yaml (conditional on externalSecrets.enabled)
2. Configure to pull secrets from:
   • Azure Key Vault (SecretStore with Azure provider)
   • AWS Secrets Manager (alternative)
   • HashiCorp Vault (alternative)
3. When ESO is enabled, skip creating the inline Secret template

Phase 2: Secret Rotation

• JWT_SECRET rotation with grace period (accept old + new key during transition)
• Database credential rotation via ESO auto-sync
• Kubeconfig encryption key rotation with re-encryption migration

values.yaml Configuration

externalSecrets:
  enabled: false
  provider: azurekv  # or aws, vault
  azurekv:
    vaultUrl: https://my-vault.vault.azure.net
    tenantId: ""
    # Auth via workload identity (recommended) or service principal
  secretMapping:
    jwtSecret: k8s-stack-manager/jwt-secret
    adminPassword: k8s-stack-manager/admin-password
    dbPassword: k8s-stack-manager/db-password
    encryptionKey: k8s-stack-manager/encryption-key

Acceptance Criteria

• ExternalSecret template added (optional, disabled by default)
• Azure Key Vault provider supported
• Existing inline Secret still works when ESO is disabled
• Documentation for ESO setup
• make helm-lint passes with both modes