design issue for system wide pull secrets

[cgwalters]

In #1746 I did an initial PR to add system wide pull secrets, but used the PR as a way to basically propose a design. The development of that PR now continued in #2600

In retrospect that was a mistake; I should have started with an issue where we could get consensus on design and things like desirability.

Let's use this issue for that discussion, separate from the code.

---

The rationale in a nutshell is: often people want a "default" pull secret today and I think that applies to both standalone desktop/server cases with quadlet and Kubernetes. I would especially point out that in e.g. OpenShift we are very often pointing "podman" and similar tools at the kubelet pull secret (peruse this search for many examples).

Similarly I think on the Fedora bootc side (ref these docs) the ergonomics would be improved if we supported a default "service" pull secret; the original proposal was /etc/containers/auth.json but as of recently we had some agreement to take it to the full "config file spec" supporting /run and /usr too.

---

@mtrmac said in #1746 (comment)

I don’t really see value in a systemd-service-specific feature, the way this PR works now.

It's not technically specific to systemd or doesn't have to be. But I do want to avoid systemd services looking in /root by default for example or even /run/user/0 - both of these are "the root user" as distinct from "system".

I don’t feel strongly about a system-wide /etc/containers/auth.json read by everything. ... OTOH it needs to be constrained to such specific single-purpose systems, it should never be the default way flexible systems are built.

Of course, we're not dropping support for distinct pull secrets. Today Kubernetes/OpenShift style cases getting away from "the global pull secret" as a baseline and then supports per-pod credentials.

Our documentation could also encourage using service-specific credentials where it makes sense for quadlets.

But at the same time the core problem is that in the status quo people have an instinct to centralize these things, and using /root/.docker or /run/user/0/auth.json both have problems.