Secret driver plugins #27856
Description
Feature request description
Secrets don’t support a plugin API like volume plugins or credential helpers. Any new drivers have to be added to containers/container-libs.
Suggest potential solution
Add a plugin API for secret drivers.
Secret driver plugins would be executable binaries like credential helpers, registered by name in containers.conf.
# example only; exact syntax tbd
[secrets.driver_plugins]
systemd-creds = "/usr/libexec/podman-secret-systemd-creds"Once registered they can be invoked using --driver, with per-secret configuration passed via --driver-opts, just like native drivers.
printf "secretdata" | podman secrets create \
--driver systemd-creds
--driver-opts 'with-key=host+tpm2'
db_password -Have you considered any alternatives?
Initially I considered extending the shell driver to pass all unknown options to the script using environment variables. While this addresses my immediate issue, scripts ran via the shell driver have inherent limitations compared to a native driver in terms of usability and inspection.
I also considered the approach outlined by #26488, which proposes a plugin system for secrets that aren’t backed by Podman resources. That approach avoids the need to create a secret first, which is convenient when secrets are managed externally. However, it’s a major departure from the existing model.
Additional context
Secret plugins would only require additive changes to the secrets package and containers.conf. The existing drivers and configuration would not be touched.
There would be no changes to the way secrets are injected into containers by Podman as part of this work. Improvements to secret injection (i.e. using a tmpfs) are orthogonal to the driver interface.
I’m happy to draft a PR once there is agreement on the overall direction.
Relevant issues and discussions: