Admin credential rotation workflow for Keycloak operator

[vriesdemichael]

Problem

The Keycloak operator uses a full master-realm admin credential stored as a Kubernetes Secret. No built-in process exists to rotate this credential. Password age is unbounded unless an external secret manager is configured.

This is documented as GAP-5 in the threat model (docs/security/threat-model.md).

What needs to happen

1. Document the manual rotation procedure — steps to update the Secret and trigger reconciliation without downtime
2. Verify graceful re-authentication — confirm the operator picks up a new credential on the next reconciliation cycle without restart (expected: yes, via the admin client factory re-reading the Secret)
3. Provide integration guidance for external secret managers:
   • External Secrets Operator + Vault
   • External Secrets Operator + AWS Secrets Manager
   • CNPG-native credential handling (for operator-managed Keycloak)
4. Log a warning at startup and/or rotation time if the credential has not changed in a configurable time window (optional hardening)

Acceptance criteria

• Manual rotation steps documented in docs/operations/secret-management.md
• External secret manager integration examples included
• Operator confirmed to re-authenticate without restart after Secret update
• Unit test verifying factory re-reads Secret on each admin client creation (if not already covered)

Related

• Threat model GAP-5: docs/security/threat-model.md
• Issue Security alerting on drift detection and admin credential rotation guidance #760: security alerting on drift detection (companion — both relate to credential integrity)
• ADR-005: no plaintext secrets
• ADR-080: atomic secret rotation