Docker compose secrets

Pagina: 1
Acties:

Vraag


Acties:
  • 0 Henk 'm!

  • LOTG
  • Registratie: Augustus 2004
  • Laatst online: 09-09 13:40
Ik ben de laatste tijd wat aan het hobbyen met een self hosted setup thuis, deze bestaat momenteel uit Proxmox met daarin een paar LXC containers en Docker containers die zijn opgezet met compose.

Nu willen veel compose files uiteraard passwords hebben voor databases en webui logins, prima natuurlijk maar die wil ik niet plaintext ergens hebben staan. Een oplossing word geboden in de vorm van docker secrets maar dat vind ik niet heel fijn. Niet erg beheerbaar, vereist een swarm en staat als nog op het systeem.

Nu leek het mij nogal voor de hand liggend dat je een secrets provider zou moeten kunnen gebruiken. Immers werken Azure en dergelijke zo ook, HasiCorp Vault leek mij een mooie oplossing.

Echter is de realiteit anders en is het belachelijk complex blijkbaar. Ik heb geen goede oplossing kunnen vinden, tenminste niet voor docker files die je niet in beheer hebt.
Wat het dichtste bij een oplossing ligt is een extra container die de agent draait en dan via een volume de secrets aan de andere containers geeft. Echter dit komt er praktisch op neer dat je als nog passwords plaintext op de machine aan het zetten bent, iets wat ik juist niet wil.

Is er iemand die met dit zelfde probleem heeft geworsteld en een oplossing heeft?

Het lijkt mij dat het een logische stap zou zijn dat een secret vanuit een provider zou worden opgehaald op het moment dat het nodig is, zonder dit plaintext op te slaan?

Alle reacties


Acties:
  • 0 Henk 'm!

  • tafkaw
  • Registratie: December 2002
  • Laatst online: 11-09 15:45
Wij doen dit met Ansible Vault, daar alle secrets in. Ci/cd en pw manager weten de decrypt key. Hashicorp Vault doen we ook, maar dan voor terraform om vm's op een cluster op te zetten.

Edit: je zou ook eens naar de cli tools van bijv. Bitwarden of 1password oid kunnen kijken.

[ Voor 20% gewijzigd door tafkaw op 24-04-2023 13:54 ]


Acties:
  • 0 Henk 'm!

  • LOTG
  • Registratie: Augustus 2004
  • Laatst online: 09-09 13:40
Dit had ik ook ergens gelezen maar dat betekent dan dat je geen compose gebruikt dan toch? Dan worden de containers gestart vanuit het ci/cd proces lijkt mij?

Dat is allemaal een stuk uitgebreider dan ik nu heb. Sowieso zijn mij compose files nu deels configuratie voor Traefik en Homepage.

Acties:
  • +1 Henk 'm!

  • Falcon
  • Registratie: Februari 2000
  • Laatst online: 15-09 19:26

Falcon

DevOps/Q.A. Engineer

Docker-Compose wordt hier gebruikt om lokaal te ontwikkelen en te valideren/testen van de SCS (keten aan applicaties in hetzelfde domein).

Deze secrets zijn dus niet spannend, omdat ze geen PRD credientials bevatten.

Mochten we lokaal moeten koppelen naar een interface/storage die wel een secret nodig heeft, dan stellen wij dit handmatig in de env.file die gebruikt wordt door Docker-Compose. Pushen van dit mag natuurlijk niet, en daarom staat de env.files die gebruikt worden in Docker-Compose standaard in de .gitignore. Ook checkt bij ons SonarCloud hierop, voor de zekerheid.

Voor de Test/PRD omgevingen wordt hier inderdaad gebruik gemaakt van een Vault. Bij ons is dit Azure KeyVault, applicaties krijgen d.m.v. een per applicatie individuele Managed Identity een Access Policy voor de toegang.

Dit allemaal geautomatiseerd uitgerold via YAML/Bicep deployment pipelines. (infra as code)

Helaas is de Docker Container image van Azure KeyVault Emulator nog niet geschikt voor sommige chipsets (Apple M1 bijv.), hierdoor kunnen wij dit stukje lokaal nog niet emuleren en hebben we de mogelijkheid om in Development-mode de credentials als env. parameter mee te geven.

[offtopic]
Wij hanteren nog een aparte Container Registry voor het Development Team ten opzichte van PRD, zodat het lokaal development strikt gescheiden is van PRD (steeds minder redenen voor).

Maar de belangrijkste reden hiervoor is dat wij zowel Developers hebben met Windows/Intelbakken als MacOS/M1/M2 machines, hiervoor moeten wij een Multi-architectural docker-image manifest beschikbaar hebben en voor PRD is dit niet nodig. Deze multi-platform images duren nog al lang om te bakken ivm een stukje emulatie (QEMU) voor de Apple chipsets, helaas bied Apple hiervoor nog geen build agents voor in zowel Azure Pipeline als in ACR Tasks/Runs)

"We never grow up. We just learn how to act in public" - "Dyslexie is a bitch"


Acties:
  • 0 Henk 'm!

Verwijderd

Zou je niet gewoon een password op user root zetten in de docker image en dan kun je de bestanden toch beveiligen, alleen lees/schrijf rechten voor group root?