Veilig geheimbeheer is een belangrijk aspect van containerbeveiliging. Als u wachtwoorden en API-sleutels injecteert als omgevingsvariabelen, riskeert u onbedoelde blootstelling aan informatie. Shell-variabelen worden vaak gelogd, doorgegeven aan onderliggende processen of gelekt naar foutrapportageservices zonder uw medeweten.
Het injecteren van waarden als speciale geheimen verkleint deze risico's. Docker heeft ingebouwde ondersteuning voor veilig geheimbeheer waarop u kunt aansluiten met Docker Compose. Toegang tot geheimen wordt per service verleend.
Hoe werken geheimen?
De Docker CLI heeft een aantal geheime beheeropdrachten, maar deze werken alleen met Swarm-clusters. Je kunt geen geheimen toevoegen aan zelfstandige containers met alleen de Docker CLI.
Docker Compose heeft “nep” geheimen om deze mogelijkheden naar workloads zonder cluster te brengen. De implementatie van Compose werkt op dezelfde manier als de Docker Swarm-functies en werkt met elk Compose-bestand.
Geheimen worden gemaakt als gewone tekstbestanden die in een bind in uw containers worden gemount. Uw toepassing heeft toegang tot de waarde van het geheim door de inhoud van het bestand te lezen. Met dit model blijven waarden inert totdat ze expliciet in uw container worden gebruikt, in tegenstelling tot permanent zichtbare omgevingsvariabelen.
Geheimen definiëren in Compose Files
Een geheim in een container krijgen is een proces in twee stappen. Eerst moet u het geheim definiëren met behulp van het veld geheimen op het hoogste niveau in uw Compose-bestand. Vervolgens update je je servicedefinities om te verwijzen naar de geheimen die ze nodig hebben.
Advertentie
Hier is een voorbeeld dat geheimen gebruikt om veilig een wachtwoord aan een service te verstrekken:
versie: “3” services: app: afbeelding: voorbeeld-app:laatste geheimen: – db_password geheimen: db_password: bestand: ./db_password.txt
De waarde van het geheim wordt uit uw werkmap gelezen’ ;s db_password.txt bestand wanneer u docker-compose up uitvoert. Compose koppelt het bestand aan /run/secrets/db_password in de container. Uw app heeft toegang tot het databasewachtwoord door de inhoud van het geheime bestand te lezen.
Bestaande Docker-geheimen gebruiken
Naast op bestanden gebaseerde geheimen, laat Compose je ook verwijzen naar bestaande Docker Swarm-geheimen. Als u dit mechanisme gebruikt, moet u de geheimen in Docker maken voordat u docker-compose up uitvoert. De opdrachtruimte voor docker-geheimen werkt alleen als uw actieve Docker-eindpunt een Swarm-managerknooppunt is.
Maak het geheim met behulp van de Docker CLI:
# haal waarde uit standaardinvoer echo P@55w0rd | docker geheim maak db_password aan – OF # haal waarde uit een file docker secret create db_password ./db_password.txt
Werk nu uw Docker Compose-bestand bij om naar het geheim te verwijzen:
version: “3” services: app: image: example-app:latest secrets: – db_password secrets: db_password: external: true
Het geheim instellen’ ;s extern veld geeft Compose de opdracht om de waarde te halen uit uw bestaande Docker-geheimen. De stapel mislukt met een fout als je hem probeert te starten voordat het geheim bestaat.
Uitgebreide geheime syntaxis
Compose ondersteunt een langere syntaxis voor geheimen als u meer gedetailleerde controle over het injectieproces nodig hebt. Door over te schakelen naar deze syntaxis kun je bestandsrechten aanpassen en de gekoppelde naam van het geheim wijzigen.
Vijf optionele velden zijn beschikbaar:
- bron – De naam van het geheim waarnaar wordt verwezen – dit moet een van de waarden zijn die zijn gedefinieerd in de sectie geheimen van uw Compose-bestand.
- target – Bestandsnaam die moet worden gebruikt wanneer het geheim in de container wordt gemount.
- uid– UID om in te stellen op het aangekoppelde geheime bestand. Standaard ingesteld op 0.
- gid – GID om in te stellen op het aangekoppelde geheime bestand. Standaard ingesteld op 0.
- modus – Bestandssysteemmachtigingen die van toepassing zijn op het aangekoppelde geheime bestand, uitgedrukt in octale notatie. Dit is standaard 0444. Pas op dat geheime bestanden nooit schrijfbaar zijn omdat ze altijd in het tijdelijke bestandssysteem van een container worden gemount.
Advertentie
Hier is een aangepast voorbeeld dat de naam van het aangekoppelde geheime bestand hernoemt en de permissies wijzigt:
versie: “3” services: app: afbeelding: voorbeeld-app:laatste geheimen: – bron: db_password doel: database_password_secret modus: 0440 secrets: db_password: external: true
De eenvoudige syntaxis is meestal voldoende voor de meeste implementaties. Als je meer specifieke vereisten hebt, zou de uitgebreide versie je de controle moeten geven die je nodig hebt. Individuele geheime verwijzingen kunnen de twee syntaxis binnen hetzelfde Compose-bestand combineren en matchen.
Geheimen en Image Authorship
Veel populaire community Docker-images ondersteunen nu geheimen in plaats van omgevingsvariabelen. Als auteur van afbeeldingen is het aanbieden van geheimen de beste manier om uw gebruikers te beschermen’ gegevens.
U kunt beide mechanismen ondersteunen door omgevingsvariabelen in te stellen op een bestandspad. Als uw afbeelding een databaseverbinding nodig heeft, laat u gebruikers de omgevingsvariabele DB_PASSWORD instellen op P@55w0rd of /run/secrets/db_password. Uw container moet controleren of de waarde van de variabele verwijst naar een geldig bestand; als dat zo is, gooi het dan weg en lees de uiteindelijke waarde uit het bestand.
Dit model geeft gebruikers de flexibiliteit om het meest geschikte mechanisme voor hun implementatie te kiezen. Onthoud dat niet alle gebruikers geheimen kunnen overnemen – als Swarm en Compose beide niet beschikbaar zijn, kunnen ze hun waarden niet opgeven.
Conclusie
Het gebruik van geheimen in plaats van reguliere omgevingsvariabelen vermindert de risico's van onbedoelde openbaarmaking van informatie. Stelt u zich een worstcasescenario voor waarbij een container zijn omgevingsvariabelen naar een gecompromitteerde logboekservice van derden stuurt. Aanvallers hebben nu uw databasewachtwoord en API-sleutels.
Advertentie
Door geheime gegevens te beperken tot toegang tot het bestandssysteem, kunnen waarden niet per ongeluk worden gelezen, omdat ze geen permanent kenmerk van uw milieu. Onthoud echter dat geheime bestanden hun eigen risico's met zich meebrengen. Je zou in de verleiding kunnen komen om ze te committeren aan bronbeheer, wat zou betekenen dat iedereen met toegang tot je repository hun waarden zou kunnen lezen.
Geheimen moeten “geheim” gedurende de hele levenscyclus van uw container. Voor productie-implementaties is het meestal het beste om builds te automatiseren met een CI-systeem. Stel uw geheimen in de pijplijninstellingen van uw CI-provider in en gebruik vervolgens uw buildscript om ze weg te schrijven naar bestanden waartoe Compose toegang heeft. Dit zorgt ervoor dat alleen u toegang heeft tot de werkelijke waarden, via de interface van uw CI-tool.