The Challenges of Running Kubernetes In the Federal Government

Last year, John Osborne from (AlphaBravo partner) Red Hat presented a lightning talk at KubeCon 2018 on the hurdles created by the 2002 FISMA laws to getting an ATO (Authority To Operate) any code structure within the Federal Government. The talk is included at the end of this post.

You may also enjoy:  What’s Driving DevSecOps Adoption Within the Federal Government?

Fast forward to today, when the Department of Defense released their “DoD Enterprise DevSecOps Reference Design” (embedded at the bottom of this post as well). In it they mandated the use of Kubernetes to avoid vendor lock-in. This is huge news for the digital transformation of Federal Government IT and speaks to the robustness of Kubernetes and the persistence and skill of the Open Source community.

Per U.S. Air Force Chief Software Officer Nicolas Chaillan on LinkedIn:

This has been signed by DoD CIO (and myself) and finally is ready for public release! A year of hard work and CNCF-compliant Kubernetes is now mandated to avoid vendor lock-in and enable environment abstraction!

This brings us back to Red Hat. In 2014, the federal government “startup” 18F started working on an initiative called OpenControl that provided a “Compliance As Code” framwork with the goal of reducing the cost and effort to getting ATO for upgraded versions of software. The Red Hat ATO Pathways project that was spawned in response becomes even more relevant than ever in being able to quickly generate the necessary documentation for the ATO process. The ability to leverage the Kubernetes platform’s ability to quickly deploy new code and updated versions of applications will rely on it.

Stay tuned as we will discuss more about the DoD document and how the many of the security concerns can be addressed and mitigated.

Further Reading

TechTalks With Tom Smith: Kubernetes and Microservices Security

Understanding Kubernetes from Real-world Use Cases