{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/secrets-management","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/secrets-management/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/secrets-management/"},"term":{"en":"Secrets management","da":"Håndtering af hemmeligheder (secrets management)"},"aka":{"en":[],"da":["secrets management"]},"domain":["platform","security"],"cluster":"cloud","layer":"identity","status":"current","era":2015,"summary":{"en":"Keeping passwords, keys and tokens that programs use in one guarded store, instead of scattered in code and files.","da":"At holde de adgangskoder, nøgler og tokens, som programmer bruger, i ét bevogtet lager i stedet for spredt i kode og filer."},"body":{"formal":{"en":"The practice and tooling for storing, handing out, rotating and revoking machine credentials - such as passwords, cryptographic keys and access tokens - from a central, encrypted store with access control and a log of every use.","da":"Praksis og værktøjer til at opbevare, udlevere, udskifte og tilbagekalde maskiners loginoplysninger - fx adgangskoder, kryptografiske nøgler og adgangstokens - fra et centralt, krypteret lager med adgangskontrol og en log over al brug."},"plain":{"en":"Like a hotel key desk that hands out room keys only to the right guests, notes who took which key and can cancel a lost one at once - instead of keys hidden under doormats.","da":"Som en hotelreception, der kun udleverer værelsesnøgler til de rette gæster, noterer, hvem der tog hvilken nøgle, og straks kan spærre en mistet - i stedet for nøgler gemt under dørmåtten."},"inPractice":{"en":"At a pension fund, developers stop writing the database password into the program's code and keep it in a central secrets store; the program fetches it at start-up, and the store changes it automatically every month.","da":"I en pensionskasse holder udviklerne op med at skrive databasens adgangskode ind i programmets kode og lægger den i et centralt lager til hemmeligheder; programmet henter den ved opstart, og lageret skifter den automatisk hver måned."},"whyItMatters":{"en":"Passwords and keys left in code or shared files are easy for attackers to find and hard to change once leaked; a guarded store limits and records who can use them.","da":"Adgangskoder og nøgler, der ligger i kode eller delte filer, er lette for angribere at finde og svære at skifte, når de er lækket; et bevogtet lager begrænser og registrerer, hvem der kan bruge dem."}},"deepDive":{"en":"The scope is machine credentials: database passwords, API keys, OAuth client secrets, TLS private keys, SSH keys, signing keys and cloud access keys. It overlaps with but differs from key management, where a KMS or HSM performs cryptographic operations and the key never leaves the boundary, and from password managers for humans. Common tools are HashiCorp Vault (relicensed under the Business Source License in 2023, which prompted the OpenBao fork), AWS Secrets Manager, Azure Key Vault and Google Secret Manager. Kubernetes Secrets are only base64-encoded and are stored unencrypted in etcd unless encryption at rest is configured through an EncryptionConfiguration, ideally with a KMS provider.\n\nStores protect secrets with envelope encryption: a data key per secret or per store, wrapped by a key-encryption key held in a KMS or HSM. Vault encrypts its storage barrier with a root key that is itself protected by Shamir-split unseal keys or by auto-unseal through a cloud KMS. Clients authenticate with a platform identity (a Kubernetes service account token, an AWS IAM role, an OIDC JWT from a CI pipeline) and receive a token bound to policies; secrets come back with a lease and TTL. Dynamic secrets go further: Vault's database secrets engine creates a unique database user per request and drops it when the lease expires, so a leaked credential dies on its own and every use is attributable. Static secrets are rotated instead; AWS Secrets Manager uses a rotation function and the staging labels AWSPENDING, AWSCURRENT and AWSPREVIOUS so that old and new credentials overlap during the switch.\n\nThe failure modes are mostly about secrets escaping the store: hard-coded credentials (CWE-798), secrets committed to Git (deleting them in a later commit leaves them in history), baked into container image layers, printed in CI logs, dumped with environment variables into crash reports, or stored in plaintext in Terraform state. Scanners such as gitleaks and TruffleHog, and GitHub secret scanning with push protection, catch many of these. The correct response to a leak is to revoke and rotate first and only then purge history. Every scheme also faces the secret-zero problem: the first credential used to reach the store must come from somewhere trustworthy.\n\nThe current direction is to eliminate static secrets altogether through workload identity federation, where a CI job exchanges its OIDC token for short-lived cloud credentials (for example AWS STS AssumeRoleWithWebIdentity), SPIFFE/SPIRE workload identities and short-lived certificates. Relevant references are NIST SP 800-57 Part 1 on key lifecycles and cryptoperiods, ISO/IEC 27001:2022 Annex A 5.17 (authentication information) and 8.24 (use of cryptography), and the OWASP Secrets Management Cheat Sheet.","da":"Området dækker maskiners loginoplysninger: databaseadgangskoder, API-nøgler, OAuth client secrets, private TLS-nøgler, SSH-nøgler, signeringsnøgler og adgangsnøgler til cloud. Det overlapper med, men er forskelligt fra, nøglehåndtering, hvor en KMS eller HSM udfører de kryptografiske operationer, og nøglen aldrig forlader grænsen, og fra password managers til mennesker. Udbredte værktøjer er HashiCorp Vault (omlicenseret under Business Source License i 2023, hvilket førte til forken OpenBao), AWS Secrets Manager, Azure Key Vault og Google Secret Manager. Kubernetes Secrets er kun base64-kodede og gemmes ukrypteret i etcd, medmindre kryptering af hvilende data er sat op via en EncryptionConfiguration, helst med en KMS-provider.\n\nLagrene beskytter hemmelighederne med envelope encryption: en datanøgle pr. hemmelighed eller pr. lager, pakket ind af en nøglekrypteringsnøgle i en KMS eller HSM. Vault krypterer sin storage barrier med en rodnøgle, som selv er beskyttet af unseal-nøgler delt med Shamirs metode eller af auto-unseal via en cloud-KMS. Klienter autentificerer sig med en platformsidentitet (et Kubernetes service account-token, en AWS IAM-rolle, et OIDC-JWT fra en CI-pipeline) og får et token knyttet til politikker; hemmelighederne udleveres med lease og TTL. Dynamiske hemmeligheder går videre: Vaults database secrets engine opretter en unik databasebruger pr. forespørgsel og sletter den, når leasen udløber, så en lækket loginoplysning dør af sig selv, og hver brug kan spores. Statiske hemmeligheder skal i stedet roteres; AWS Secrets Manager bruger en rotationsfunktion og staging-labels AWSPENDING, AWSCURRENT og AWSPREVIOUS, så gamle og nye loginoplysninger overlapper under skiftet.\n\nFejlene handler mest om hemmeligheder, der slipper ud af lageret: hardkodede loginoplysninger (CWE-798), hemmeligheder committet til Git (sletning i et senere commit efterlader dem i historikken), bagt ind i lag i container-images, skrevet ud i CI-logs, dumpet med miljøvariabler i crash-rapporter eller gemt i klartekst i Terraform-state. Scannere som gitleaks og TruffleHog samt GitHubs secret scanning med push protection fanger mange af dem. Den rigtige reaktion på et læk er først at tilbagekalde og rotere og først derefter rense historikken. Alle løsninger står desuden over for secret zero-problemet: den første loginoplysning, der bruges til at nå lageret, skal komme et troværdigt sted fra.\n\nRetningen i dag er helt at fjerne statiske hemmeligheder via workload identity federation, hvor et CI-job veksler sit OIDC-token til kortlivede cloud-loginoplysninger (fx AWS STS AssumeRoleWithWebIdentity), SPIFFE/SPIRE-workload-identiteter og kortlivede certifikater. Relevante referencer er NIST SP 800-57 del 1 om nøglers livscyklus og kryptoperioder, ISO/IEC 27001:2022 bilag A 5.17 (autentifikationsinformation) og 8.24 (brug af kryptografi) samt OWASP Secrets Management Cheat Sheet."},"edges":[{"type":"requires","to":"cs/credential","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/cryptographic-key","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/service-account","confidence":"high","strength":"normal"},{"type":"implements","to":"cs/least-privilege","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/data-breach","why":{"en":"Leaked passwords and keys are a common way into cloud systems; keeping them guarded and short-lived narrows that door.","da":"Lækkede adgangskoder og nøgler er en almindelig vej ind i cloudsystemer; at holde dem bevogtede og kortlivede gør den dør smallere."},"confidence":"medium","strength":"normal"},{"type":"used-with","to":"ai/system-prompt","why":{"en":"System prompts can leak, so passwords and keys belong in a secrets store the app reads from, never in the prompt text.","da":"Systemprompter kan lække, så adgangskoder og nøgler hører til i et hemmelighedslager, som appen læser fra, aldrig i promptteksten."},"confidence":"medium","strength":"normal"}],"depth":3,"sources":[{"title":"NIST SP 800-190 - Application Container Security Guide","tier":"standard","publisher":"NIST"},{"title":"CSA Cloud Controls Matrix (CCM)","tier":"reference","publisher":"Cloud Security Alliance"}],"draft":true}