Why Kubernetes Service Ownership is the Answer to Container Security
Full-service ownership is a hot topic right now in Kubernetes, as it revolves around the need for better container security. At the center of the discussion is the question of how this fundamental shift into a service ownership model can actually deliver more robust security through deeper collaboration and visibility.
For development teams, service ownership means taking responsibility for the products and services they deliver through each step of the development life cycle. This gives greater control to teams who want to carefully manage how their software runs in production. It also frees up operations folks who need to focus on core infrastructure rather than debugging and optimizing applications. While this shift into better service ownership can have a positive impact on many areas of the organizational workflow, there’s no doubt that enhanced container security is among the most critical.
Why is Container Security so Challenging?
Developers have always been responsible for the security of their code. But the infamous “shift left” created by DevOps practices has placed more responsibility on developers to manage their application’s infrastructure and production environment, in addition to the code itself. Dev teams are now responsible for determining the operating system, installed software and deployment configuration for their applications—things that used to fall on the shoulders of sysadmins and ops teams.
Security improves when cloud-native and Kubernetes service ownership is in place to help development teams stay accountable for issues in both their application code and configuration. Full-service ownership encourages development teams to discover and mitigate security issues at earlier stages in the software development life cycle, something all organizations should be looking to codify into their policies. Proper service ownership puts the “Sec” in DevSecOps, bringing teams together under the gold standard of security.
Because containers and Kubernetes configurations come with new blind spots in security and changing attack surfaces, visibility across clusters remains challenging. Developers have to assume responsibility for many of these new security challenges, something their role has not required in the past—and something they can be reluctant to embrace. This is precisely why shifting left in the development process is so critical—it gives developers the view they need to address security issues. The main principle of DevSecOps, where teams are tightly integrated, revolves around precisely this mantra.
How do we Divide Responsibility for Running Kubernetes Securely?
Kubernetes offers a framework for running distributed systems, built with microservices and containers to run the applications resiliently. Even so, Kubernetes is not simple to implement. Different teams must own various layers of the stack.
Infrastructure and operations teams, even with service ownership in place, essentially own the platform layer. They need to ensure that the Kubernetes control plane—as well as any core add-ons for things like ingress, DNS and certificate management—are healthy, scalable and secure. They will need to spend time investigating their cluster-level configuration as well as the configuration of add-ons, which often require sensitive permissions on the host nodes and extensive access to the Kubernetes API.
Development teams, on the other hand, need to concentrate on the runtime environment of their applications. This means not only ensuring that their codebase is free of security flaws (for example, by running static analysis and doing regular code reviews), but also ensuring that the operating system and any installed software is free of known CVEs. They will also need to ensure their deployment configuration (e.g. a Helm chart or set of Kubernetes manifests) adheres to the principle of least privilege.
It can be hard to keep every development team on the same page, especially as your policies and best practices evolve over time. To keep things consistent and secure, operations teams will want to leverage multi-cluster visibility dashboards as well as policy enforcement for workload configuration. This ultimately allows them to drive actionable feedback to development teams and to enforce mission-critical best practices across all development teams. For service ownership to succeed, infrastructure teams need to provide developers with strong guidance and policy for the security practices they need to own and maintain.
What is the Ultimate Goal in Kubernetes Security?
Organizations today must find meaningful ways to unify development, security and operations by simplifying Kubernetes complexity and enabling full-service ownership. To help teams overcome the inherent cultural gaps of service ownership, they need:
- Developer Enablement to help development teams take ownership of security and efficiency configurations in their applications, thereby alleviating the burden on operations folks.
- Visibility so service owners can configure container policies with effective guidelines and avoid downtime.
- Policy Enforcement to ensure service ownership is continuously integrated from CI/CD through production.
Once organizations and their teams gain comprehensive visibility into Kubernetes environments—complete with a dashboard that provides views of all clusters—they can begin to better understand misconfigurations, why they happen and how they can cause potential risk.