Kube has to have a concept of attribution (ownership of X implies ownership of Y), so we would make it an admins responsibility to configure the system in such a way that uids/gids are secure and fair (Kube has effective root on hosts anyway).
It does not, I merely wanted to dovetail the large scale concern so folks would be aware of the potential impact when dealing with individual containers (customers in the short term could need to build images with specific uids/gids in order to accomplish cluster wide volume sharing, in the long term user namespaces may reduce the need for that).
I do agree this is an issue, but its one that's exacerbated by containers not created by them. It makes more sense to me do try to accomplish this at the orchestration layer that has visibility to the platform and the containers.YesEspecially at a pod layer where it's critical to match UID/GID. Question here, would it require the use of Kubernetes volumes not Docker volumes to accomplish?Kubernetes volumes are docker volumes, but as you note the orchestrator is the one who needs to pair those upWould etcd be useful in this case to provide a specific set of UID/GID combos to containers? Security issues with that approach?Kube has to have a concept of attribution (ownership of X implies ownership of Y), so we would make it an admins responsibility to configure the system in such a way that uids/gids are secure and fair (Kube has effective root on hosts anyway).I don't think this addresses the rpm-ostree issue as that isn't container related, is it Colin? Am I misinterpreting that the potential issue comes from local changes vs composed changes that affect UID/GID assignments?It does not, I merely wanted to dovetail the large scale concern so folks would be aware of the potential impact when dealing with individual containers (customers in the short term could need to build images with specific uids/gids in order to accomplish cluster wide volume sharing, in the long term user namespaces may reduce the need for that).-Matt MOn Wed, Jan 7, 2015 at 5:16 PM, Clayton Coleman <ccoleman redhat com> wrote:At some point in the near future we're going to try and define global uid allocation (or a means whereby someone can do global uid allocation) for containers in Kubernetes. It's too important a problem for real customers (there's no other way to have consistent security across tens or hundreds of machines) to go without.
----- Original Message -----
> I may be overstating the case a bit, but ensuring uid/gid matches on shared
> volumes (regardless of Docker or otherwise) has always been a manual
> process. I'm thinking even of the dark days with ORCL db usernames and
> shared storage volumes. The only wrinkle here is we're talking about a
> UID/GID set that gets created by the RPM, not by an admin. I've had issues
> with install order on systems creating UID/GID issues for shared or
> migrated content for as long as I've been an admin.
>
> The OStree issue seems to be a merge issue, what happens if a locally
> created entity collides with a system created entity. Install order should
> always be the same, and if everyone is respecting the standards for system
> / local UID numbering, the inside the container issue goes back to admin
> hygene as they stray into complex container environments.
>
> Or am I putting too much on the admin?
>
> -Matt M
>
>
> On Wed, Jan 7, 2015 at 3:40 PM, Colin Walters <walters verbum org> wrote:
>
> > Interesting discussion here:
> >
> > https://fedorahosted.org/fpc/ticket/474
> >
> > This is quite similar to the issues with rpm-ostree in
> > https://github.com/projectatomic/rpm-ostree/issues/49
> >
> > I think we're going to need some tooling to help ensure repeatable uid
> > allocation when building Docker containers.
> >
> >
>