`podman login` with SPIFFE Workload Identity Tokens

[adambkaplan]

Feature request description

podman login supports HTTP basic authentication (username/password) as well as authentication from token-based credentials in a relevant auth/config.json file.

This feature would add support for authenticating with container registries using SPIFFE Verifiable Identity Documents (SVID).

Suggest potential solution

Prerequisites

• SPIRE or other SPIFFE-compliant workload identity agent running on host.
• Registry is set up with an appropriately configured federated identity provider that trusts the domain that the SPIFFE-compliant agent belongs to.

Potential Solution

• User experience:

  podman login [registry] --use-workload-id \
    --workload-id-provider=https://registry.domain/oauth2/federation
    --spiffe-endpoint=unix:///run/spire/sockets/spire-agent.sock

• Execution:
  • Podman requests the workload SVID through the spiffe-endpoint.
  • Podman exchanges the SVID for an OIDC token at the proivded workload-id-provider endpoint
  • OIDC token is utilized to complete the authentication with the container registry.

Have you considered any alternatives?

The current "status quo" - do the SVID/OIDC token exchange outside of Podman, then pass it in as the --password. Example here

Additional context

Working with SVIDs - SPIFFE documentation

[adambkaplan]

I could see this working in tandem with a distribution providing "out of the box" support for SPIRE - see Fedora discussion.

[mheon]

Is SPIFFE support standardized in the OCI distribution spec?
@mtrmac PTAL

[mtrmac]

I know nothing about this problem space, I never studied SPIFFE.

Just quickly looking at the motivation statement…

  podman login [registry] --use-workload-id \
    --workload-id-provider=https://registry.domain/oauth2/federation
    --spiffe-endpoint=unix:///run/spire/sockets/spire-agent.sock

No-one is going to voluntarily write things like that, definitely not interactively. Wouldn’t it be much easier for the workload creator (which presumably has the information that the workload is allowed to access a container registry) to pre-populate an auth.json in the workload?

Also, how does this scale? Would every single software authenticating to… any HTTP service at all … need a specialized SPIFFE support? Is Podman truly a special case?

As a guess,

do the SVID/OIDC token exchange outside of Podman, then pass it in as the --password

(or setting identitytoken in auth.json) looks like the appropriate boundary between Podman and the rest of the world.

---

Is SPIFFE support standardized in the OCI distribution spec? @mtrmac PTAL

The spec does not deal with authentication at all (e.g. opencontainers/distribution-spec#240 ).

I can’t see anything related in docker/docker nor distribution/distribution. (There is some support for OpenID (? -like?) code to get a token based on a refresh token or an username:password, but, again, obtaining the refresh token needs to happen externally.)

[Luap99]

I have not used them but isn't this one reason why credential-helpers exists? So external tools can perform more complex authentications themselves and just hand the token to podman?

[adambkaplan]

I have not used them but isn't this one reason why credential-helpers exists?

I totally forgot about these! The user experience, from what I understand, is twofold:

• User installs a binary that acts as the "credential helper"
• User updates their auth.json to tell podman to use the credential helper when logging in to a provided registry:

{
  "credHelpers": {
    "quay.io": "spire-login"
  }
}

...and if all works well, the developer just needs to run podman login <registry> && podman ...

Is the podman credential helper interface/protocol the same as Docker's?

[adambkaplan]

Also, how does this scale? Would every single software authenticating to… any HTTP service at all … need a specialized SPIFFE support? Is Podman truly a special case?

Podman is certainly not a special case. SPIFFE's architecture is designed to replace any current flow that uses static username/passwords or long-lived tokens (expire in days -> year) with ephemeral certificates and tokens (expiration measured in hours or less).

Does everything need SPIFFE support? No. Could it make for a pleasant user experience - maybe?

[adambkaplan]

Found this old issue - is rootless mode still a concern when implementing a credential helper? #4123

[Luap99]

Found this old issue - is rootless mode still a concern when implementing a credential helper? #4123

I cannot speak for the issue but rootless podman runs inside a custom userns so any tool we exec there will be inside that that and must be able to deal with such an unusual env, i.e. being uid 0 but not having access to any real root things. As long as the tool using $HOME and other XDG_ env the paths it should be fine most likely.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[mtrmac]

I think a credential helper outside of Podman is the best way forward.

Please reopen, or file a new issue, if it turns out to be impossible due to the user namespace environment.