Confused by compliance in Kubernetes? We’re not surprised. Although compliance can be reasonably straightforward to navigate, many industry standards, such as PCI DSS, the Payment Card Industry Data Security Standard and HIPPA, the Health Insurance Portability and Accountability Act of 1996, barely mention containers, Kubernetes or the cloud, and when they do the details can be sparse, vague and not easy to translate into practical application.

This is because the industry standards are intended as an overview of the best practices and threats rather than detailed how-to guides (even if they are hundreds of pages). Instead, the standards provide use cases to assist organizations in understanding the technologies and practices to help achieve compliance.

In Part One:

The Two Main Goals of Kubernetes Compliance
Challenges of Kubernetes Compliance
Kubernetes Compliance: Security Standards
NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations
NIST SP 800-190 Compliance: Securing Containers And Environments
NIST SP 800-210 Compliance: Controls for Cloud
CIS Kubernetes Benchmark
NSA and CSA Kubernetes Hardening Guidance
MITRE ATT&CK® Matrix for Containers

The Two Main Goals of Kubernetes Compliance

Many factors you need to consider for compliance overlap with security but with key differences. K8s compliance has two main goals:

1. Comply, we don’t care how–just comply - Compliance must be achieved with the industry standards or regulations by whatever method an internal team decides to employ, so the organization does not expose itself to fines, put customer data at risk, or lose potential contract or partnership opportunities.
   
   
2. My checklist doesn’t care that K8s is ephemeral - Achieve compliance with an organization’s internal policy and governance by ensuring that the unique characteristics of Kubernetes, such as the visibility issues, are addressed correctly to allow for auditing and assessments.

You will find that following the high-level compliance recommendations of your specific industry standard will naturally lead to a deep dive into security recommendations and frameworks, which will provide greater practical explanations. This guidance is found through familiar security bodies and recognized experts, such as NIST, CIS, CISA, and MITRE.

We will touch on some K8s security standards and frameworks in this blog (particularly NIST), but we will reserve a dedicated discussion for a later series of blogs (covering such things as standards and benchmarks, common attack vectors, and how to secure your cloud, clusters, and code). 

Read on for a high-level explanation of the security guidance around Kubernetes you’ll need to apply for K8s compliance. In Part 2, we will go on to look at an industry standard as an example. We have chosen PCI DSS since many organizations encounter it. In Part 3, we provide a high-level overview of open-source policy and governance tools used to achieve the two main compliance goals mentioned above.

The Challenges of Kubernetes Compliance

Understandably, managing compliance in a platform as complex and dynamic as Kubernetes demands a deep understanding of the Kubernetes architecture, policies, and security controls.

Kubernetes is the most popular platform for handling container orchestration, but K8s compliance has many challenges. Kubernetes’ sheer complexity makes it difficult to effectively identify and address the compliance gaps. At its simplest, it doesn’t take long before you have hundreds or thousands of resources to manage in a distributed application.

Ephemeral by Design

The dynamic and ephemeral nature of Kubernetes clusters can make maintaining a consistent state of compliance challenging. Pods and containers are created and destroyed frequently, making it difficult to ensure compliance across the entire stack if those activities aren’t monitored and logged correctly.

Multi-Tenancy Complications

Additionally, there are specific compliance challenges when using Kubernetes with multi-tenancy architecture. This situation creates a situation where multiple apps and teams will share the same cluster, but each team may have different compliance requirements and configurations. Organizations must implement proper isolation, access controls, and policies to maintain compliance across tenants.

No Default Compliance Control

Many new adopters or less experienced admins don’t appreciate that native K8s does not supply controllers that enable policy and governance. Kubernetes is highly extensible, and the expectation has always been that engineers will configure K8s to their requirements and draw on the many flavors of managed Kubernetes services, PaaS offerings, and open-source tools within the ecosystem to implement good compliance.

Ecosystem Tool Sprawl

Additionally, the complexity of the Kubernetes ecosystem and the vast number of open-source projects and tools available can make integration and compatibility challenging. Ensuring seamless interoperability and avoiding conflicts between different components can be complex.

Kubernetes Compliance: Security Standards

The evolving nature of compliance standards adds another layer of complexity, requiring organizations to stay updated with the latest requirements and ensure their Kubernetes deployments align with these standards.

