Document how to authenticate to private container repository.

[jmarrero]

rpm-ostree uses skopeo to pull the images however we do have a specific system directory we expect the auth file to live in:

https://github.com/ostreedev/ostree-rs-ext/blob/3db50b0001eaba208b0943dd3c6c3074a03a432e/lib/src/globals.rs#L58

/etc/ostree/auth.json 

We need document how this path as it will be a common practice to push layered images into private repos.

Initial doc will likely look like:

podman login --authfile /etc/ostree/auth.json docker.io

[cgwalters]

Yeah we should document this better. Now, the choice of /etc/ostree/auth.json was intended to be explicitly separate from the containers defaults because:

• One might want to use separate pull secrets for "the host" versus application containers
• I consider the containers-stack using /root (and /run/users/0) to be ugly for things that are executed as system services.

I think it's for reasons similar to this that e.g. kubelet uses /var/lib/kubelet/config.json by default.

IMO...we should consider adding /etc/containers/auth.json that is only read when executing as part of a systemd unit or so. It would help keep things clearly separate from "the root user".

If we did that I'd say that ostree should change to honor it by default.

[rhatdan]

You could use the REGISTRY_AUTH_FILE and point the command there.

I would be fine with changing it, but that would be up to @vrothberg & @mitrmac

[cgwalters]

Yeah, we use a custom auth file today by just forking skopeo --authfile.

The question here is more - do you agree it'd make sense to have /etc/containers/auth.json which is clearly decoupled from "the root user" and is shared by "podman when run via systemd" as well as ostree?

[vrothberg]

The question here is more - do you agree it'd make sense to have /etc/containers/auth.json which is clearly decoupled from "the root user" and is shared by "podman when run via systemd" as well as ostree?

It sounds like a security risk to me if this file can be globally read by all users.

[cgwalters]

It sounds like a security risk to me if this file can be globally read by all users.

Right, the standard thing to do here is to refuse to read the file if it's world-readable; that's what e.g. ssh does with both ~/.ssh and /etc/ssh/ssh_host_ed25519_key for example.

In Kubernetes it's also expected that the system pull secret in /var/lib/kubelet/config.json is also mode 0600, though I don't think kubelet enforces that (it probably should).

[cgwalters]

Or to say this another way: there's a lot of precedent for storing system secret values in /etc, this would just be another one of those - again, cleanly separating "the system config" in /etc from "the root user" data in /root.

[vrothberg]

That sounds like a reasonable thing to do. I pull in @mtrmac, my trusted security advisor :^)

[mtrmac]

This sounds plausible in principle, for root-owned daemons. I’m not that sure it’s worth the extra complexity, primarily for users reading the man page and having an extra item in there, but I don’t feel strongly about that part.

But, uh, is the recommendation to run root-owned system services, or rootless Podman services? I’m not actually sure at all.

If it is rootless services, each started by systemd with its own UID (which sounds like much better-isolated approach to me, and more consistent with non-containerized system services):

• We would have to make the credentials file world-readable, which is a complete non-starter. Or maybe protected by an ACL that allows the right services, but the services would still not be isolated — worse than having per-service credential files.
• Or alternatively, we would have this feature that makes it easier to run containers in root-running systemd services using the discouraged security design, which seems undesirable: we would be doing work to make it easier for users to do the wrong thing.

TBD details if the above is not a concern:

• Specific ordering vs the other built-in defaults and environment variables.
• What’s the canonical way to check “we are in a systemd unit”, and “we are in a system (not user) systemd unit?

---

(Ideally, I think there should be a system secrets store, of some kind, unlocked on boot; and each systemd service should be given an unlocked per-service secrets store, by systemd, when it is started. We are clearly not there at all, almost everything is storing secret key material and credentials in files. Still, I’m trying to write down the ideal just to have something to move towards.)

[cgwalters]

But, uh, is the recommendation to run root-owned system services,

This.

If it is rootless services, each started by systemd with its own UID (which sounds like much better-isolated approach to me, and more consistent with non-containerized system services):

So...this is a tricky topic. I think many users will want to set things up so that e.g. an ExecStartPre=podman pull type thing ideally can use system-level privileges.

Are you thinking of a DynamicUser=yes type case? In that model, where podman is executed via the system systemd (i.e. not systemd --user) then we can just do ExecStartPre=-podman pull to ensure that part runs as root and hence can access the pull secret.

[mtrmac]

I was just thinking about the container equivalent of “run bind under a dedicated named user, not as root”. If the equivalent is to run all of podman inside that unit as the named user, that unit just can’t use root-only credential files. (ExecStartPre=podman pull as root would use root’s c/storage, and not affect the rootless storage used by the rootless podman run later.)

It’s quite possible I’m just ignorantly blathering about an elegantly solved problem.

[cgwalters]

These use cases today are using ${XDG_CONFIG_HOME}/containers/auth.json right? Particuarly if they're started by a login user that makes sense to me. For example, let's suppose an IoT device uses a pre-created static core user that is also used to ssh into.

They should continue to use that; the proposed /etc/containers/auth.json is just not for that use case.

[rhatdan]

If /etc/containers/auth.json is roo:root 600, then I have no problem making rootful Podman/Buildah look there.

[cgwalters]

OK, I did containers/image#1746