No company would charter a ship without ensuring it passed all the recognized safety regulations and relevant industry standards. In the same way, you wouldn’t implement cloud-native technology and run Kubernetes in production without ensuring that your clusters and their workloads comply with recognized best practices and industry standards.

What standards you need to consider are either an organization’s internal policies or industry benchmarks (such as CSI Kubernetes Benchmarks) and best practices, regulatory requirements (such as DSS PCI, the global standard for ensuring a secure environment for payment card information), or cybersecurity standards and guidance (such as NIST SP 800-190, which specifically covers containers). 

As well as protecting customer data and ensuring an organization avoids legal or regulatory penalties, this level of compliance engenders trust. Compliance enables many things, such as the ability for an organization to pin a trusted certification on their e-commerce unit or company home page. Additionally, depending on what standard is followed, the ability to brandish the right paperwork will open business opportunities, for example, with federal entities and enterprises working in the healthcare and banking sectors.

In practice, Kubernetes compliance overlaps with improving resource management, tightening security measures, and ensuring data privacy. As well as regulatory compliance, K8s compliance also blends into aspects of auditing and monitoring, continuous integration, and continuous deployment & DevOps:

Resource Management - With resource management, the goal is efficient use of resources and adherence to best practices in the deployment and management of applications. This includes optimizing resource allocation, ensuring high availability, and using resource quotas and limits.

Kubernetes Security - Meanwhile, K8's security compliance ensures that the Kubernetes environment is configured and managed to protect against unauthorized access, data breaches, and other security threats. This involves configuring role-based access control (RBAC), network policies, and security contexts and using tools such as pod security policies.

Data Privacy - The data privacy and protection aspect of K8s compliance focuses on following regulations such as GDPR (which is implemented under different acts in Europe and the UK), the 1996 HIPAA federal law and standard (for protecting sensitive patient health information) and, where relevant, CCPA (the California state consumer regulations that control the use of personal information). Each regulation dictates how sensitive personal data should be handled and protected and involves implementing appropriate data encryption, access controls, and data residency requirements.

Regulatory Compliance - We’ve already mentioned regulatory compliance in a past blog, such as PCI DSS and SOC 2 (the American Institute of Certified Public Accountants’ framework for storing and processing client data), but Kubernetes compliance also deals with the following:

Auditing and Monitoring - Many standards require the implementation of robust logging and monitoring solutions to track and enable the proper audit of activities within the Kubernetes environment. This is crucial for incident response, troubleshooting, and maintaining operational transparency, especially when the official auditor arrives with their clipboard. Vulnerability assessments and updates are also essential to maintain compliance over time.

Continuous Integration and Continuous Deployment & DevOps - compliance in CI/CD is concerned with integrating Kubernetes with CI/CD pipelines in a way that maintains code quality, security, and operational standards.

As you can see, there are a host of areas that need to be addressed for Kubernetes compliance, and the two main ways compliance is achieved are through policy and governance.

Kubernetes Compliance: Using Governance and Policy

Both policy and governance remain highly topical as many organizations continue to play ‘whack-a-mole’ handling both, as highlighted in VMWare’s State of Kubernetes 2023. The VMWare survey indicated that, as organizations expand their use of cloud services, the top security concerns become applying policy consistently across clusters and teams (42%), failing compliance (38%), and controlling access to clusters (33%).

In the context of K8s, policy refers to the set of constraints and conditions that define how Kubernetes resources can be configured. It enables admins to enforce rules and restrictions on various aspects of a cluster, such as network connectivity, security, resource limits, etc. Policies ensure that, for example, containers come from trusted registries, pods are labeled correctly, resource limits are set, and services are not exposed publicly on the internet, among other things.

Governance, on the other hand, sits at a higher level and involves implementing and maintaining clusters that comply with the defined policies. It includes the use of tools and processes to enforce policies and ensures that resources adhere to the desired configuration before they hit a Kubernetes cluster.

When handling governance and policy in Kubernetes, admins must define policies in such a way that they provide feedback and enable remediation for non-compliance. It is vital policies do not ruin the developer experience and stop or discourage developers from deploying apps to K8s altogether–and, sadly, this can and does happen if devs feel restrictions are too cumbersome and consume too much of their time.

Extending Kubernetes for Policy and Governance

Kubernetes was designed from its inception to offer many ways to extend, customize, and control Kubernetes, as evidenced by the vast number of tools and services we now have in the cloud-native and K8s ecosystem landscape. As we know, all the main components of Kubernetes, such as the API server, etcd state store, controller manager, kube-proxy, kubelet, and container runtime, are customizable and extensible.

There are also many different methods of extending Kubernetes. There are interface extensions, such as CNI (Container Network Interface), CRI (Container Runtime Interface), and CSI (Container Storage Interface), but they tend to be used by providers. For the K8s end user, the focus is generally admission controllers, which are used to extend the Kubernetes API server. Outside of using the Kubernetes API server, DaemonSets are used for installing logging and monitoring tools.

Using Admission Controllers

For the most part, admission controllers are the main way that Kubernetes validates and enforces policies as they are designed to intercept requests that travel through the Kubernetes API server after authentication and authorization and before an API object is created, as illustrated in the diagram, below.

An admission controller interacts with the constant stream of API requests that run through the server and adds, modifies, or rejects API requests.  While some controllers are built into the native Kubernetes API server, users create custom admission controllers for adding whole new custom resource types, accessible by command tools such as kubectl, and adding sidecar containers to Pods in a cluster for useful tooling and services.

One type of admission plugin that can be developed is a Dynamic Admission Webhook, which is comprised of HTTP callbacks that handle admission requests and act on them. This type of webhook takes advantage of several Kubernetes’ built-in (if activated) admission controllers: ValidatingAdmissionWebhook and MutatingAdmissionWebhook. 

Admission controllers can also be used in conjunction with customer resources. This is where new API objects are added to the Kubernetes API by creating a CustomResourceDefinition, a resource that defines another resource. Like all requests, traveling through the API server, the API objects are subject to an initial authentication and authorization and can be accessed using the Kubernetes API and commonly used command-line tools, like kubectl.

When an API request is sent through the Kubernetes API server, it will encounter either admission controllers that mutuate (that is, alter the request so it complies with policy) or validate a request. A MutatingAdmissionWebhook is used to add or modify resources when they don’t match a resource definition, whereas a ValidatingAdmissionWebhook confirms whether resources do or do not comply with policy and sends an admit or deny response back to the API server.

Once you understand how API requests flow through the Kubernetes API Server and how K8s can be extended to validate and mutate requests, you can begin to understand the different ways to achieve policy and governance in Kubernetes. What policy engine you decide to use–whether open source or a proprietary offering from a provider–will likely depend on the expertise and personal preferences of your existing team and your ability to train them on new technologies.

Contact Us

If you’d like to discuss options in more detail and your Kubernetes compliance needs—Book a free, confidential call with 360 Cloud Platforms today!

CONNECT WITH US