Secrets management
Purpose: Handle credentials for AEM integrations without secrets in git, packages, or CRXDE-visible properties.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Everyone touches a credential eventually |
| Platform engineers | Mechanism owners |
The threat model
Secrets in the repo are visible to every CRXDE reader, every package download, every backup, and — if they reach git — every clone forever. "It's just the stage password" is how prod patterns rot.
Where secrets may live (pick per your infrastructure)
| Mechanism | How it reaches AEM | Notes |
|---|---|---|
| Env vars / JVM system properties, set by the platform (vault-templated) | OSGi config interpolation: "apiKey": "$[env:RATING_KEY]" | Clean default on 6.5 (secretsdir/interpolation support per SP level) |
Secrets file directory on disk ($[secret:rating-key]) | Interpolation from a root-only directory | Pairs well with vault agents writing files |
| External secrets manager (Vault/cloud KMS) fetched at startup by an OSGi service | Service provides credentials to clients | Most control; you own caching/rotation code |
| Crypto Support (/system/console/crypto) encrypted values in config | {aes256}… values decrypted by instance key | OK for low-churn secrets; key management per-instance is the burden — hmac/master must be synced across instances for shared configs |
Never: plaintext in .cfg.json in git, dialog/content properties, clientlib JS, or logs (logging rules).
Rotation reality check
Whatever mechanism you pick, walk through: *how do we rotate this credential with zero downtime?* Env-var approaches need instance restarts (rolling, LB-drained); fetched-secret services can hot-reload; crypto-support values need config redeploys. Write the rotation runbook per secret when it is created — the register (landscape) links to it — and rehearse on the next scheduled rotation, not the post-breach one.
Hygiene
- Different credentials per environment, always — stage keys must open nothing in prod.
- Scope: one credential per integration per direction; shared "the-api-user" credentials make revocation a hostage negotiation.
- Scanning: secret-detection hooks in CI on every repo (it will catch someone within the year; that is the point).