Re: [atomic-devel] Container data and uid/gid

[Clayton Coleman <ccoleman redhat com>]

----- Original Message -----
> >
> > 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).
> 
> 
> Would an SVirt style approach work here, where shared ownership is a
> product of common SElinux labeling?

I'm sure we have to have common labels as well.  

> 
> 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).
> 
> 
> Shucks, I was looking for an easy out and hoped I'd miss something.

Alas

> 
> -Matt M
> 
> 
> On Thu, Jan 8, 2015 at 12:26 PM, Clayton Coleman <ccoleman redhat com>
> wrote:
> 
> >
> >
> >
> > On Jan 8, 2015, at 9:16 AM, Matt Micene <nzwulfin gmail com> wrote:
> >
> > 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.
> >
> >
> > Yes
> >
> >
> > Especially 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 up
> >
> >   Would 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 M
> >
> > On 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.
> >> > >
> >> > >
> >> >
> >>
> >
> >
>