Beste praktijken voor het beheren van geheimen met HashiCorp Vault in CI/CD

Het veilig beheren van geheimen is een cruciaal aspect van moderne CI/CD-pijpleidingen. Elk lek van API-sleutels, databasegegevens of tokens kan leiden tot catastrofale datalekken, nalevingsschendingen en reputatieschade. HashiCorp Vault biedt een robuuste oplossing voor geheim beheer van ondernemingen, waardoor organisaties gevoelige gegevens gedurende de hele ontwikkelings- en implementatiecyclus kunnen beschermen. Door beste praktijken voor Vault-integratie aan te nemen, kunnen teams blootstelling minimaliseren, rotatie automatiseren en strikte toegangscontrole uitvoeren zonder de levering te vertragen.

Deze gids schetst bewezen strategieën voor het gebruik van HashiCorp Vault in CI/CD omgevingen. U leert hoe u dynamische geheimen kunt gebruiken, fijnkorrelig beleid kunt implementeren, gegevens in doorvoer en rust kunt versleutelen, voortdurend referenties kunt roteren en alle geheime toegang kunt bewaken. We behandelen ook integratiepatronen voor belangrijke CI/CD-tools zoals Jenkins, GitLab CI en GitHub Acties, samen met gemeenschappelijke valkuilen om te vermijden.

Het inzetten van deze praktijken zal niet alleen uw beveiligingshouding versterken, maar ook operationele workflows stroomlijnen, handmatige overhead verminderen en helpen voldoen aan de regelgevingsvereisten zoals SOC 2, PCI DSS en HIPAA.

HashiCorp Vault begrijpen in CI/CD

HashiCorp Vault is een hulpmiddel dat is ontworpen om veilig de toegang tot tokens, wachtwoorden, certificaten en andere geheimen te beheren en te beveiligen. In CI/CD workflows kan Vault dynamisch geheimen genereren, geheime levenscyclus beheren en toegangsbeleid afdwingen. In tegenstelling tot statische geheimen hardcoded in configuratiebestanden of omgevingsvariabelen, behandelt Vault geheimen als efemerale bronnen die op verzoek worden gecreëerd en automatisch worden ingetrokken na gebruik.

Vault integreert met CI/CD systemen via zijn REST API, CLI en native authentificatie plugins. Het typische patroon omvat:

  • Authenticatie: De CI/CD-pijpleiding authenticeert Vault met behulp van een veilige methode zoals AppRole, Kubernetes auth, of een kortlevend token geïnjecteerd door de CI-tool.
  • Geheime Retrieval: Tijdens een bouw- of implementatiefase vraagt de pijpleiding om geheimen van Vault ..of statische geheimen van een KV-winkel of dynamische geheimen van een database, cloud, of PKI-engine.
  • Gebruik: Geheimen worden tijdelijk geïnjecteerd in omgevingsvariabelen, configuratiebestanden of commandoargumenten, dan gebruikt voor taken zoals het verbinden met een database, het ondertekenen van artefacten, of het implementeren van een cloudprovider.
  • Opruimen: Na gebruik trekt de pijpleiding tijdelijke referenties of omgevingsvariabelen uit om het venster van blootstelling te verminderen.

Deze aanpak elimineert de noodzaak om geheimen op te slaan in Git repositories, CI/CD configuratiebestanden, of artefact registers, waardoor het aanvalsoppervlak drastisch wordt verminderd.

Kernbeginselen van geheim beheer met kluis

1. Gebruik Dynamische Geheimen

Statische geheimen . . zoals een enkele database wachtwoord gebruikt voor jaren . . zijn een beveiligingsaansprakelijkheid . Als gecompromitteerd , ze verlenen aanhoudende toegang tot totdat handmatig gedraaid . Vault dynamische geheime motoren maken referenties op de vlieg met korte tijd-tot-leven (TTL) waarden . Bijvoorbeeld , Vault kan een unieke , tijd-beperkte wachtwoord voor een PostgreSQL-gebruiker of een IAM toegang sleutel voor een AWS rol genereren .

Dynamische geheimen bieden verschillende voordelen:

  • Korte levensduur: Geheimen verlopen automatisch, vaak binnen minuten of uren.
  • Persessie-unie: Elke pijpleiding loopt krijgt verschillende referenties, waardoor het onmogelijk is om een gecompromitteerd geheim van een eerdere bouw te hergebruiken.
  • Automatische intrekking: Gewelf kan dynamische geheimen onmiddellijk na het voltooien van de pijpleiding herroepen, of wanneer de TTL vervalt.

