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.
> >
> >
>