Learn more about these different git repos.
Other Git URLs
Containers are becoming really hot last several months. It becomes apparent that we need to react sooner rather than later. I have been having different discussions with groups working on containers. Here are the to main use cases we need to address:
- Serving different identity data to the processes running in two different containers - When user SSH into a machine and into a container SSSD should be able to enforce HBAC rules.
We can probably fork this into several tickets in future.
Based on the recent discussion with container engineers the recommendation was to leverage environment variables with something like the following
a. When container is started we assume that there is an env var CONTAINER_NAMESPACE (for example) b. When a process connects to SSSD it will look at the peer process on the other side of the socket. c. Then it will check that the process is running inside a container. There is no call to do this yet. There are couple options: to traverse /proc/pid/cgroup and determine when container the process belongs to or to ask systemd to implement a call. This needs to be sorted out as traversing /proc seems like a hack (though several people independently suggested this). Assume we got a container ID as a result of this lookup. d. Using this ID we will ask docker about the CONTAINER_NAMESPACE variable and use its value to determine SSSD source/domain (or sources) to use. See "inspect" call in the docker API: http://docs.docker.io/en/latest/api/docker_remote_api_v1.6/ e. If variable not set or the process is not inside a container SSSD will use reasonable defaults.
This effort is somewhat related to #1021 and to have ability to serve different source/domains to different applications running on the system.
For the SSH case it seems that every container needs to be exposed as a virtual host. The we would be able to apply all the HBAC rules. It is unclear how this will be accomplished so we need to continue a discussion.
This ticket absolutely requires a design. The ideas above are triaged with container guys but still need to be more formally recorded and reviewed.
Docker containers are mostly used as lightweight VMs. Wouldn't this be more targeted at other containerized environments like OpenShift?
Adding Jan P. as well.
Fields changed
cc: => jpazdziora@redhat.com
On 11/14/2013 10:15 AM, Daniel P. Berrange wrote:
On Thu, Nov 14, 2013 at 09:07:37AM -0600, Josh Poimboeuf wrote: On Thu, Nov 14, 2013 at 09:58:33AM -0500, Aristeu Rozanski wrote: On Wed, Nov 13, 2013 at 06:13:06PM -0500, Dmitri Pal wrote: Is there an easy call to see if a process on the other side of the socket is running in a container and in which one? High level you could use libvirt for that. Which libvirt interface would give this? I looked but didn't see one. There isn't one to report this, but conceivably one could be designed. If it'll be implemented manually, checking process' cgroup in proc and /proc/<pid>/ns/* files to determine which namespaces it's attached on. True, though how would you convert the namespace id to a docker or libvirt container name? I don't think you'd want to try such a conversion - if we wanted this, you'd want a formal API for it whose semantics could be guaranteed long term. Daniel Yes this is seems like what I am really looking for.
On Thu, Nov 14, 2013 at 09:07:37AM -0600, Josh Poimboeuf wrote:
On Thu, Nov 14, 2013 at 09:58:33AM -0500, Aristeu Rozanski wrote: On Wed, Nov 13, 2013 at 06:13:06PM -0500, Dmitri Pal wrote: Is there an easy call to see if a process on the other side of the socket is running in a container and in which one? High level you could use libvirt for that. Which libvirt interface would give this? I looked but didn't see one. There isn't one to report this, but conceivably one could be designed. If it'll be implemented manually, checking process' cgroup in proc and /proc/<pid>/ns/* files to determine which namespaces it's attached on. True, though how would you convert the namespace id to a docker or libvirt container name? I don't think you'd want to try such a conversion - if we wanted this, you'd want a formal API for it whose semantics could be guaranteed long term.
On Thu, Nov 14, 2013 at 09:58:33AM -0500, Aristeu Rozanski wrote:
On Wed, Nov 13, 2013 at 06:13:06PM -0500, Dmitri Pal wrote: Is there an easy call to see if a process on the other side of the socket is running in a container and in which one? High level you could use libvirt for that. Which libvirt interface would give this? I looked but didn't see one. There isn't one to report this, but conceivably one could be designed. If it'll be implemented manually, checking process' cgroup in proc and /proc/<pid>/ns/* files to determine which namespaces it's attached on. True, though how would you convert the namespace id to a docker or libvirt container name? I don't think you'd want to try such a conversion - if we wanted this, you'd want a formal API for it whose semantics could be guaranteed long term.
On Wed, Nov 13, 2013 at 06:13:06PM -0500, Dmitri Pal wrote:
Is there an easy call to see if a process on the other side of the socket is running in a container and in which one? High level you could use libvirt for that. Which libvirt interface would give this? I looked but didn't see one. There isn't one to report this, but conceivably one could be designed.
If it'll be implemented manually, checking process' cgroup in proc and /proc/<pid>/ns/* files to determine which namespaces it's attached on. True, though how would you convert the namespace id to a docker or libvirt container name? I don't think you'd want to try such a conversion - if we wanted this, you'd want a formal API for it whose semantics could be guaranteed long term.
Daniel Yes this is seems like what I am really looking for.
The framework might be not ready for us to use by 1.12.
milestone: NEEDS_TRIAGE => SSSD 1.12 beta
rhbz: => todo
priority: major => blocker
Lukas is working on this effort.
owner: somebody => lslebodn
Related ticket https://fedorahosted.org/sssd/ticket/2312
Moving forward as an ongoing tracker.
milestone: SSSD 1.12 beta => SSSD 1.12.1
milestone: SSSD 1.12.1 => SSSD 1.13 beta
Related ticket - #2438
blockedby: => 2438
mark: => 1
blockedby: 2438 => 2438, 2476
We decided to de-prioritize this effort for the 1.13 upstream release during our face-to-face plannings in Brno. Moving to 1.13 backlog.
milestone: SSSD 1.13 beta => SSSD 1.13 backlog priority: blocker => major
Mass-moving tickets not planned for the 1.13 release to 1.14
milestone: SSSD 1.13 backlog => SSSD 1.14 beta
cc: jpazdziora@redhat.com => jpazdziora@redhat.com, jheiss@aput.net sensitive: => 0
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1201262 (Red Hat Enterprise Linux 7)
rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1201262 1201262]
There is a separate sssd-docker container in RHEL these days, so this work is done. Additional work should be tracked with separate tickets, but I'm going to close this one.
milestone: SSSD 1.14 beta => SSSD 1.14 alpha resolution: => fixed status: new => closed
And fedora version of sssd container is already in docker hub for some time https://hub.docker.com/r/fedora/sssd/
Metadata Update from @dpal: - Issue assigned to lslebodn - Issue marked as depending on: #2261 - Issue marked as depending on: #2438 - Issue marked as depending on: #2476 - Issue set to the milestone: SSSD 1.14 alpha
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3193
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.