As mentioned, the practicalities of achieving compliance are often missing from the standards. A good starting point is recommendations from security bodies, such as the National Institute of Standards and Technology (NIST), and its guidelines for securing all types of IT systems.

NIST SP 800-53 covers security and privacy controls more broadly, while 800-190 covers more specifics around containers, and 800-210 considers cloud environments and access controls. Unfortunately, only 800-190 mentions Kubernetes specifically, but very briefly, about its native management of secrets.

NIST SP 800-53 Compliance: A Baseline For Key K8s Controls

Whether or not your organization is a third-party vendor or business working with federal entities or systems, NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations (PDF), will provide a solid baseline system and controls for a security department and compliance. The latest update, revision 5, was published in 2020 and has added valuable recommendations for areas such as supply chain risk management and focuses strongly on the outcomes of controls.

The NIST SP 800-53 framework is broad in scope and provides three baselines (low, medium, and high impact) and 20 control groups (including audit and accountability, configuration management, training, and more). As there is a clear apps and images security responsibility with K8s and containers, the most relevant controls (found in Chapter 3) are:

1. Access control - e.g., recommends least privilege, RBAC enforcement, automatic audits on account creations and changes, enforcement of inactivity logouts, separation of duties, limits on unsuccessful logins and concurrent sessions, etc. 
    
2. Assessment and authorization and monitoring - e.g., recommends developing a plan of action and milestones for planned remediation actions and authorization processes, including multiple authoring, continuous monitoring, pen testing, security considerations for information exchange, and internal system connections.
    
3. Audit and accountability - e.g., guidelines for event logging, timestamps, audit record, review, analysis, reporting and audit retention best practice, non-repudiation measures, and monitoring for information disclosure. 
    
4. Configuration management - e.g., discusses using the least functionality principle, baseline configurations, settings and management plan, control for config changes, impact analyses, and recommended restrictions to access for changes. 
    
5. Incident response - e.g., training on handling incidents and testing responses, best practices for monitoring, tracking, documenting, monitoring, and reporting incidents, developing response plans, and responding to information spillage.
   
   
6. System and communications protection - e.g., controls for separating system and user functionality, isolating security functions, preventing information transfer via shared system resources, DoS, boundary and resource availability protection, and cryptographic key management.
   
   
7. System and information integrity - e.g., flaw remediation method, malicious code protection, system monitoring, receiving security alerts, advisories and directives, good error messages and handling, predictable failure prevention, validating information input filtering.
   
   
8. System and service acquisition - e.g., allocation of resources, dev configuration, testing, evaluation and management, security and privacy engineering principles and considerations in the system development life cycle and external services, acquisition best practices, proper development of system documentation.

NIST SP 800-190 Compliance: Securing Containers And Environments

NIST SP 800-190, Application Container Security Guide, published in 2017, is a good starting point for understanding and securing core components in container technology that many industry standards will request in their compliance recommendations. NIST SP 800-190 provides an overview of container technology (Section 2) and general guidance on security risks (Section 3). It also standardizes the management of risk by detailing the six core components that pose significant risks (which it calls “security countermeasure levels”): image, registry, orchestrator, container, host OS, and hardware.

The five tiers of the container technology architecture. In Section 3, NIST SP 800-190 explains the major risks in six core components (listed below) and, in Section 6, supplies high-level considerations for securing the container life cycle. Image by NIST Guidance on Application Container Security.

Here is a selection of the major risks that are defined in the NIST SP 800-190 guidance:

Image Risks - including image vulnerabilities because of the static nature of image components, image config defects, e.g., incorrect/escalated privileges, embedded malware, use of clear text for secrets, and untrusted images from external sources.

Registry Risks - including use of insecure channels, stale image use, potential use of out-of-date versions, and insufficient authentication and authorization restrictions.

Orchestrator Risk - mentions unbounded admin access where access isn’t scoped to specific needs, unauthorized access, particularly by ‘orphaned’ accounts, and poor separation of inter-container network traffic. It also covers workload sensitivity, for example, ensuring that containers are grouped by relative sensitivity and defining which hosts run containers of the same sensitivity. 

Container Risk - discusses vulnerabilities in runtime software that could enable container escape. Other risks include unbounded network access from containers and insecure runtime configs, e.g., running a container in privileged mode and allowing access to the host or allowing a container to change paths such as /boot or /etc on the host. 

