-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document how to authenticate to private container repository. #4180
Comments
Yeah we should document this better. Now, the choice of
I think it's for reasons similar to this that e.g. kubelet uses IMO...we should consider adding If we did that I'd say that ostree should change to honor it by default. |
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 |
Yeah, we use a custom auth file today by just forking The question here is more - do you agree it'd make sense to have |
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 In Kubernetes it's also expected that the system pull secret in |
Or to say this another way: there's a lot of precedent for storing system secret values in |
That sounds like a reasonable thing to do. I pull in @mtrmac, my trusted security advisor :^) |
This sounds plausible in principle, for But, uh, is the recommendation to run 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):
TBD details if the above is not a concern:
(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.) |
This.
So...this is a tricky topic. I think many users will want to set things up so that e.g. an Are you thinking of a |
I was just thinking about the container equivalent of “run It’s quite possible I’m just ignorantly blathering about an elegantly solved problem. |
These use cases today are using They should continue to use that; the proposed |
If /etc/containers/auth.json is roo:root 600, then I have no problem making rootful Podman/Buildah look there. |
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180 Signed-off-by: Colin Walters <[email protected]>
OK, I did containers/image#1746 |
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180 Signed-off-by: Colin Walters <[email protected]>
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180 Signed-off-by: Colin Walters <[email protected]>
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180 Signed-off-by: Colin Walters <[email protected]>
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180 Signed-off-by: Colin Walters <[email protected]>
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180 Signed-off-by: Colin Walters <[email protected]>
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180 Signed-off-by: Colin Walters <[email protected]>
A long-running tension in the docker/podman land is around running as a system service versus being executed by a user. (Specifically a "login user", i.e. a Unix user that can be logged into via `ssh` etc.) For login users, it makes total sense to configure the container runtime in `$HOME`. But for system services (e.g. code executed by systemd) it is generally a bad idea to access or read the `/root` home directory. On image based systems, `/root` may be dynamically mutable state in contrast to `/etc` which may be managed by OS upgrades, or even be read-only. For these reasons, let's introduce `/etc/contaners/auth.json`. If it is present, and the current process is executing in systemd, it will be preferred. (There's some further logic around this that is explained in the manpage; please see that for details) cc coreos/rpm-ostree#4180 Signed-off-by: Colin Walters <[email protected]>
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
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:
The text was updated successfully, but these errors were encountered: