eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Red Hat announced the 1.0 release of its open-source Podman project on Jan. 17, which provides a fully featured container engine.
In Podman 1.0, Red Hat has integrated multiple core security capabilities in an effort to enable organizations run containers securely. Among the security features are rootless containers and enhanced user namespace support for better container isolation.
Containers provide a way for organizations to run applications in a virtualized approach on top of an existing operating system. With the 1.0 release, Red Hat is now also positioning Podman as an alternative to the Docker Engine technology for application container deployment.
“We felt the sum total of its features, as well as the project’s performance, security and stability, made it reasonable to move to 1.0,” Scott McCarty, product manager of containers at Red Hat, told eWEEK. “Since Podman is set to be the default container engine for the single-node use case in Red Hat Enterprise Linux 8, we wanted to make some pledges about its supportability.”
McCarty explained that for clusters of container nodes, the CRI-O technology within the Red Hat OpenShift Container Platform will be the default. The OpenShift Container Platform is Red Hat’s distribution of the Kubernetes container orchestration platform.
Red Hat already integrated a pre-1.0 version of Podman in its commercially supported Red Hat Enterprise Linux (RHEL) 7.6 release in October 2018. McCarty said that both RHEL 7 and RHEL 8 will be updated to include Podman 1.0. RHEL 8 is currently in private beta.
CRI-O is a Kubernetes container runtime and is at the core of Red Hat’s OpenShift. CRI-O reached its 1.0 milestone in October 2017. McCarty said Podman was originally designed to be used on OpenShift Nodes to help manage containers/storage under CRI-O, but it has grown into so much more.
“First and foremost, Podman is designed to be used by humans—it’s easy to use and has a very intuitive command-line experience,” McCarty said.
A user interacts with Podman at the node level—this includes finding, running, building and sharing containers on a single node. Even in clusters of thousands of container hosts, McCarty said it’s useful to have a feature rich tool like Podman available to troubleshoot and to tinker with individual nodes.
“One main challenge to adopting Kubernetes is the learning curve on the Kubernetes YAML, which defines running containers,” McCarty said.
Kubernetes YAML provides configuration information to get containers running. To help onramp users to Red Hat OpenShift, McCarty said Podman has the “podman generate kube” command. With that feature, a Podman user can interactively create a pod on the host, which Podman can then create and export as Kubernetes-compatible YAML.
“This YAML can then be used by OpenShift to create the same pod or container inside of Kubernetes, in any cluster or even multiple times within the same cluster, stamping out many copies anywhere the application is needed,” McCarty explained. “The user doesn’t even have to know how to write Kubernetes YAML, which is a big help for people new to the container orchestration engine.”
Security
One of the key attributes of Podman is the improved security. A challenge with some container deployments is that they are deployed with root access privileges, which can lead to risk.
On Jan. 14, security vendor CyberArk reported one such privileged container risk on the Play-with-Docker community site that could have potentially enabled an attacker to gain access to the underlying host. With containers, the basic idea is that the running containers are supposed to be isolated, but if a user has root privileges, that isolation can potentially be bypassed.
Podman has the concept of rootless containers that do not require elevated privileges to run. McCarty said that to use rootless containers, the user doesn’t need to do anything special.
Another key concept with Podman is that it does not require a new system daemon to run. Dan Walsh, consulting software engineer at Red Hat, explained that if a user is going to run a single service as a container, then having to set up another service to just run the container is a big overhead.
“Forcing all of your containers to run through a single daemon forces you to have a least common denominator for default security for your containers,” Walsh told eWEEK. “By separating out the containers engines into separate tools like CRI-O, Buildah and Podman, we can give the proper level of security for each engine.”
Walsh added that Podman also enables users to run each container in a separate user namespace, providing further isolation. From a security auditing perspective, he noted that the “Podman top” command can be used to actually reveal security information about content running within the container.
Podman Usage
Red Hat is seeing a lot of usage for Podman as a replacement for the Docker Engine for running containers in services on hosts, according to McCarty.
The Fedora and openSUSE communities seem to be taking the lead on adopting Podman, McCarty said, but Red Hat also seen it packaged and used in many other distributions, including Ubuntu, Debian, Arch and Gentoo, to name a few.
“Podman essentially operates at native Linux speeds, since there is no daemon getting in the way of handling client/server requests,” he said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.