Om dynamische geheimen te implementeren, configureert u een geheime engine (bijv. database, AWS, Azure) met een bepaalde rol en standaard TTL. Uw pijplijn vraagt dan om een lease voor die rol en gebruikt de geretourneerde referenties alleen voor de duur van de taak.

2. Implementeren van Fine-Grained Access Control

Het Vault-beleid wordt geschreven in HCL (HashiCorp Configuration Language) en volgt een op paden gebaseerd machtigingenmodel. Elk beleid verleent of ontkent toegang tot specifieke geheime paden en mogelijkheden (lees, maak, update, delete, lijst, sudo). Het principe van de minst privilege moet elke beleidsdefinitie begeleiden.

Beschouw deze richtsnoeren als volgt:

  • Rolbeleid: Maak een apart beleid voor ontwikkeling, steigers en productiepijpleidingen.Een CI-job die een functietak bouwt mag nooit toegang hebben tot productiegeheimen.
  • Padbeperkingen: Beperk de toegang tot alleen de exacte geheime paden die nodig zijn. Bijvoorbeeld, een databasebeleid zou op kunnen toestaan, maar ontkent al het andere.
  • Tijdgebonden toegang: Combineer beleid met token TTL's en verlengingslimieten. Zelfs als het token van een pijpleiding wordt gestolen, is het geldigheidsvenster beperkt.
  • Gebruik identiteiten: Gebruiken van Vault Identity Entities and Groups om beleid aan specifieke CI/CD-tools, taken of serviceaccounts toe te voegen.

Voorbeeld van een minimaal beleid voor een CI-pijpleiding:

path "database/creds/ci-app" {
 capabilities = ["read", "list"]
}

path "secret/data/ci/*" {
 capabilities = ["read", "list"]
}

path "auth/token/lookup-self" {
 capabilities = ["read"]
}

3. Versleutelen Geheimen in rust en in transit

Vault versleutelt automatisch alle gegevens die in de backend zijn opgeslagen met behulp van een master key. Deze sleutel is zelf versleuteld en kan worden beheerd met een externe sleutelbeheerdienst (KMS) of een hardware beveiligingsmodule (HSM). Echter, encryptie in transit is even belangrijk. Alle communicatie tussen CI/CD agenten en Vault moet TLS 1.2 of hoger gebruiken.

Beste praktijken:

  • TLS inschakelen: Vault-server configureren met een geldig certificaat van een vertrouwde CA of een interne PKI.
  • Verifiëren certificaten: CI/CD clients moeten de certificaatketen van Vault servers verifiëren. Geef het CA certificaat als onderdeel van de tools trust store.
  • Gebruik wederzijdse TLS indien mogelijk: Voor extra veiligheid, vereisen klantcertificaten van CI/CD-systemen.
  • Vermijd platte tekst over het netwerk: Nooit geheimen ophalen over HTTP of niet-versleutelde verbindingen. De meeste CI/CD-agenten ondersteunen omgevingsvariabelen die het Vault-adres en token veilig kunnen injecteren.

4. Geheime rotatie automatiseren

Regelmatige rotatie vermindert de schade van een gelekt geheim. Gewelfde dynamische geheimen worden automatisch gedraaid bij elk leaseverzoek, maar statische geheimen in KV-winkels moeten ook rotatie. HashiCorp raadt aan om Vault

Om rotatie van statische geheimen te automatiseren:

  • Bewaar statische geheimen in Vault KV v2 engine, die versiering en check-and-set operaties ondersteunt.
  • Schrijf een geplande taak (cron, Nomad periodieke batch, of CI-pijpleiding) die nieuwe waarden genereert en schrijft ze naar Vault.
  • Update alle afhankelijke systemen (databases, API gateways) met het nieuwe geheim via Vault plugin ecosysteem of externe scripts.
  • Gebruik Vault

5. Audit en Monitor Toegang

Vault logt elk geauthenticeerd verzoek naar zijn audit apparaten. U kunt audit logs naar bestanden, syslog, of externe diensten zoals Elasticsearch, Splunk, of Datadog. Audit logs bevatten de client IP, authenticatie methode, aanvraag pad, responsgegevens (indien toegestaan), en eventuele fouten.

