As software takes on an increasingly essential and mission-critical role in the operations of the U.S. government and Department of Defense (DoD), application developers creating software on behalf of the government are under pressure to develop and deploy new versions, features, and capabilities to their users quickly. But, as the old saying goes, haste makes waste. Considering the sensitive data and information that is stored, shared, and analyzed by government and military applications, this accelerated speed of development and deployment simply cannot come at the cost of security.
While the movement towards microservices has helped to accelerate the development process, embracing the DevSecOps approach to application development has helped to ensure that rapid deployments don’t come at the cost of application security. And enabling both of these things is Kubernetes.
To learn more about the role that Kubernetes plays in secure application development, how it’s enabling a DevSecOps approach to development, and how Kubernetes differs – fundamentally – from container solutions, we recently sat down with Matthew Bach, a Senior Specialist Solutions Architect for the DoD at Red Hat.
During our discussion with Matthew, we asked about the unique security requirements that application developers working for the government face, and the new tools that can ensure their software meets all government security requirements – including Red Hat’s OpenShift platform as a service (PaaS) solution.
Here is what he had to say:
GovDevSecOpsHubs (GDSOH): Can you tell our readers a little bit about Kubernetes? What benefits does it deliver? How is Kubernetes different from other container solutions?
Matthew Bach: Kubernetes is an open-source project that orchestrates and manages Linux containers. The main benefits are high availability for your applications, and the ability to scale.
Placing an application in a container and running it is pretty easy, but once you start scaling out you really need Kubernetes to help manage that. Kubernetes is different from other container management projects in that it has seen vast industry adoption, largely because of how extensible the codebase is and the large community driving the innovation while keeping open standards.
GDSOH: What role does Kubernetes play in enabling the faster, more frequent deployments that are a hallmark of today’s development teams? Why is it important for today’s DevSecOps approach to development?
Matthew Bach: Kubernetes is one piece of the larger equation that enables developers to deploy more frequently by pairing with a flexible software architecture approach known as microservices. Developers can take their previous monolithic application designs and break them down into smaller and more manageable services. Rather than having to spin up an entire virtual machine and configure such a system, teams are able to create and destroy completely configured stateless machines by leveraging a container driven workflow.
We’re talking about a difference between weeks and even months in some environments to seconds required to deploy a container.
Doing this enables teams to focus on more manageable portions of their code base and replace modular pieces of it over time asynchronously, rather than releasing a single application as one unit. When large apps are broken down into smaller parts, it’s far easier to patch a given service without creating a ripple effect of refactoring the codebase.
Because of this, Kubernetes pairs well with a DevSecOps approach by allowing you to inject security checks and balances at the start of every service, rather than waiting to scan one large monolithic application after a large development cycle has taken place. One of the core tenants of DevSecOps is shifting security as far left as possible and Kubernetes makes this easier to achieve.
GDSOH: Red Hat recently announced a new version of OpenShift. What is OpenShift? What makes it different from other Kubernetes distributions?
Matthew Bach: Red Hat OpenShift is often referred to as the Red Hat distribution of Kubernetes, and that’s a fair starting point. We do, in fact, develop in the upstream Kubernetes community before bringing in that code and including it as a product at the core of OpenShift. However, the distinction to be made is that OpenShift is a PaaS and it’s so much more than just Kubernetes.
Kubernetes alone will only get you started. OpenShift is the combination of roughly 100 upstream best-in-class open source projects that are bundled together in unison with extensive compatibility testing to ensure our customers have everything they need to take Kubernetes to production.
“Government customers run critical workloads that our nation’s security depends on. With this comes very stringent security requirements and oftentimes deployment to a standard region in a public cloud is not an option; more often than not they’re completely disconnected from the public internet. This makes the deployment of any software significantly more difficult.” – Matthew Bach
Some Kubernetes vendors are essentially just taking the upstream source code, throwing a web-console GUI on top, and selling it with support. Red Hat has taken a significantly more holistic approach and we’re well known for our commitment and participation in these upstream projects. There have been plenty of nightmare security stories with Kubernetes and container vulnerabilities that were exploited in the wild.
Red Hat chooses to own this problem from the operating system up. OpenShift comes with a purpose-built less-mutable operating system managed by OpenShift to prevent issues other Kubernetes distributions are at risk of when the operating system patches are managed out of band with the container orchestrator patches.
Red Hat OpenShift comes with a logging and monitoring stack, metrics, a pipelining system, a service mesh, a developer IDE, automated day 2 operations and so much more that I can’t cover them all in the context of this conversation. We know these are the things our customers need when adopting Kubernetes, and we choose to participate and foster the development of all of their upstream community counterparts and support customers using these directly; rather than delivering a Kubernetes clone and relinquishing customers to a Github repository to file an issue.
GDSOH: In the announcement of OpenShift 4.6, Red Hat claims that the new version has, “…a number of enhancements focused on enabling our government customers to accelerate and expand their adoption of containers and DevSecOps.” What unique requirements do government development teams face? Why do they need special features in contrast to other Kubernetes users?
Matthew Bach: Government customers run critical workloads that our nation’s security depends on. With this comes very stringent security requirements and oftentimes deployment to a standard region in a public cloud is not an option; more often than not they’re completely disconnected from the public internet. This makes the deployment of any software significantly more difficult.
With the 4.6 release of Red Hat OpenShift, we’ve added additional locations in which Government customers can do a fully automated deployment, getting them up and running with a cluster that meets Government security requirements quickly.
GDSOH: What is FIPS validation? Why is this so essential for government Kubernetes users? What unique security challenges and requirements do they face that makes this essential?
Matthew Bach: FIPS stands for Federal Information Processing Standards. Essentially, it’s a standard for encryption algorithms to adhere to that can in turn be validated by the National Institute of Standards and Technology (NIST). To say something is FIPS validated means it’s been through the rigor of inspection by NIST and received a blessing that communicates to consumers that it has met the requirements for inclusion in the list of FIPS validated modules.
In government, this is essential as it’s a great starting point in a long list of things that need to be in place for an IT system to receive an authority to operate (ATO). With OpenShift, ensuring your deployment has FIPS enabled is as simple as a one-line variable change at installation time. It’s well understood within the government IT circles that Kubernetes alone isn’t a silver bullet in achieving FIPS compliance.
If you’re looking for more information on OpenShift – or looking to get started with the solution – click HERE and select an environment that works for you.