Host OS Risk - covers large attack surface risks and the inherent risks with a shared kernel. The section also highlights issues from component vulnerabilities such as kernel primitives, improper user access rights, such as directly logging on to hosts, and the potential for file tampering if a container has permission to mount sensitive host OS directories.

The remainder of the guide (from Section 4 onwards) deals with recommended countermeasures, example scenarios, and life cycle security considerations. Note: If you want specific and detailed guidance for Linux containers, that is in NISTIR 8176 - PDF. 

As the 800-190 guidance was only published two years after Kubernetes was released, it doesn’t address Kubernetes specifically (beyond a brief mention), but it does provide solid best practices for standard container security.

NIST SP 800-210 Compliance: Controls for Cloud

As the name indicates, NIST SP 800-210, General Access Control Guidance for Cloud Systems - PDF, is concerned with controls for cloud environments. The guidelines deal with IaaS (Network, hypervisors, VMs, and APIs), PaaS (memory data and APIs), and SaaS (covering topics such as policies, multi-tenancy, and role management). If you are using a cloud provider and want to comply with industry standards, it is worth reading and checking that your provider is following guidance.

Outside of NIST, the other security research and guidelines to review are the CIS Kubernetes Benchmark, NSA and CSA Kubernetes Hardening Guidance (August 2022, PDF), which was co-authored by Endpoint Security and the MITRE ATT&CK Matrix for Kubernetes.

CIS Kubernetes Benchmark

The Center for Internet Security (CIS) is a non-profit that supplies benchmark guidelines–based on community feedback. For Kubernetes, that means open-source K8s as well as most of the cloud-based K8s services (Amazon Elastic Kubernetes Service, Azure Kubernetes Service, Google Kubernetes Engine, and many more). 

You can manually work your way through the 228 pages of recommendations for everything from API server and scheduler to config files, etcd, pod security policies, and kubelet, or automate the process by using kube-bench, a Go-based open source application, created by Aqua Security, that will run your K8s clusters through all the CIS benchmark guidelines.

NSA and CSA Kubernetes Hardening Guidance

The NSA and CSA guidance makes recommendations for K8s Pod security, network separation and hardening, authentication and authorization, audit logging, threat detection and practices for upgrading, and application security practices.

The guidance also recommends seven mitigations as well as hardening measures, which boil down to the following:

• Scan containers and Pods for vulnerabilities or misconfigurations.
• Run containers and Pods with the least privileges possible.
• Use network separation to control the damage a compromise can cause.
• Use firewalls to limit unneeded network connectivity and encryption to protect confidentiality.
• Use strong authentication and authorization to limit user and admin access and limit the attack surface.
• Capture and monitor audit logs to alert admins to potential malicious activity.
• Periodically review all K8s settings and use vulnerability scans to ensure risks are appropriately accounted for and security patches are applied.

MITRE ATT&CK® Matrix for Containers

The Containers Matrix is free and lists the techniques used against containers and, by extension, container orchestration tools, including Kubernetes. It lists nine main technique groups from initial access, execution, persistence, privilege escalation to defense evasion, credential access, discovery, lateral movement, and the impacts of techniques. This tool is geared towards helping a security team as there’s a visual navigator for red/blue team planning and gaining a bird’s eye view of your current defensive coverage (instead of using a spreadsheet).

The MITRE ATT&CK® Containers Matrix includes a navigator for assessing an organization’s defensive coverage of the nine main technique groups used against containers. Image by MITRE ATT&CK®.

In this blog. we’ve shed light on the practical challenges and best practices in achieving compliance in Kubernetes, emphasizing the significance of ensuring that an organization aligns itself and complies with recognized security frameworks and guidance, such as the NIST SP 800-53, 800-190, and 800-210, as well as the CIS Kubernetes Benchmark and NSA and CSA Kubernetes Hardening Guidance. In Part 2, we will take a high-level look at PCI DSS and the challenges compliance throws up, particularly for the dynamic and ephemeral nature of K8s clusters.

Contact Us

Need help with K8s compliance? Take the pain out of the process and connect with us today to find out how we can reduce workloads and support and work with your teams.

CONNECT WITH US