Rancher Federal this week unveiled a Kubernetes-based open source project targeted at allowing container deployments to meet the increased security requirements of government organizations. The move continues what has been a growing push by different branches of the government to use cloud native architectures to modernize their IT infrastructure.

Rancher Federal was formed by some of the early founders of Rancher Labs. It's focused on developing open source products for the U.S. government.

The latest product is based on the RKE Government project. The project, which goes by the RKE2 shorthand, combines Rancher Labs' Kubernetes Engine distribution (RKE) with its edge-specific k3s platform and designed as a Kubernetes distribution that meets the Federal Information Processing Standards (FIPS).

RKE is a well-established Kubernetes distribution that helped Rancher Labs wrangle a top placing in Forrester Research's latest ranking of multi-cloud container development platforms. That platform also prodded SUSE to acquire Rancher Labs. And its k3 platform has been adopted into the Cloud Native Computing Foundation (CNCF) as a "sandbox" project.

RKE Government further ups its security stance by using Security-Enhanced Linux (SELinux) via the Containerd container runtime and Rancher Labs’ free and open source Kubernetes encryption module. Brandon Gulla, VP of engineering at Rancher Federal, explained in an email that the module is currently undergoing evaluation with the NIST testing laboratories and that it anticipates it will soon gaining FIPS-140-2 validation. "It was paramount to get the product into the hands of our customers as soon as possible," Gulla noted. "Once we receive the certification from NIST, we will move forward with marking the distribution as stable and join the list of modules listed with NIST."

The RKE Government platform also uses the Docker runtime for deploying and managing the control plane and the container runtime for Kubernetes, but it launches the control plane as static pods that are managed by the kubelet.

The enhancements tackle some of the security challenges that continue to plague the Kubernetes market. Container security platform provider StackRox recently noted that 90% of enterprises it surveyed had experienced a container security incident, with nearly half of respondents stating they have delayed rolling out container-based applications into production due to security concerns.

This security issue is even more pressing for government entities, which are using containers and Kubernetes to gain technology advantages.

Speaking during this week’s Cloud Native Virtual Summit featuring Kubernetes event, Nicolas Chaillan, the chief software officer for the U.S. Air Force, said that the military branch has embraced the container architecture as part of its DevSecOps migration plans. He explained that the microservices architecture allowed for much finer-grained control and management of Department of Defense’s (DoD’s) development stack.

For its security posture, Chaillan said that the DoD relies on several different layers. This includes zero-trust security down to the container or function level using Istio and Envoy for containers and Knative for functions.

“You realize pretty quickly that you don't want to be running the these as [virtual machines],” Chaillan said. “If you're running dev, test, staging, and prod – and for us that's across multiple classification levels – you end up having 12 of these environments per program, and we have a lot of different critical programs across the DoD right now.”

Chaillan said that those plans right now include about 60 programs moving to DevSecOps, including “the big jets, the bombers, nuclear systems, space systems, business systems, so for us we want to make sure that there's no drift between environments.”

“And so by containerizing everything and orchestrating everything on Kubernetes, you can have the same cyber visibility,” Chaillan added.

The DoD efforts rely heavily on the CNCF ecosystem of vendors and projects. Chaillan explained that this is being done so that it can avoid any vendor lock-in issues and so that it knows it’s using projects that have broad support.

UPDATE: This story has been updated to further clarify the differences between Rancher Federal and Rancher Labs. It has also been updated to clarify that the open source Kubernetes encryption module was still undergoing evaluation with the NIST testing laboratories.