Re: [Freeipa-users] client/authentication inside a docker container
On Thu, Feb 04, 2016 at 12:37:07PM -0500, Prasun Gera wrote: > On Thu, Feb 4, 2016 at 10:56 AM, Jan Pazdziora > wrote: > > > > The goal is to run the > > > docker container such that when the user calls docker run, > > > > Is any user allowed to run docker run? That seems like a security > > issue. > > Well any user that can do sudo should be able to run docker. Is there a > security issue with that ? You need to limit those sudo calls to very specific list of parameters that can be passed to the docker client, otherwise it has the potential of running any command. > > > it just drops > > > into a shell with the container's environment, but everything else looks > > > largely the same. i.e. The user gets the same uid:gid and sees the same > > > directories and permissions as the host. > > > > So you want bash started in the container, with the uid:gid of the > > person invoking the command? If the users are trusted to do docker > > run, they can do > > > > docker run -u $UID container bash > > > > themselves. > > Yes, this is similar to the 3rd point I mentioned. The problem though is > that directory listings will not show names inside the container. They'll In that case, having sssd-client package installed in the container and /var/lib/sss mounted to the container could help. > only show uids and gids. NIS solves this as a quick hack, but is there > something better ? Permissions would still work since NFS is not > kerberized. Another issue I haven't figured out is how the user can get > sudo inside the container. If you start docker with the user's uid, I don't > know if there is a safe way for that user to get sudo inside. If you start > docker in the root shell, you can create the user with the uid:gid, add it > to sudoers, and then change to the user's shell ? Yes. If you have /var/lib/sss mounted and sssd-common (or libsss_sudo in new versions) installed in the container, you can even use the sudo rules from IPA. > > But you likely do not want to give every user a way to run any command, > > why not just use sudo, and > > > > docker run -u $SUDO_UID container bash > > > > in the script invoked with the sudo (untested)? > > I didn't follow this. Can you explain a bit more ? In the default setup, > you anyway need sudo to run docker. Not really -- access to docker's Unix socket is all that the docker client needs. > What is the -u string here ? Setting the uid under which the container processes are run back to the invoking user. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] client/authentication inside a docker container
On Thu, Feb 4, 2016 at 4:23 PM, Nordgren, Bryce L -FS wrote: > An RHEL 7 host filesystem may have the same basic structure as an Ubuntu > trusty container filesystem, but may have different users defined, > particularly for running services and for owning the files those services > must touch. To what extent do you want the same users to be enforced > between the container and the host? Is it OK for service accounts to be > different, as long as user/login/people accounts are the same? > > > Yes, that would be OK. I think all I need is that the files touched inside the container look consistent permissions-wise to files that you see on the host, and vice-versa. As such, I don't need authentication inside the container since we don't need to host any services in the container. I just need 1:1 mapping for uid:gid for regular users. > It almost sounds like you’re using containers to isolate user environments > and processes, but you’re accumulating data from/sharing data between > containers…Which implies that the processes generating the data run as the > user and not as a system service. It may be easier to wrap whatever program > you’re running as a web service so the users don’t have to log in and your > uid:gid problem goes away. > > > Yes, I've just got started with Docker, and trying to use it as a way to isolate development environment. We have a tool which has some weird toolchain dependencies (old versions of gcc, boost, bison, and possibly a few others), which would make it very hacky to compile/run it natively on all systems. I think docker solves that problem such that whenever the use wants to use that tool, they can just drop into the docker container and work there. > Bryce > > > > *From:* freeipa-users-boun...@redhat.com [mailto: > freeipa-users-boun...@redhat.com] *On Behalf Of *Prasun Gera > *Sent:* Thursday, February 04, 2016 8:19 AM > *To:* freeipa-users@redhat.com > *Subject:* [Freeipa-users] client/authentication inside a docker container > > > > I am trying to set up a docker image with a specific development > environment. We use idm 4.2 for authentication, and non-kerberized nfs > (including home) for data storage on the hosts. The goal is to run the > docker container such that when the user calls docker run, it just drops > into a shell with the container's environment, but everything else looks > largely the same. i.e. The user gets the same uid:gid and sees the same > directories and permissions as the host. I'm trying to figure out what the > best way of mapping user ids is. I've looked at the following options: > >- ipa-client-install inside the container. This has a few problems. >One is hostname and DNS. Container needs an fqdn for this to work, and the >dns has to resolve this hostname. We are not using IPA's DNS. So this whole >approach looks very kludgy. Besides, I'm not sure what the right way of >handling these ephemeral host names is. Ideally, they should be un-enrolled >when the container is destroyed, >- Use ipa's fake NIS. This works, and is very simple to setup, but I >think we want to phase out NIS. If we start using it inside docker, it will >never die >- Don't do any domain authentication. Just ask the user to create a >user with the same uid:gid as the host so that they can r/w to their own >directories. > > The ipa version is 4.2 running on RHEL 7. The container image will be > based on ubuntu trusty. Hosts are a mix of different OSes. > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] client/authentication inside a docker container
An RHEL 7 host filesystem may have the same basic structure as an Ubuntu trusty container filesystem, but may have different users defined, particularly for running services and for owning the files those services must touch. To what extent do you want the same users to be enforced between the container and the host? Is it OK for service accounts to be different, as long as user/login/people accounts are the same? It almost sounds like you’re using containers to isolate user environments and processes, but you’re accumulating data from/sharing data between containers…Which implies that the processes generating the data run as the user and not as a system service. It may be easier to wrap whatever program you’re running as a web service so the users don’t have to log in and your uid:gid problem goes away. Bryce From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Prasun Gera Sent: Thursday, February 04, 2016 8:19 AM To: freeipa-users@redhat.com Subject: [Freeipa-users] client/authentication inside a docker container I am trying to set up a docker image with a specific development environment. We use idm 4.2 for authentication, and non-kerberized nfs (including home) for data storage on the hosts. The goal is to run the docker container such that when the user calls docker run, it just drops into a shell with the container's environment, but everything else looks largely the same. i.e. The user gets the same uid:gid and sees the same directories and permissions as the host. I'm trying to figure out what the best way of mapping user ids is. I've looked at the following options: * ipa-client-install inside the container. This has a few problems. One is hostname and DNS. Container needs an fqdn for this to work, and the dns has to resolve this hostname. We are not using IPA's DNS. So this whole approach looks very kludgy. Besides, I'm not sure what the right way of handling these ephemeral host names is. Ideally, they should be un-enrolled when the container is destroyed, * Use ipa's fake NIS. This works, and is very simple to setup, but I think we want to phase out NIS. If we start using it inside docker, it will never die * Don't do any domain authentication. Just ask the user to create a user with the same uid:gid as the host so that they can r/w to their own directories. The ipa version is 4.2 running on RHEL 7. The container image will be based on ubuntu trusty. Hosts are a mix of different OSes. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] client/authentication inside a docker container
On Thu, Feb 4, 2016 at 10:56 AM, Jan Pazdziora wrote: > On Thu, Feb 04, 2016 at 10:19:16AM -0500, Prasun Gera wrote: > > I am trying to set up a docker image with a specific development > > environment. We use idm 4.2 for authentication, and non-kerberized nfs > > (including home) for data storage on the hosts. > > Are the hosts IPA-enrolled? > > Yes. > > The goal is to run the > > docker container such that when the user calls docker run, > > Is any user allowed to run docker run? That seems like a security > issue. > > Well any user that can do sudo should be able to run docker. Is there a security issue with that ? > > it just drops > > into a shell with the container's environment, but everything else looks > > largely the same. i.e. The user gets the same uid:gid and sees the same > > directories and permissions as the host. > > So you want bash started in the container, with the uid:gid of the > person invoking the command? If the users are trusted to do docker > run, they can do > > docker run -u $UID container bash > > themselves. > > Yes, this is similar to the 3rd point I mentioned. The problem though is that directory listings will not show names inside the container. They'll only show uids and gids. NIS solves this as a quick hack, but is there something better ? Permissions would still work since NFS is not kerberized. Another issue I haven't figured out is how the user can get sudo inside the container. If you start docker with the user's uid, I don't know if there is a safe way for that user to get sudo inside. If you start docker in the root shell, you can create the user with the uid:gid, add it to sudoers, and then change to the user's shell ? > But you likely do not want to give every user a way to run any command, > why not just use sudo, and > > docker run -u $SUDO_UID container bash > > in the script invoked with the sudo (untested)? > > I didn't follow this. Can you explain a bit more ? In the default setup, you anyway need sudo to run docker. What is the -u string here ? -- > Jan Pazdziora > Senior Principal Software Engineer, Identity Management Engineering, Red > Hat > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] client/authentication inside a docker container
On Thu, Feb 04, 2016 at 10:19:16AM -0500, Prasun Gera wrote: > I am trying to set up a docker image with a specific development > environment. We use idm 4.2 for authentication, and non-kerberized nfs > (including home) for data storage on the hosts. Are the hosts IPA-enrolled? > The goal is to run the > docker container such that when the user calls docker run, Is any user allowed to run docker run? That seems like a security issue. > it just drops > into a shell with the container's environment, but everything else looks > largely the same. i.e. The user gets the same uid:gid and sees the same > directories and permissions as the host. So you want bash started in the container, with the uid:gid of the person invoking the command? If the users are trusted to do docker run, they can do docker run -u $UID container bash themselves. But you likely do not want to give every user a way to run any command, why not just use sudo, and docker run -u $SUDO_UID container bash in the script invoked with the sudo (untested)? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] client/authentication inside a docker container
I am trying to set up a docker image with a specific development environment. We use idm 4.2 for authentication, and non-kerberized nfs (including home) for data storage on the hosts. The goal is to run the docker container such that when the user calls docker run, it just drops into a shell with the container's environment, but everything else looks largely the same. i.e. The user gets the same uid:gid and sees the same directories and permissions as the host. I'm trying to figure out what the best way of mapping user ids is. I've looked at the following options: - ipa-client-install inside the container. This has a few problems. One is hostname and DNS. Container needs an fqdn for this to work, and the dns has to resolve this hostname. We are not using IPA's DNS. So this whole approach looks very kludgy. Besides, I'm not sure what the right way of handling these ephemeral host names is. Ideally, they should be un-enrolled when the container is destroyed, - Use ipa's fake NIS. This works, and is very simple to setup, but I think we want to phase out NIS. If we start using it inside docker, it will never die - Don't do any domain authentication. Just ask the user to create a user with the same uid:gid as the host so that they can r/w to their own directories. The ipa version is 4.2 running on RHEL 7. The container image will be based on ubuntu trusty. Hosts are a mix of different OSes. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
