[CWL security migration] Independent Keyverse KMS and secret authority; retire dotenv and static credential files #2063

Owner requirement — corrected 2026-09-10

CWL must stop depending on .env, and Keyverse must itself provide the independent KMS/cryptographic trust and secret-lifecycle service. External KMS/HSM is OPTIONAL, not a production prerequisite. The previous preference for external custody did not meet the owner's standalone requirement.

POSTGRES_PASSWORD_FILE, a different plaintext config file, or a Kubernetes Secret is not proof of migration. These may change transport but do not establish Keyverse issuance, access policy, rotation, revocation or audit. A static host file cannot be relabeled as an independent trust authority merely by moving it outside the repository.

This issue is the cross-repository migration register, NOT evidence that rollout is complete. The original request was recorded on 2026-09-09; the clarification above supersedes the previous external-provider/static-bootstrap interpretation without discarding useful hardening or predecessor delta.

Canonical responsibility

Keyverse owns root custody, initialization/seal/unseal/recovery, cryptographic key lifecycle and operations, secret versions/leases, governed credential issuance/revocation and access audit. Identity/federation, authorization and custody remain distinct bounded contexts. New custody/cryptographic runtime is Rust with reviewed primitives, not a new custom cipher or another Python vault engine.

.github owns reusable verification/inventory; AppGuardrail owns source detection. enterprise-architecture-core records the context map and adoption decision; context-graph-contracts publishes only value-free interoperability contracts. Consumers retain domain truth and use immutable released APIs, never Keyverse DBs, source copies or open-PR runtime dependencies.

Independent startup and key usage

The Keyverse custody core must initialize and unseal without a live dependent Keycloak, credentials issued by its own locked data plane, another Keyverse deployment, or an external KMS/vault. Minimal durable bootstrap state may contain encrypted key material and public/authenticated metadata, not its complete plaintext unlock factor.

A standalone quorum-unseal profile with separately protected custodians is a valid direction; optional local hardware or external-provider profiles can support automatic unseal under their declared trust assumptions. Quorum unseal is not threshold signing. Do not promise both unattended full-cluster cold recovery and protection from possession of all host state without any separate unlocking factor. Protect initial enrollment and instance identity; never replace that with an unverified token, shared admin password or unauthenticated first network request.

Keyverse must offer opaque key handles and authorized encrypt/decrypt, wrap/unwrap, sign/verify and MAC operations. Root/wrapping/signing private keys are non-exportable via normal APIs. Secret-string retrieval and any plaintext data-key export are separately scoped capabilities; not every consumer should receive an encryption key as a string.

Software-only custody, hardware-backed custody and validated hardware modules have different assurance. A PKCS#11-compatible service is not automatically a physical HSM or FIPS-validated product. Record the exact module/version/configuration evidence for any such claim.

Policy to enforce

