Guest post by Robert Brennan, Fairwinds
In the world of software development and Kubernetes, service ownership means development teams take responsibility for supporting the products they deliver, at every stage of the service life cycle. This model gives development teams greater control over how their software runs in production, and frees up operations teams to focus on core infrastructure instead of debugging and optimizing applications.
One of the hottest conversations right now in Kubernetes revolves around the need for more comprehensive container security—and how this fundamental change can be facilitated through better overall service ownership.
The Challenges of Container Security
Cloud native and Kubernetes service ownership helps development teams improve security by holding them accountable for security issues in both their application code and its configuration. Full-service ownership of Kubernetes clusters is what enables the shift left to address security issues earlier in the development process, something all teams should be looking to codify into regular practice. In other words, proper service ownership is what puts the “Sec” in DevSecOps, now considered the gold standard for software security.
Many organizations face challenges when trying to adopt Kubernetes at scale, mostly because they lack the tools, processes and experience to properly launch secure container environments. This can be a real struggle. Because Kubernetes and containers present a new approach for deploying applications, operations and security teams question whether the applications and data will be secure when they adopt microservices, containers and Kubernetes to develop and deploy applications.
Why? Because many traditional security tools and processes no longer apply. Containers create new security blind spots, along with new attack surfaces, making visibility across containers and clusters even more challenging. As such, developers must assume responsibility for some of the new security challenges, a role they’re unaccustomed to and reluctant to embrace. This is why organizations must learn to shift security “left” in the development process, giving them the view they need to address security problems. This approach sits at the heart of DevSecOps, where teams are tightly integrated, and helps businesses avoid five critical mistakes associated with Kubernetes ownership.
The Service Ownership Solution
Kubernetes provides a framework to run distributed systems, built with microservices and containers to run the applications resiliently. That said, Kubernetes is complex, which means different teams need to own different layers of the stack.
Take operations for example. Even with full service ownership in place, operations teams essentially own the Platform layer, otherwise known as the core infrastructure ensuring Kubernetes is available and ready to scale. Operations teams seeking success must have multi-cluster visibility and policy enforcement, which essentially allows them to drive actionable feedback to the development teams.
Product and development teams also play a critical role in establishing a robust security posture in Kubernetes. For their success, service ownership has to be well established, so developers know exactly what security practices they’re responsible for.
Kubernetes service ownership may look a little different for infrastructure teams and application developers: infrastructure teams should focus mostly on the security of the core infrastructure, while crafting policies and compliance dashboards for application configuration; developers should focus on adhering to those policies as they construct their deployment configurations.
As a result, infrastructure and development teams require self-service tooling that allows them to communicate and collaborate. These observability tools are what enable them to diagnose and triage security, efficiency, and reliability issues.
What do I need to know about Kubernetes service ownership?
It is important to understand where the configuration of your Kubernetes environment isn’t meeting industry standards and best practices. Take deployments for example. They may appear to work well without something as simple as liveness and readiness probes in place or without resource requests and limits set. But the truth is, ignoring these configuration settings is a recipe for disaster down the line.
With regards to security, uncovering when a Kubernetes deployment is over-permissioned is challenging to say the least. In fact, many teams do over-permission containers and clusters, mostly because the simplest easy way to get something to work is to provide root access—which means full admin privileges. In this way, configuration can introduce significant security risk into the Kubernetes environment.
On the other hand, when appropriate governance is in place, Kubernetes service ownership can help organizations ship code faster and with less risk, especially businesses with multiple teams and clusters. For a company running, say, 40 clusters, well-implemented service ownership can mean the difference between knowing who is responsible for patching a vulnerability and a security failure. This clear indication of ownership also ensures the right team or developer will check the cluster configuration and apply a patch when needed. Service ownership can help every development team find success in getting applications on Kubernetes successfully.
Fairwinds Insights is a platform for DevOps teams to enable service ownership. Developers can ship applications faster with a safety net and achieve production-readiness.