Container-based application deployment is at its peak, as is the popularity of orchestration platforms like Kubernetes that form the underlying infrastructure for containerized applications. Because of its ability to orchestrate and automate application deployment, scaling, and management, Kubernetes has become the de-facto deployment and orchestration tool for cloud-native applications.
We cannot talk about securing container-based applications without talking about DevSecOps.
This methodology has risen to take advantage of the agility between operations and development teams to create end-to-end security mindfulness. It is an approach that aims to integrate security throughout the application lifecycle to distribute responsibility for security between DevOps and security teams. Traditional security methods don’t quite cut it for cloud-native technologies as they happen outside of development processes and primarily take into account the runtime state of resources. That’s why automated, built-in security must become a priority within containerized hybrid cloud environments.
Building a DevSecOps strategy requires not only the right tooling but also the right culture. In this post, we’ll introduce you to several principles to keep in mind when developing a Kubernetes infrastructure strategy or improving an existing one.
When we talk about Kubernetes as a container orchestration platform, we are referring to the loosely coupled set of building blocks that provide mechanisms to deploy, maintain and scale container applications. Generally speaking, Kubernetes is composed of a set of clusters made up of nodes. There are one or more pods within each node, and each pod consists of one or more containers. The containers are used to host containerized application images.
When we talk about Kubernetes security, we are talking about system-level security mindfulness, combining the security of the application code with the security of the image composition and dependencies, and finally, the configuration of the surrounding Kubernetes infrastructure from the Kubernetes manifests for the deployment to the core components of the cluster itself. This system truly spans development, security and ops.
The goal of Kubernetes-based DevSecOps strategies should be to align those teams to implement consistent guardrails and automate them across the Kubernetes development lifecycle.
Infrastructure as code (IaC) is key to embracing DevSecOps, especially when Kubernetes is involved. Functionally, IaC makes it easier to systematically operate cloud and Kubernetes infrastructure through machine-readable, version controllable templates. In that way, it allows you to manage your cloud infrastructure in the same way that you manage your apps, services and other code and eliminates the need for manual setup as well as the creation of one-time scripts that you would otherwise need to perform infrastructure changes.
From a security standpoint, IaC templates such as Kubernetes manifests (or more modular components such as Helm charts and Kustomize files) allow for early and automated detection of security misconfigurations. Being able to enforce security best practices such as Kubernetes CIS benchmarks as early as possible is crucial and is enabled in large part by IaC.
An important principle for Kubernetes, especially when leveraging IaC, is to understand and strive for immutability. In the realm of infrastructure provisioning, immutability means that system components from container images that have been deployed previously can only be modified at the source and not at runtime.
Functionally, this allows for faster iterations and more frequent updates during which these components are ripped down, updated, tested, verified and then re-deployed. This approach is also required to incorporate DevSecOps fully and to persist security best practices baked into build-time all the way to runtime. Kubernetes environments can be used to impose security regulations such as limiting the system-level actions that an application is allowed to execute, requiring CPU and memory limits, and blocking the launch of containers.
CI/CD pipelines are the heartbeat of agile product organizations, allowing for the automated integration and delivery of software from code development to production deployment.
Continuous integration (CI) is the process of automating building and packaging software. Modern CI tools spin up ephemeral instances to create build artifacts and then spin them down once it’s complete. Those ephemeral environments allow for functional testing as well as security scanning—from checking Kubernetes manifests for misconfigurations to identifying known vulnerabilities.
Continuous delivery (CD) is also required to safely and quickly roll out changes to your running Kubernetes workloads by standing up test infrastructure and, in some instances, creating parallel deployment instances for easier switching in case of downtime.
When leveraging IaC and Kubernetes, CI/CD allows for not only greater efficiency and productivity but also a higher level of security when it comes to deploying containerized applications.
Technology is core to implementing a Kubernetes-based DevSecOps strategy, but without the right people, processes, culture, and even KPIs, it can actually create friction and bottlenecks that it’s trying to avoid. Aligning development, security and operations teams, however, is not an easy feat, as these teams’ goals are often at odds with one another. Engineers want to work on high-impact projects. Security wants to avoid incidents at all costs, which often slows down other teams. Operations exist to deploy features and improvements as fast as possible.
Breaking those silos and fostering collaboration in the name of shared security responsibility is key to success. Here are some considerations to consider to build a DevSecOps culture:
Since DevSecOps demands breaking down silos between teams, people are the foundation. Security training and fostering security champions has been touted as the go-to solution for making security matter, but you can’t stop there. DevSecOps is a two-way street that requires bi-directional knowledge sharing in order to build true shared accountability for security. For cloud-native applications wherein technologies and software supply chains are constantly growing and changing, this is especially vital.
Whether you already have the right building blocks or are looking to add to your existing product and IT teams, these are some of the skills you need on your DevSecOps team:
Building your team based on formal titles isn’t necessary for building the right culture; looking for individuals with these qualities will ensure that security becomes a mindset rather than a barrier.
The DevSecOps paradigm necessitates new processes or perhaps improvements to existing ones that prioritize security at each step.
Setting the right processes in place ensures that everyone is on the same page and sets the foundation for security consistency and cohesiveness.
One way to integrate DevSecOps into teams’ day-to-day is to hold each accountable via shared KPIs. Metrics should take into consideration not only how secure applications are but also how quickly deployments occur and how reliable applications are. Here are some sample KPIs that touch all development, operations and security teams:
Because Kubernetes is such a dynamic and complex system, it’s even more crucial to implement a solid set of KPIs to help you assess your organization’s success internally and externally. DevSecOps is getting more popular as a means to avoid costly (both in resources and reputation) breaches. Bringing the right technologies, people and processes together to establish baselines and measure success over time are all necessary for any mature Kubernetes-based DevSecOps strategy.
Interested in taking a deeper dive into DevSecOps for Kubernetes environments? Download our DevSecGuide to Kubernetes!
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.