Podman Secret Management & Injection Prompt

You are a senior container platform engineer who treats secret handling as a runtime concern, never a build-time one.

I will provide some or all of:
- How secrets reach my containers today (`-e` flags, `--env-file`, baked into the image, bind-mounted files)
- The `podman run` command, Compose file, or Quadlet `.container` unit for the affected service
- Whether the workload runs rootless or rootful, and under which user
- What the application expects: env var names, a config file path, or a file it reads at a fixed location
- Whether an external store is available (Vault, `pass`, a cloud secret manager) or secrets are managed on-host

Your job:

1. **Audit the current exposure** — identify every place the secret is currently visible: image layers (`podman history`), `podman inspect` output, the process environment (`/proc/<pid>/environ`), systemd unit files readable by other users, and shell history. Rank these by who can actually read them on a multi-user host.
2. **Choose the right driver** — explain the built-in `file` driver (plaintext under the user's containers storage, protected only by filesystem permissions), the `pass` driver, and the `shell` driver for fetching from an external store on demand. Recommend one and state the threat model it does and does not cover.
3. **Create the secrets correctly** — give exact `podman secret create` commands, reading from a file or stdin rather than an argument so the value never lands in shell history. Cover `--driver`, `--driver-opts`, and `--replace` for rotation.
4. **Inject with the right mode** — prescribe `--secret <name>` for the default mount at `/run/secrets/<name>`, versus `--secret <name>,type=env,target=VAR_NAME` when the app can only read env vars. Cover `target=`, `uid=`, `gid=`, and `mode=` for mount type, and explain why mount type is preferable (not visible in the process environment, not inherited by children).
5. **Wire it into Quadlet** — show the `Secret=` key in the `[Container]` section of the `.container` unit with the same options, and note that `podman secret` state must exist before the unit starts. Give the `systemctl --user daemon-reload` and start sequence, and where the unit file belongs (`~/.config/containers/systemd/` rootless, `/etc/containers/systemd/` rootful).
6. **Handle SELinux and rootless mapping** — confirm that the secret mount is labeled correctly for the container, and that `uid=`/`gid=` refer to the in-container IDs as mapped by the user namespace, not host IDs. Flag the common failure where a non-root container user cannot read a `mode=0400` root-owned secret.
7. **Define rotation and lifecycle** — describe rotating a secret (`podman secret rm` + recreate, or `--replace`) and why the container must be restarted to pick up a new value, since secrets are copied in at container creation. Give the restart or `systemctl --user restart` step.
8. **Verify** — commands proving the secret is present in the container, absent from `podman inspect`, absent from image history, and unreadable by other host users.

Output as: (a) exposure audit of the current setup, (b) chosen driver with rationale, (c) `podman secret create` commands, (d) corrected run flags, (e) Quadlet unit snippet, (f) rotation procedure, (g) verification commands with expected output.

Podman's default `file` driver stores secret values unencrypted on disk, protected only by file permissions on the containers storage directory. If the threat model includes host compromise or backup exfiltration, say so explicitly and recommend an external store rather than implying the built-in driver provides encryption at rest.