Like the title says, does anyone know how to give systemd services a secret?

For example: postgresql.bu

variant: fcos
version: 1.4.0
storage:
  directories:
    - path: /opt/services/postgres/data
      overwrite: true
      mode: 0755
systemd:
  units:
    - name: postgres.service
      enabled: true
      contents: |
        [Unit]
        Description=The PostgreSQL object-relational database system
        Wants=network-online.target
        After=network-online.target

        [Service]
        Type=notify
        NotifyAccess=all
        Restart=on-failure
        RestartSec=60
        ExecStartPre=-/bin/podman kill postgres
        ExecStartPre=-/bin/podman rm postgres
        ExecStartPre=/bin/podman pull docker.io/library/postgres:15
        ExecStart=/bin/podman run --name postgres \
            --volume /opt/services/postgres/data:/var/lib/postgresql/data:z \
            --env POSTGRES_USER=admin \
            --env POSTGRES_PASSWORD=admin \
            --env POSTGRES_DB=admin \
            --replace --sdnotify=conmon \
            --publish 0.0.0.0:5432:5432/tcp \
            --restart=unless-stopped \
            --log-level info \
            docker.io/library/postgres:15

        [Install]
        WantedBy=multi-user.target

If that is my SystemD unit file, can I replace:

env POSTGRES_PASSWORD=admin with a value that is discovered at runtime?

  • @[email protected]OP
    link
    fedilink
    English
    21 year ago

    Thanks for the quick response :)

    I read through the operator notes yesterday.

    To avoid any possibility of leaking sensitive information, it’s best to store secrets in a dedicated service such as Hashicorp Vault.

    I just wish there was a short example on how to use:

    • vault + ignition
    • or vault + systemd
    • or vault + podman

    I just asked ChatGPT and it’s solution seems good:

    Within the Unit File, in the PreStart condition, retreive the secrets from vault.

    [Unit]
    Description=Your Service
    ...
    
    [Service]
    ExecStartPre=/usr/local/bin/fetch_vault_secret.sh
    Environment="SECRET_KEY=%i"  # Replace %i with the actual secret path in Vault
    
    ExecStart=/path/to/your/service
    
    [Install]
    ...
    

    Where the fetch_vault_secret.sh script looks like this:

    #!/bin/bash
    export VAULT_ADDR="https://vault.lan:8200"
    export VAULT_TOKEN="your-vault-token"
    
    SECRET_KEY="${SECRET_KEY//\//%2F}"  # Replace / with %2F in the secret path
    
    secret_value=$(vault kv get -field=value secret/${SECRET_KEY})
    export SECRET_VALUE="$secret_value"
    

    I’ll play with it some, and post the results back later.

    If anyone has a better solution please let me know :)

    • dogA
      link
      fedilink
      English
      11 year ago

      that’s fair! i think it’s more because deploying vault is not really a quick task, iirc xD but yeah, i 'd love to hear how other coreos users handle their secrets. more than one way to… inject your secrets i guess xD