Guest post originally published on the Kublr blog by Oleg Chunikhin
Kubernetes governance may sound dull. But, if you’re an enterprise, it’s a critical part of what you must figure out to be production-ready at scale. When standardizing on-demand services for your dev teams – a DevOps best practice – you must ensure that groups deploying Kubernetes clusters follow certain rules, a process that is typically automated via policy management.
However, even if you only have a few clusters, all managed by the same person, you must keep them synchronized. With no automation, that can translate into quite a bit of work. Centralized policy management and enforcement will ease that process.
Unfortunately, governance is still a pretty patchy area. Different governance rules are implemented through different frameworks. And because it is so scattered, different management and governance extensions may overlap with other security frameworks you already have in place.
With no single comprehensive tool that addresses all your governance needs, you’ll need to mix and match until all critical areas are covered. Your goal is to minimize the number of governance frameworks needed while maximizing the coverage so it’s easier to manage for your ops team.
Governance 101
Governance refers to the ability of Ops teams to verify and enforce certain rules across departments, groups, or the entire organization. In the Kubernetes context, that means enforcing rules across Kubernetes clusters as well as applications running in those clusters.
There are two governance dimensions. First, policy scope, meaning where a specific rule should be applied, enforced, or verified. Secondly, policy targets, relating to what should be enforced and verified.
Scope may be specified in terms of organizational units (departments, teams, groups, users), technical units (cloud provider, datacenter, region, group of clusters, namespaces, label selectors, etc.) or both. Scope definition capabilities may also range from static lists to dynamic rules.
Let’s explore the second dimension in more detail.
Enforceable Governance Targets
In terms of security policies, there are multiple areas Ops may need to control. These range from security settings that ensure only those users who should have access to a cluster or app do, to providing access to certain departments, to specifying OS capabilities that applications are allowed to use. For example, for each cluster created by the data science department, users will be granted access permission to a specific default namespace.
Image management is another governance area. Organizations can specify which container images to use in which clusters or what conditions they must fulfill to be cleared for production usage. For instance, all images must be scanned and have no vulnerabilities level above “warning.”
Networking policy management allows organizations to define which pods or containers can talk to each other, i.e. pod security constraints defined through governance. In some cases, security frameworks will solve these governance requirements. You may have a common governance framework covering security as well as other areas, including cluster topology and general cluster configuration constraints.
Configuration constraints and policies is another governance category. It allows you to define resource configurability rights, as well as resource access and limits. For instance, business unit A may be permitted to create clusters in Azure and AWS in these specific accounts and use resources up to a certain limit, but they do not have the ability to alter configuration specs. Here we are dealing with Kubernetes and the Kubernetes management tool configuration structure.
There are also a number of governance rules related to applications deployed in these clusters. Some of the security rules discussed above apply to apps, including networking policies, and define which pods can talk to each other (known as application-level constraints). You can also constrain resource usage, requests, and limits for all applications.
There are clearly numerous different policies that can be automated to minimize the risk of mismanagement and exploitable vulnerabilities. To automate a governance framework, you’ll need some form of registry for all your assets. In the case of Kubernetes cluster governance, you’ll need a place where all your clusters are registered. This emphasizes once more the importance of centralized management for all your Kubernetes clusters.
Implementing a Governance Framework
When implementing your governance framework, you have three options:
Combine multiple specialized governance frameworks into a comprehensive solution. Tools like NeuVector can be leveraged for security policies. Then, specialized cloud cost management tools can be used for cloud resource management and cost control, such as Cloudability, and so on.
That approach doesn’t come without its challenges as you may have a set of tools that don’t necessarily communicate and integrate with each other. Different policies are defined in different places with different interfaces. Some frameworks may not be aware of your container management platform or containers in general. For instance, while using a cloud focused cost management framework you can set limits in certain clouds/cloud accounts, but you won’t have visibility into which cluster or app caused an unexpected expense.
Another approach is implementing it on top of your centralized Kubernetes platform. This is especially interesting if it has an API through which you can access different clusters, parameters, and characteristics. This is basically a build-your-own approach enabling you to integrate other cloud native platforms into an existing governance framework.
The third approach is to select a Kubernetes platform that includes a comprehensive governance framework or at least has it in its roadmap.