![\"Podman\"](\"https:\/\/www.eweek.com\/imagesvr_ez\/b2bezp\/2019\/01\/podman-1088x725.png?alias=article_hero\")
<\/div>\nRed Hat announced the 1.0 release of its open-source\u00a0Podman project on Jan. 17, which provides a fully featured container engine.<\/p>\n
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.<\/p>\n
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.<\/p>\n
“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,”\u00a0Scott McCarty, product manager of containers at Red Hat, told\u00a0eWEEK<\/em>. “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.”<\/p>\n 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.<\/p>\n Red Hat already integrated a pre-1.0 version of Podman in its commercially supported Red Hat Enterprise Linux (RHEL)\u00a07.6 release<\/a>\u00a0in 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.<\/p>\n <\/a>OpenShift<\/strong><\/p>\n CRI-O is a Kubernetes container runtime and is at the core of Red Hat’s OpenShift. CRI-O reached its\u00a01.0 milestone<\/a>\u00a0in 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.<\/p>\n “First and foremost, Podman is designed to be used by humans\u2014it’s easy to use and has a very intuitive command-line experience,” McCarty said.<\/p>\n A user interacts with Podman at the node level\u2014this 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.<\/p>\n “One main challenge to adopting Kubernetes is the learning curve on the Kubernetes YAML, which defines running containers,” McCarty said.<\/p>\n Kubernetes\u00a0YAML<\/a>\u00a0provides configuration information to get containers running.\u00a0To help onramp users to Red Hat OpenShift, McCarty said Podman has the \u201cpodman generate kube\u201d 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.<\/p>\n “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\u2019t even have to know how to write Kubernetes YAML, which is a big help for people new to the container orchestration engine.”<\/p>\n Security<\/strong><\/p>\n 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.<\/p>\n On Jan. 14, security vendor CyberArk\u00a0reported<\/a>\u00a0one 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\u00a0can potentially be bypassed.<\/p>\n 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\u2019t need to do anything special.<\/p>\n 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.<\/p>\n “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\u00a0eWEEK<\/em>. “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.”<\/p>\n Walsh added that Podman also enables users to\u00a0run each container in a separate user namespace, providing further isolation. From a security auditing perspective, he noted that the \u201cPodman top\u201d command can be used to actually reveal security information about content running within the container.<\/p>\n Podman Usage<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n “Podman essentially operates at native Linux speeds, since there is no daemon getting in the way of handling client\/server requests,” he said.<\/p>\n<\/div>\n Related Stories:<\/p>\n\n