Belangrijkste monitoringpraktijken:

  • Selecteer audit logging: Configureer ten minste één audit apparaat. Gebruik een veilige, alleen-toevoegen bestemming om te voorkomen dat geknoei.
  • Alerts instellen: Alerts aanmaken voor mislukte authenticatiepogingen, toegang tot gevoelige paden (bijv. de productiedatabasegegevens) of leasen van intrekkingen.
  • Review regelmatig: Periodiek controleren beleid gebruik en toegangspatronen. Verwijder ongebruikte beleid of paden.
  • Gebruik Vault

Integratie van Vault in CI/CD Pijpleidingen

Authenticatiemethoden voor CI/CD

Het kiezen van de juiste authenticatiemethode is cruciaal voor de veiligheid en het gebruiksgemak.

  • AppRol: Aanbevolen voor machine-naar-machine-authenticatie.Een CI/CD-service creëert een Vault-rol met een en . De pijpleiding wordt geauthenticeerd door beide te presenteren, waarbij een kortstondige client-token wordt ontvangen.
  • Kubernetes Auth: Ideaal voor pijpleidingen die in Kubernetes lopen. Vault valideert het Kubernetes serviceaccount token via de Kubernetes API server en geeft een Vault token uit op basis van de service accounts gebonden beleid.
  • AWS/GCP/Azure Auth: Voor pijpleidingen die op cloudproviders draaien, kan Vault de instantiemetadata of IAM rol verifiëren om tokens uit te geven zonder hardgecodeerde sleutels.
  • Tokengebaseerd: Voor eenvoudige opstellingen kan een CI/CD-tool zoals Jenkins een Vault token als een geheime variabele injecteren. Deze benadering is minder veilig en mag alleen worden gebruikt met zeer korte-levende tokens.

Altijd de voorkeur geven aan dynamische, gebonden authenticatie boven statische tokens. Configureer token TTLs om de maximale pijpleiding duur (bijvoorbeeld 30 minuten) te passen en stel een redelijk aantal toepassingen in (indien van toepassing).

Integratie met specifieke CI/CD-tools

Jenkins: Gebruik de HashiCorp Vault-plugin. Stel een Vault-serveradres, authenticatiemethode (AppRol of token) in en definieer pijpleidingen die geheimen ophalen via stappen. De plugin ondersteunt base64-codering, bestandsinjectie en omgevingsvariabele toewijzing.

GitLab CI: GitLab CI ondersteunt de Kluis in eigen persoon via het token . Configureer Kluis om JWT-authenticatie te accepteren van GitLab

GitHub Acties: Gebruik de actie GitHub. Het ondersteunt OIDC-authenticatie (aanbevolen), token of AppRole. Voeg een stap toe die geheimen in kaart brengt aan omgevingsvariabelen of schrijft ze naar bestanden. Voor OIDC, configureert u Vault met een JWT-authentieke methode die wordt vertrouwd op uitgever en die gebonden is aan specifieke repositories of branches.

CircleCI: Gebruik de Vault orb of directe API-oproepen. CircleCI

Voorbeeld van de werkstroom met AppRole in Jenkins

Beschouw een Jenkins pijpleiding die een Docker-image bouwt en het in een Kubernetes cluster zet. In plaats van het opslaan van de Kubernetes configuratie en het register wachtwoord in Jenkins, haalt het ze op van Vault op runtime.

  1. Vooraf configureren Vault: Maak een beleid dat leestoegang geeft tot en ]. Creëer een AppRol-rol met dat beleid, een TTL van 10 minuten, en een opgeslagen in Jenkins als een geloofsovertuiging.
  2. Pipeline Stap: Gebruik de HashiCorp Vault-plugin met de AppRole rol-ID (ook een credential) en de SecretID. De plugin authenticeert en verkrijgt een Vault token.
  3. Fetch Secrets: Lees het Docker register wachtwoord en Kubernetes token van Vault. De plugin schrijft ze naar tijdelijke omgevingsvariabelen of bestanden.
  4. Gebruik: Voer uit met de referenties. Draai dan met de configuratie. Na de stap eindigt de pijpleiding en vervalt het kluisteken.
  5. Opruiming: Optioneel herroepen AppRole...als herbruikbaarheid niet gewenst is.

Geavanceerde overwegingen

Geheime motoren en hun gebruiks gevallen

