Enable cert authentication for container content/flatpaks

Development RFCs
,
1

Decision Due Date: 04/20/2025
Hello Community,

This proposal is the first step in enabling certificate authentication for container content(which is also the backend for our flatpak support).

What this is not:
To make things clear, this is not related to the “protected” repository field we use to guard content on pulp distributions. Access to container content will continue to be protected by katello and not by pulp content-guard.

Current state:

Today, container content access is granted using basic authentication with username/password. This includes podman login for container content as well as podman login and copying generated auth file for flatpak access. Once the user is authenticated and a token returned to requesting client, we use the token for all future communications.

Motivations:

  1. Client authentication using consumer certs will allow us to authenticate repository access based on Content View/LCE of the registered host. Today once the user logs in on a client, they immediately have access to all container repositories regardless of Content View Environments it is registered to.
  2. Having cert auth will eliminate the need to pass around user credentials to an already registered host and for other automated workflows.
  3. This will allow us to reduce the number of repositories we expose for a client on our flatpak registry. Today since user based auth grants access to all repositories, we rely on the request IP and map it to host to grant access which is not ideal and difficult to extend to proxies. Using cert auth will help us in designing a better solution for Flatpaks, smart proxies, and lifecycle management - #11 by iballou.

Proposed design:

  1. Podman/flatpak have support for image/docs/containers-certs.d.5.md at main · containers/image · GitHub .
  2. With the correct certs placed in the directory for katello/proxy registry, podman and flatpak clients are able to serve these certs to registry for authentication.
    a) We can update Global registraion template to automate the placement of certs in the right directory.
    b) We can provide REX templates to do this on managed hosts.
  3. We will enable katello registry and proxy registry to be able to authenticate the certs for a request.

Note:

  1. We will continue to use user auth for uploading container content. That follows the pattern for other content uploads.
  2. We are going to be able to support cert auth only for EL10 clients and not below cause the flatpak client support for container certs is not available in older versions. The older clients will continue to use user auth. User auth is also the fallback for EL10 clients without certs in the right directory.

Decision

We will update this proposal with the final decision regarding whether or not we should implement this proposal and, if so, the updated design after all the questions and feedback are received and resolved.

2 Likes
2

Isn’t the consumer cert already on the registered host? What directory are we putting it in? Does it require making a copy of the cert?

1 Like
3

Is this a different token than Personal Access Tokens?

When using sub-man, would these be a copy of the certificates or would you opt for a symlink?

4

We want to create the structure as defined in image/docs/containers-certs.d.5.md at main · containers/image · GitHub which requires the directory name to correspond to the hostname. So we need to copy the /etc/pki/ consumer certs that sub-man creates to the /etc/containers/certs.d/katello_hostname/ for the podman/flatpak clients to read.

5

Today it is the Personal access token we create against the user. We don’t need to continue using tokens and rely completely on cert auth or we could enhance the Personal access tokens to support hosts along with users as we discussed offline. That is a good decision to make… :slight_smile:

I hadn’t thought of symlinks and haven’t tested it but I don’t see why that wouldn’t work. This will also remove the need to manage updates to the certs. :heart:

6

If we can avoid tokens, that feels like it would avoid then having to manage the tokens (expiration, deletion etc.). Token management for hosts would likely require more UI elements to understand them.

That was where my thinking was leaning – how to ensure the certificates get updated when a user performs some action that updates the certificates.

2 Likes
7

+1 to using symlinks so we don’t have to keep another thing in sync. But when sub-man changes your certs, I think the file names would also change…

8

That would not happen with consumer certs in /etc/pki/consumer right. IIRC, it’s the entitlement certs that change names?

9

Oh right, they’re just called cert.pem and key.pem. So that should be fine. :+1:

1 Like
10

One more thing that I found in my testing is we can’t use the consumer *.pem directly but renaming to .key and .cert works fine. It may change some implementation details.

Another thing is we are going to be able to support this only for EL10 clients and not below cause the flatpak client support for container certs is not available in older versions. The older clients will continue to use user auth. User auth is also the fallback for EL10 clients without certs in the right directory. I’ll add this to the RFC text above for visibility.

2 Likes
11

What is the client that supports it? That means that for podman certificate auth won’t work?

12

podman has had this support for a while AFAIK…I’d expect EL9 to have it but I’ll need to verify that. flatpak support only landed in EL10…