Add libpod API support for Podman via LIBPOD_* environment variables#47
Merged
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thanks for opening this pull request! Be sure to follow the pull request template!
thespad
approved these changes
Jun 13, 2026
github-project-automation
Bot
moved this from PRs
to PRs Approved
in Issue & PR Tracker
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Podman exposes two HTTP API groups on the same socket:
Projects like prometheus-podman-exporter cannot be placed behind this proxy because the libpod endpoints are not supported.
This PR adds support for libpod endpoints.
Description:
Adds
LIBPOD_*environment variables mirroring the existing Docker compat variables, one per libpod endpoint group (LIBPOD_CONTAINERS,LIBPOD_PODS,LIBPOD_IMAGES,LIBPOD_VOLUMES,LIBPOD_NETWORKS,LIBPOD_INFO,LIBPOD_EVENTS,LIBPOD_EXEC,LIBPOD_GENERATE,LIBPOD_MANIFESTS,LIBPOD_PLAY,LIBPOD_SECRETS,LIBPOD_SYSTEM).LIBPOD_PING=1andLIBPOD_VERSION=1are enabled by default, consistent with their Docker compat counterparts.Adds lifecycle action overrides for libpod containers (
LIBPOD_ALLOW_START,LIBPOD_ALLOW_STOP,LIBPOD_ALLOW_RESTARTS,LIBPOD_ALLOW_PAUSE,LIBPOD_ALLOW_UNPAUSE) and Podman-specific pod lifecycle (LIBPOD_ALLOW_POD_START,LIBPOD_ALLOW_POD_STOP,LIBPOD_ALLOW_POD_RESTARTS,LIBPOD_ALLOW_POD_PAUSE,LIBPOD_ALLOW_POD_UNPAUSE), all of which bypassPOST=0just like the Docker compat ALLOW_* vars.All new variables default to 0 (deny), preserving the existing security posture for Docker-only users.
The current implementation uses one independent env var per libpod endpoint. This is the most conservative and consistent approach (matches the existing Docker compat model).
I also thought about coupled flags via a global
LIBPOD=1— a single LIBPOD flag that, when set to 1, automatically enables the libpod counterpart of any already-enabled Docker compat endpoint. SoIMAGES=1+LIBPOD=1would implicitly allow /libpod/images. This reduces configuration verbosity for operators who want symmetric access across both API groups, but makes the permission model less explicit.Benefits of this PR and context:
Add podman compatibility to
docker-socket-proxy.How Has This Been Tested?
This has been tested with prometheus-podman-exporter running under docker-socket-proxy.
Before this PR
With this PR
With the following env :Source / References: