You are managing Kubernetes users: do you know what’s happening in your clusters? Do you know if your clusters are secure, cost-efficient, or unreliable? This is a problem for many engineering leaders, yet implementing Kubernetes policies and then enforcing them can be problematic especially without stakeholder approval.
Kubernetes can be a meeting point between DevOps, development, security and compliance teams. This meeting point offers an opportunity for alignment on guardrails, Kubernetes governance and enforcement. Getting buy-in from stakeholders and maintaining it as downstream users experience your implemented policies is crucial. Without it, DevSecOps will struggle, teams will lose confidence and you’ll miss out on the “we are in this together” mentality.
Policy helps three types of ownership models:
Ops owns all things containers and Kubernetes: While this enables developers to focus 100% of their time on app code, a side effect is Ops becoming overloaded with the responsibility of tuning and maintaining configurations for hundreds or thousands of workloads they have little context over. Managing this complexity can be solved with prioritization of existing issues, as well as applying Kubernetes guardrails around a set of good best practices.
Shared ownership between Ops and Dev (most common): Finding the right balance between operational ownership and time to market is key. Most companies may push some of the Kubernetes and container configuration to developers - just the bits that require app level context - while Ops manages everything else, including platform level functionality like DNS, certificate management, ingress/egress, etc. Human error can introduce avoidable mistakes. A policy that applies sensible defaults can help.
Complete service ownership by Dev: In this state, teams may face challenges with devs not knowing enough about Kubernetes best practices, and accidentally introducing misconfigurations that create compliance risk, or consume too much compute resources - leading to increased costs or capacity issues. While this may be the ideal end state for many organizations, the reality is few companies are here.
Stakeholders include platform engineers, DevOps, developers, engineering, security and compliance leaders. We typically run into these stakeholders:
Operations
Security and Compliance
Software Development
When policy enforcement is implemented, each stakeholder benefits:
Operations: Kubernetes Operators are incentivized to automate as much as possible to reduce the risk of downtime, complexity, and 3am pages. For example, a deployment policy that requires all apps to have proper labels is a common way to enforce consistency from team to team.
Security & Compliance: Security teams are on the hook for ensuring containers are running without critical vulnerabilities, making sure Kubernetes configurations have the right security context, and maintaining enterprise-wide visibility into infrastructure risk. With policies, especially those that come out of the box, security teams can reduce risk and stay compliant at a much reduced cost. Further, it helps security teams advocating to the platform engineering team to apply and enforce security policies at the cluster level. It helps to ensure security is front of mind and in compliance.
Software Development: Developers are paid to write code and ship roadmap features. They do not have the time to learn all the intricacies of Kubernetes. The challenge here is that when implementing policies, developers may have to refine certain steps they take to get their job done. For example, not granting privileged access. Policies can be pushed earlier into the CI/CD process so developers get feedback on the bits of configuration related to their specific app. Configuration requirements will become second nature as they experience the policies.
When implementing any guardrails, your downstream users will be impacted as you start to check deployments across a set of best practices. By getting stakeholder buy-in, each team leader will be able to communicate why these checks are happening. It will help to overcome any objection downstream.
We’ve helped many companies build and manage their Kubernetes infrastructure. The challenge for many is onboarding multiple application teams to Kubernetes and interfacing with folks from DevOps, development, and security. One problem area is how to audit clusters against the requirements of each team.
We noticed that without a way to validate clusters, teams would see configuration drift, Kubernetes sprawl and risk (due to the speed of engineering). We needed a way to implement guardrails to eliminate human error and make it easier for platform engineering, development, and security teams to work together as apps move to cloud-native infrastructure.
To address this, we built Fairwinds Insights. It audits Kubernetes clusters against a variety of best practice areas, including security, workload efficiency, and cluster reliability and customized policies. It helps enforce Kubernetes policies across workloads in one centralized dashboard.
You can use Fairwinds Insights for free, forever. Get it here.
With stakeholders across an organization interested in security, compliance and cost, Fairwinds Insights provides the view needed for all team leads. Security is enforced, compliance is ensured and costs are minimized.
