search

OpenCHAMI / deployment-recipes

Ochami deployment recipes
MIT License
8 stars 10 forks source link

[RFD] adding secrets to services in docker compose (without using docker swarm) #7

Closed travisbcotton closed 7 months ago

travisbcotton commented 7 months ago

Secrets can be added via ENV variables or files on the host Files on the host can be plaintext files and can be added as secrets and used by services in the compose file. Secret as a file example below

compose.yaml

version: '3.8'

services:
  web:
    image: <service-container>
    secrets:
     - secret-file

secrets:
  secret-file:
    file: <path to file>

This can be a complex file and the syntax and structure will be preserved.

We can use this to bring in the ochami-init config file to generate users in the various databases. Then we won't need to generate passwords every time we run the init.

Here is an example of how we might use files to bring in the ochami-init config file

version: '3.8'

smd-init:
  container_name: smd-init
  image: ghcr.io/openchami/smd:v2.13.5
  environment:
    - SMD_DBHOST=postgres
    - SMD_DBPORT=543
    - SMD_DBUSER=ochami
    - SMD_DBPASS=${POSTGRES_PASSWORD} # Set in .env file
    - SMD_DBNAME=ochami
    - SMD_DBOPTS=sslmode=disable
    - OCHAMI_CONFIG=/run/secrets/ochami.yaml #need to read from here now
  hostname: smd-init
  depends_on:
    - postgres
    - ochami-init
  networks:
    - internal
  entrypoint:
    - /smd-init
  secrets:
    ochami-config

secrets: 
  ochami-config:
    file: deployment-recipes/lanl/docker-compose/configs/ochami.yaml

There shouldn't be a need to write to that config anymore. But we will still need a way to generate the initial passwords and a safe place to keep the ochami.yaml config file

synackd commented 7 months ago

I think this is way better than reading and writing the same config file from within the container. Password generation and management is relegated outside of the container.

Would it be worth it to separate the secrets from the actual configuration? That way, if a secret manager/vault is used later on, if the configuration needs to be changed, the whole configuration file wouldn't have to be unlocked. E.g. ochami.yaml and ochami-secrets.yaml.

Also, I presume that instead of having SMD be the service that ingests the secret, you meant to put ochami-init?

travisbcotton commented 7 months ago

ugh, yes on the smd-init part. I copied the wrong stanza.

alexlovelltroy commented 7 months ago

I've created a new issue (#21) in the roadmap project to make this our preferred standard. We can close this one.