Path to external secret gets passed to environment variable instead of the secret itself

[herzenschein]

My goal is to not store my passwords in any file or exposed environment variable when managing containers, only relying on podman secrets.

I created a secret manually by passing a password to stdin, like printf "somepassword" | podman secret create passname -.

I then added the secret to my wg-easy container and marked it as external.

I passed the path to said secret via an environment variable: PASSWORD=/run/secrets/passname.

However, the actual password I get for wg-easy is simply /run/secrets/passname instead of the created secret, as though it was considered a string.

Using podman-compose from the devel archive did not solve the issue.

To Reproduce Steps to reproduce the behavior:

1. what is the content of the current working directory (ex. docker-compose.yml, .env, Dockerfile, ...etc.)

Only a compose file. I also use Caddy which requires more files, but the issue is reproducible without those.

2. what is the sequence of commands you typed

podman-compose --in-pod 1 --project-name wg-easy up --detach

Minimal reproducible example without Caddy, see https://github.com/wg-easy/wg-easy/wiki/Using-WireGuard-Easy-with-Podman for a reference:

version: "3.8"

volumes:
  wg-easy:

secrets:
  wg-pass:
    external: true

services:
  wg-easy:
    environment:
      - WG_HOST=my.domain.com
      - PASSWORD=/run/secrets/wg-pass
    secrets:
      - wg-pass
    image: docker.io/weejewel/wg-easy
    container_name: wg-easy
    hostname: wg-easy
    volumes:
      - wg-easy:/etc/wireguard:Z
    ports:
      - 51820:51820/udp
      - 51821:51821/tcp
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1

The web interface where you type the password should be in port 51821.

Expected behavior The password required to log in to wg-easy is the one stored in the secret.

Actual behavior The password required to log in to wg-easy is literally "/run/secrets/wg-pass".

Environment:

• OS: Linux
• podman version: 4.4.1
• podman compose version: 1.0.6

Additional context

I only found two potentially related issues, but I don't really know if they are what I mention in this issue:

• https://github.com/containers/podman-compose/issues/671
• https://github.com/containers/podman-compose/issues/589

[SzczurekYT]

Any updates on this?

[Shkrelic]

I too am interested in this. I've resorted to editing container endpoint to set the secret as an env variable.

[krair]

FYI, this is a problem with the container itself, not with podman-compose. You've likely seen some containers that let you set sensitive information as an environment variable that ends in _FILE like DATABASE_PASSWORD_FILE. This indicates to the app that the password is not actually stored in this variable, but that it must read the contents of the file declared in the variable.

Currently, podman-compose does not have anyway to combat this oversight by the container creator. However, you do have an option with podman run directly. As an example:

podman run --rm -it --secret db_secret,type=env,target=DB_SECRET docker.io/library/busybox sh
/ # echo $DB_SECRET
cd9635a4b83d8adc975ec53dae2b33e4a85397fa635e9251fce9827982e9eb36

[herzenschein]

@krair I don't quite understand. I'm not sure I've seen containers use a password file. PASSWORD here is expected to just be a plain password as far as I understand, not a file.

What would be the proper solution for the container creator to know what to do?

[krair]

@herzenschein This is actually a common practice. For example, see the Docker Secrets section here: https://hub.docker.com/_/postgres/

In this case, instead of passing the env variable PASSWORD, the maintainer could check for an env variable named PASSWORD_FILE. Thus, to "retrieve" the password, the code would return cat $PASSWORD_FILE instead of just $PASSWORD.

[nmcbride]

I'm trying to figure out how to go from a secret to a value in a target ENV var as well. For all the containers that take passwords and tokens as env vars.

If podman kube and podman run both support it, then couldn't podman compose also support it too?

[herzenschein]

BTW, probably related: https://github.com/containers/podman-compose/issues/718#issuecomment-1993851662