Vault ondersteunt vele geheime motoren. Voor CI/CD zijn de meest relevante:

  • KV v2 (Key-Value): Bewaar statische geheimen zoals API-sleutels, certificaten of omgevingsspecifieke instellingen. Schakel versiering in om wijzigingen terug te draaien.
  • Database: Gebruikers van tijdelijke databases genereren met dynamische referenties voor MySQL, PostgreSQL, MongoDB en anderen.
  • Cloud Providers (AWS, Azure, GCP): Genereer tijdelijke IAM rollen, service principals, of opslag rekeningsleutels.
  • PKI: Geef kortlevende TLS-certificaten voor mTLS uit tussen microdiensten of voor containerregisters.
  • Transit: Versleutel/decoderen van gegevens zonder het te bewaren .. nuttig voor het versleutelen van artefacten voordat ze worden opgeslagen in een repository.

Beleidsontwerp Beste praktijken

Beleidsontwerp met een duidelijke naamgevingsconventie en hiërarchische structuur. Bijvoorbeeld:

  • ..voor CI-specifieke geheimen.
  • ..voor het in scene zetten van omgevingsgeheimen.

Gebruik de regels van deny] niet te ruim; de standaardontkenning van Vault is voldoende. Combinaties van en moeten worden getest voordat ze worden ingezet op productie. Het Vault CLI commando is nuttig voor validatie.

Back-up en herstel van rampen

Vault . opslag backend (consul, vlot, bestand, enz.) moet regelmatig worden back-ups. Als u geïntegreerde opslag (Raft), inschakelen snapshot back-ups. Voor CI / CD-pijpleidingen die afhankelijk zijn van Vault voor alle geheimen, een Vault uitval zal breken implementaties. Mitigate dit door:

  • Vault draaien in een zeer beschikbare (HA) configuratie met ten minste drie knooppunten.
  • Een terugval set geheimen opslaan in een alternatieve versleutelde winkel (bijvoorbeeld AWS Secrets Manager) met een korte TTL . Maar behandel dat als een laatste redmiddel.
  • Regelmatig testen van de herstelprocedures bij rampen, inclusief herstel van een momentopname.

Vaak voorkomende Pitfalls te vermijden

  • Hardcodering van een Vault Token in CI/CD Variabelen: Zelfs als het token wordt opgeslagen als een geheime variabele, kan het worden gelekt door bouwlogs of artefacten. Gebruik dynamische authenticatie (AppRole, OIDC) zodat het token wordt gegenereerd voor elke run en nooit aanhoudt.
  • De wortel Token gebruiken in Pijpleidingen: De root token mag alleen worden gebruikt voor initialisatie en noodgevallen. Alle pijpleidingen moeten gebruik maken van tokens met beperkte reikwijdte met een passend beleid.
  • Niet instellen van korte TTL's: Een CI-pijpleiding loopt meestal minuten, niet uren. Stel token TTL's in op de verwachte duur van de opdracht plus een kleine buffer. Langlevende tokens verhogen het risico.
  • Afwijkende auditlogs: Zonder auditmonitoring mis je indicatoren van compromissen of verkeerd geconfigureerd beleid. Stel je waarschuwingen in voor toegang tot zeer gevoelige geheimen.
  • Opslaan van geheimen in Pijplijn-uitvoer: Nooit geheimen afdrukken naar console, logbestanden of artefacten bouwen. Gebruik een op bestanden gebaseerde injectie of verwijder het geheim van omgevingsvariabelen onmiddellijk na gebruik.
  • Vergeet Leases te herroepen: Dynamische geheimen blijven geldig totdat de lease afloopt of wordt ingetrokken. Trek leases in uw pijplijn expliciet in.Vervolgens worden de leases na de bouw of schoonmaakfase ingetrokken ().

Conclusie

Het integreren van HashiCorp Vault in uw CI/CD-pijpleidingen elimineert de gevaarlijkste bron van geheime lekken: hardcoded of omgevingsgestuurd statische referenties. Door de beste praktijken die hier worden beschreven te volgen . dynamische geheimen, fijnkorrelige toegangscontrole, encryptie, geautomatiseerde rotatie en uitgebreide checking .U kunt een robuuste, productie-ready geheime management workflow bereiken.

Start klein: adopteer AppRole-authenticatie voor één pijpleiding, haal een dynamische database credential, en volg de audit logs. Geleidelijk uitbreiden om alle pijpleidingen en geheime types te bestrijken. Met Vault, veiligheid en snelheid gaan hand in hand, ervoor zorgen dat uw CI / CD-uitgangen zijn zowel veilig en betrouwbaar.

Aanvullende middelen: