Adventive — AWS Secrets Manager

AWS Secrets Manager standards for Adventive. Currently focused on IdP recovery codes — the secrets that exist to rebuild or recover Adventive’s Cloudflare Zero Trust identity providers (JumpCloud SAML, Google Workspace OIDC, Duo) when something goes wrong upstream.

Chapters

#	Topic	Status
01	IdP recovery codes — naming, IAM role, MFA, audit	Stub — production gate; implementation required before any prd deploy

Why Secrets Manager (not Cloudflare Secrets Store) for IdP recovery

The IdP recovery codes exist to rebuild Cloudflare’s identity-plane integration. If they live inside Cloudflare’s own secret store, a Cloudflare-side incident that requires re-creating IdP integrations is also the incident that locks the recovery material away. That’s a circular dependency at DR time.

AWS Secrets Manager is intentionally out-of-band from Cloudflare:

• Separate provider, separate identity plane.
• Existing Adventive AWS keystore (Cognito sync, S3 credentials, etc. already use AWS-native secret stores).
• IAM-gated human access, separate from JumpCloud / Cloudflare Access.
• MFA-enforceable via IAM policy condition aws:MultiFactorAuthPresent.
• CloudTrail audit on every GetSecretValue call.
• KMS-encrypted at rest with a dedicated CMK for recovery material.

For Cloudflare Worker runtime secrets (like the New Relic ingest license key consumed by the OTel envelope), the canonical store is Cloudflare Secrets Store, NOT AWS Secrets Manager. See docs/platform/cloudflare/workers/06-observability-opentelemetry.md for that pattern.

Convention

Naming for IdP recovery: adventive-idp-recovery-<idp>-<artifact>, lowercase, hyphenated. Examples:

• adventive-idp-recovery-jumpcloud-saml-metadata
• adventive-idp-recovery-google-oidc-credentials
• adventive-idp-recovery-duo-integration

IAM role: AdventiveIdPRecoveryReader. At least two members. MFA required. CloudTrail-audited.