1. Runtime application/provider secrets resolve through released Keyverse contracts. .env, home-directory dotenv discovery, plaintext config DBs, static secret mounts and environment-variable fallback are not alternative credential authorities.
2. Non-secret endpoints, log levels, bootstrap locators and deployment settings stay typed configuration. Do not misclassify safe dotenv-disabling code, examples or transitive dependencies as proven secret exposure.
3. Cryptographically verify short-lived workload identity and bind issuer, audience, subject, tenant/environment, key/version, purpose, operation and lifetime. GitHub OIDC also binds repository/owner IDs and trusted immutable workflow identity. Decoded claims alone are not authentication; PR/fork code never receives general privileged secrets.
4. Prefer direct client integration or authenticated local IPC. A driver-required ephemeral file is only a separately reviewed compatibility sink AFTER Keyverse-issued, scoped, short-lived authorization, with replacement/cleanup and no fallback. The current static /run/keyverse-bootstrap/* producer lacks this lifecycle and remains a gap, not a default standalone architecture.
5. Consumers fail closed on invalid/revoked/expired authorization. Any still-valid lease cache follows its explicit revocation policy. Revocation cannot retroactively erase plaintext already returned to a compromised consumer; revoke/expire the upstream credential too. Do not hide failure with expired caches, operator tokens, paid-provider fallback or another secret store.
6. Model-provider secret use stays in contextual-orchestrator's authorized execution boundary; model-backed Actions continue using orchestrator/free and gateway-scoped identity. No hardcoded provider/model/group or key fan-out to siblings.
7. Secret values do not enter PRs, logs, artifacts, metrics, browser bundles, events, screenshots or LLM context. Evidence contains only necessary value-free locations/references, with appropriate access control for sensitive metadata.

PostgreSQL acceptance

Database-image administrative initialization is separate from consumer authentication. _FILE initializes a static password; it is not a workload lease.

Use Keyverse-issued short-lived client certificates with explicit database-role mapping where the actual driver/TLS integration supports them, or an explicitly selected Keyverse-owned dynamic-role adapter with least-privilege credentials. No shared long-lived superuser password is distributed to applications. The database adapter is a deliberate privileged provider integration, not permission for arbitrary cross-service SQL.

Prove real issuance, login, scope denial, renewal, rotation and revocation. Define revocation for both new connections and existing sessions/pools; expiration alone is not evidence that an authenticated session ended. Provisioning authority and initial DB connection must not create another startup dependency cycle. A static certificate/private-key file is not an acceptable substitute for a static password file.

Existing source lines and correction

• Keyverse 🧪 테스트 개선: parse_conflict_reason 함수 단위 테스트 추가 #129: canonical encrypted-store foundation. Initial observed head 0f10ac556a318c3c3f5ce7eab0802573ecce0c4c is historical. Preserve the complete valid delta; administrator metadata/write APIs are not a workload KMS service.
• Keyverse Run scheduler when base branches advance #151: protected root-file compatibility repair. Initial implementation 4caafd0fa56b9ca377c93d78299bfe82dbec8faf and 42 focused local cases are historical, not current full verification or native custody acceptance. The latest inspected head 0fe44cfcda9cbd1cf2d81f4b9360630449ea3a70 remains open/Draft. Reconcile its proposed external-KMS mandate with this clarification.
• Keyverse Handle unknown stale auto-merge branches #153: current static-mount/_FILE source delta is preserved but NOT accepted as completed migration. Documentation correction 61b30595bea4639517387d3ad55c2464a5d8f3d8 changes ADR-0017, index and doctoring only; it does not implement native KMS. Keep Draft and repair the runtime/consumer contract before adoption.
• AppGuardrail fix(autofix): publish protected branch repairs through stacked PRs #1199: lexical dotenv inventory does not prove Keyverse usage or find every implicit loader.
• Naruon fix(scheduler): bound organization sweep pressure under Actions saturation #1630: staging a secret-reference resolver does not implement a non-exportable key-operation port or authorize premature runtime cutover.

Historical initial inventory — not an exhaustive organization census

Refresh each path from its live protected/default ref before editing. These are the original indexed observations, not current deployment findings:

Enumerate all accessible non-archived CWL repositories, retaining inaccessible/unscanned/failed entries in the denominator. Zero lexical findings or absence of .env is not migration completion.

Work packages and completion gates

• Native Keyverse init/seal/unseal/recovery succeeds without any external KMS/vault and without dependent identity/database startup credentials.
• Context-bound encryption, non-exportable key operations, versioned/3NF durable state, audit failure behavior, concurrency, rotation, rewrap and restore are implemented and tested.
• Verified workload identity, narrow authorization, secret/key-operation distinction and credential lease/revocation contracts are released immutably.
• PostgreSQL real-driver issuance/authentication/expiry/rotation/revocation and active-session behavior are proven; static _FILE wiring is not counted.
• Run scheduler when base branches advance #151/Handle unknown stale auto-merge branches #153 compatibility hardening is integrated only with corrected default-profile/custody boundaries and current full checks.
• AppGuardrail detection and central .github immutable invocation produce value-free exact-head inventories and reject new regressions without hiding legacy gaps.
• EA/contracts owners reconcile the context map, API ownership, PRD/TRD/UML and product gap baseline; no domain truth/secret copying.
• Consumer owner stacks demonstrate clean .env-free startup, authority outages, rotation/revocation and rollback without static fallback, then retire old paths.
• Publish owner artifacts before adoption; record owner version + consumer SHA + deployment/recovery evidence.

PR check concurrency remains {workflow name}-{repository}-{PR number}; missing indirect PR identity fails closed. Cancel only obsolete same-group verification runs. Merge/release/deploy/migrations stay serialized, idempotent and non-cancelling. No force pushes, synthetic checks, gate weakening or unverified Close.

No real credentials, deployment or repository protections are changed by this issue revision. The corrected acceptance requirements remain unfulfilled until executable evidence exists.

Primary references (APA 7)

HashiCorp. (n.d.). Seal stanza. https://developer.hashicorp.com/vault/docs/configuration/seal

HashiCorp. (n.d.). Seal/Unseal. https://developer.hashicorp.com/vault/docs/concepts/seal

HashiCorp. (n.d.). Transit secrets engine. https://developer.hashicorp.com/vault/docs/secrets/transit

HashiCorp. (n.d.). PostgreSQL database secrets engine. https://developer.hashicorp.com/vault/docs/secrets/databases/postgresql

PostgreSQL Global Development Group. (n.d.). Certificate authentication (PostgreSQL 17). https://www.postgresql.org/docs/17/auth-cert.html

National Institute of Standards and Technology. (n.d.). FIPS 140-3 standards. https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-standards

GitHub. (n.d.). OpenID Connect reference. https://docs.github.com/en/actions/reference/security/oidc

OWASP Foundation. (n.d.). Secrets management cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

Keycloak. (n.d.). Using a vault. https://www.keycloak.org/server/vault

Vendor documents are architectural precedents, not adopted runtime dependencies or proof of Keyverse implementation. Keycloak's internal vault adapter is not the CWL-wide KMS/secret-service API.