On new applications and use cases for container technology

As containerization goes mainstream, many are finding new applications and use cases for container technology. Jan Pazdziora, senior principal software engineer at Red Hat, faced the limitations of traditional Docker when he wanted to containerize FreeIPA. This led to creation of his Docker-freeipa open source work.

Jan has a talk coming up on the project at this year's LinuxCon Europe. Jan has rich experience in open source, and we had a productive time discussing topics ranging from complex use cases for Docker, to open source software as a whole, and the future of Perl.

The topic of your talk, "Complex Applications in Containers," is both intriguing and a little puzzling, as we don't usually expect Docker to be used this way. Can you please tell us a bit about it?

When exploring the container technology and the possibility of using it for parallel installations of FreeIPA for testing and other purposes, I certainly tried to "follow the book" and properly isolate individual pieces into separate containers. However, the server comprises of multiple interconnected components, configuring numerous OS-level components and libraries. For example, the Kerberos configuration is used for authenticating communication among the individual parts, so it needs to be available to all of them. I would need to bind-mount many configuration directories and files into many containers, something which is easy do wrong with plain Docker.

Furthermore, the configuration program ipa-server-install that sets up all the components plays an important role in the overall value of the FreeIPA project by making the setup consistent and easy to achieve from admin's point of view. It assumes all parts get configured and run on a single machine. We could have waited with the containerization effort until it gets refactored to support installation on multiple hosts, rewritten the logic using Docker tools, or just used the configuration tool directly and adapted the environment within the container. Since the setup tool makes a heavy use of systemctl calls when enabling the individual services and restarting them, using systemd in the container was the initial plan.

Eventually, we went with a custom systemctl to emulate just enough of the systemd functionality needed for the services we need. That gave us the most control while keeping the solution lean.

What do you think of the state of containerization? What needs to be done before containers are seen as mission critical and enterprise ready?

It depends on the use-case. For some of them, containers are already there and organizations and companies use them. For certain deployments, additional plumbing will likely be needed to give people building the solutions easy and flexible control over combining the containers and the host environments for secure setups. It's important to remember containers are actually multiple different technologies that may not all be utilized in a particular deployment.

You can have containerized application which just uses cgroups to set resource limits, filesystem namespaces to use a particular libraries or JVM version, and perhaps SELinux for container isolation, but does not need UID or PID namespacing. Unlike virtual machines, the boundaries of containers can be more flexible, and sometimes blurred.

The work on Docker-freeipa is actually part of the effort of making containers enterprise ready—bringing identity management into containerized environments—and not just the server side being able to run FreeIPA in the container. The project also contains client-side branches with System Security Services Daemon (SSSD), and we actively explore ways of consuming external identities and authentication in containers.

Docker security is a huge concern. What still needs to be done to plug security holes in Docker?

I believe some of the issues stem from the fact that people view Linux container technology and Docker containers as functionally equivalent to virtual machines, just with lower footprint, rather than as enhanced chroot environments. The carelessness with which they run processes based on random images downloaded from various sources is a result of perceived ease of use, and it will need to be addressed both with education and raising awareness, and with tools making it much more obvious what is being downloaded and run, and how. For deeper insight into security aspects of Docker, Dan Walsh is much more qualified, as he actively works with Docker's internals.

As you said, the traditional approach of Docker has been to deploy each component in an independent container and link them together. As the applications are becoming complex, this is becoming a limitation, which is the problem you are trying to solve with Docker-freeipa. Do you think there is scope for a "Docker orchestration service" that bundles the mini-containers and creates an uber-container?

If an application consists of four containers and you need for all of them to be running to deliver some value to the users, people will be searching for ways to describe the relationships between containers via some more persistent ways than --link and -v options to Docker run commands. Docker Compose, Kubernetes Pods, or similar projects might be the answer.

Whether the orchestration itself should run as a container or is just a definition in a file and runtime state of some daemon, I don't dare to speculate.

You have immense experience in the world of identity management. Traditionally dominated by proprietary products, open source solutions such as OpenAM and OpenIDM have been slowly making an impact. Is open source identity management production-ready? Do you have any examples of how open source IM is being deployed?

There are different levels of identity management software. People usually confuse them because this is a complex area. OpenAM and OpenIDM are more Web-application-level technologies on top of infrastructure and clouds. I would not comment on those technologies and their readiness for the enterprise. It is probably better to get opinion of someone closely working with those projects.

The infrastructure and clouds under the hood need platform-level identity management capabilities. In case of Windows, this has been traditionally solved by Active Directory and a whole ecosystem of related integrated components product offerings. In the open source world, FreeIPA that can nicely integrate with Active Directory by the way of cross-forest Kerberos trusts takes this role. It is definitely production-ready and has been deployed in multiple production environments. Red Hat offers a supported version called Identity Management (IdM) in Red Hat Enterprise Linux. Over the last several years we have seen a steady growth of production deployments on Fedora, Red Hat Enterprise Linux, and CentOS platforms.

Organizations use them to centrally manage access to Linux machines and services running on them, sometimes for dozens of thousands of users. The client-side SSSD installed on hosts then enforces the policies, using the PAM (pluggable authentication modules) and other native mechanisms. Often the authenticated users are coming from Active Directory realms and the IdM solution bridges the two worlds, giving the enterprises the freedom to deploy individual parts of their infrastructure using technology best suited for the task.

You have also been a contributor to CPAN. Perl has attracted many programmers with its low entry barrier and has been rightfully called the "duct tape of the Internet." Much has been said about Perl being no longer relevant and a dying language. As a long-time advocate, what are your thoughts on the future of Perl?

With cloud services, as well as with containerization, it is possible and expected that solutions will be created as combinations of various components that are able to process and exchange data using some open protocols or formats. While I don't expect to again see Perl used wherever you look like it was back in the CGI days, components written in Perl 5 (or 6?) can live and provide value for decades to come.

There are new projects started that use that language from time to time, and it's nice to see the old friendly code from time to time in people's git repos. And maybe the next huge social network is being developed somewhere in Perl right now.

Can you tell us a bit about your role at Red Hat? How much of your time do you spend on other open source project contributions as part of your official work?

At Red Hat, I'm responsible for integration of identity management technologies to our products. This allows our customers to have users from external identity management systems like IdM or Active Directory, or users from external organizations via federation using SAML or other protocols, to use those products with single sign-on, central access control, or similar expected possibilities. Another part is then security of complex systems where we try to avoid passwords being used for various systems and database accounts and search for ways of using more maintainable mechanisms—GSS-API and Kerberos or SSL certificates.

Since Red Hat's philosophy is "upstream first" and our products are open source, we obviously try to enable those features in upstream projects first as a rule. I might not have huge number of contributions in other open source projects because I lately focus on evangelizing and enabling and helping others to do those contributions, rather than pushing pull requests myself. But I have git-clones and svn-checkouts of over 80 projects on my disk and I work with those on daily basis.

This article is part of the LinuxCon Europe Series for LinuxCon in Dublin. LinuxCon Europe is where where developers, sys admins, architects and all levels of technical talent gather together under one roof for education, collaboration and problem-solving to further the Linux platform. LinuxCon Europe will be held October 5-7, 2015, in Dublin, Ireland.