KarChunTOverview of Kubernetes Compliance and Security Frameworks
Explore the various compliance and security frameworks relevant to Kubernetes.
Compliance and Security Frameworks
Understand what is compliance frameworks?
Compliance Frameworks are structured guidelines and best practices that organizations follow to ensure they meet regulatory requirements and industry standards. Meaning that, it defines what to do or what needs to be done to meet legal, regulatory, and industry standards.
There are some common compliance frameworks;
- General Data Protection Regulation (GDPR)
- Health Insurance Portability and Accountability Act (HIPAA)
- Payment Card Industry Data Security Standard (PCI DSS)
- National Institute of Standards and Technology (NIST)
- Center for Internet Security (CIS) Benchmarks
- System and Organization Controls (SOC 2)
| Frameworks | Purpose | When to Apply | Key Focus Areas & How to Use | Tools |
|---|---|---|---|---|
| GDPR | Protect personal data and privacy of EU citizens. | When handling data of EU citizens or operating in the EU. | Data protection, privacy, breach notification. Implement data encryption, access controls, and ensure compliance with data subject rights. | Kubernetes Secrets, Open Policy Agent (OPA), HashiCorp Vault. |
| HIPAA | Protect sensitive healthcare information. | When handling healthcare data in the U.S. | Data encryption, access controls, audit logging. Configure Kubernetes to secure PHI (Protected Health Information). | Kubernetes RBAC, Falco, Aqua Security. |
| PCI DSS | Secure payment card data. | When processing or storing payment card information. | Network segmentation, secure storage of sensitive data. Segment networks, secure Kubernetes secrets, and monitor access logs. | Sysdig Secure, Trivy, Kubernetes Network Policies. |
| NIST | Provide security guidelines for IT systems, including containers. | When implementing federal or enterprise-level security standards. | Container security, runtime environments, orchestration platforms. Follow NIST SP 800-190 for container security best practices. | Anchore, Prisma Cloud, Kubernetes Benchmarks. |
| CIS | Provide best practices for securing Kubernetes clusters. | When securing Kubernetes configurations and runtime environments. | Configuration best practices, runtime security. Apply CIS Benchmarks for Kubernetes to harden cluster security. | kube-bench, kube-hunter, CIS-CAT. |
| SOC 2 | Ensure trust principles like security, availability, and confidentiality. | When providing services that require assurance of data security and privacy. | Security, availability, confidentiality. Implement controls to meet SOC 2 trust principles and monitor compliance. | Datadog, Splunk, Kubernetes Audit Logs. |
Threat Modeling Frameworks
Understand what is threat modeling frameworks?
We know that Compliance Frameworks define what to do or what needs to be done to meet legal, regulatory, and industry standards, but it doesn't tell you how to do it. This is where Threat Modeling Frameworks come into play.
Threat Modeling Frameworks define how to do it by providing a structured approach to identifying and addressing potential security threats and suggesting mitigation strategies to secure your Kubernetes environment.
There are some popular threat modeling frameworks;
- STRIDE
- DREAD
- MITRE ATT&CK
STRIDE
What is Data Integrity?
Data integrity refers to the accuracy, consistency, and reliability of data throughout its lifecycle. It ensures that data remains unaltered during storage, transmission, and retrieval, except by authorized processes or users. Maintaining data integrity is critical for preventing unauthorized modifications, corruption, or loss of data.
STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a widely used threat modeling framework to identify and address security threats in Kubernetes clusters. It helps teams systematically analyze potential threats and design appropriate mitigations.
| Threat | Description | Example | Mitigation |
|---|---|---|---|
| Spoofing | Attacker impersonates (pretend) a user, system, or entity as a legitimate user to gain unauthorized access. | An attacker uses stolen credentials to access a Kubernetes cluster as an administrator. | Use strong authentication mechanisms like multi-factor authentication (MFA) and enforce Role-Based Access Control (RBAC) in Kubernetes. |
| Tampering | Attacker modifies data or configurations to compromise integrity. | An attacker alters data being sent to a Kubernetes API server, leading to unauthorized changes in the cluster. | Use immutable infrastructure, enable audit logging, encryption for data in transit, and digital signatures for data integrity. |
| Repudiation | The ability of a user to deny performing an action because there is no evidence to trace the action back to them. This can lead to situations where a user can claim they didn't perform a certain action, such as making unauthorized transactions, accessing restricted data, or any other activity that could have negative consequences. | A malicious user deletes Kubernetes pods, but there are no logs to identify who performed the action. | Enable Kubernetes audit logs and integrate them with tools like Splunk or Elasticsearch for traceability. |
| Information Disclosure | Unauthorized access or exposure of sensitive information to unauthorized entities. | Sensitive data in Kubernetes secrets is exposed to unauthorized users. | Encrypt sensitive data at REST and in transit, use tools like HashiCorp Vault for secret management, and implement network policies to restrict access. |
| Denial of Service (DoS) | Overloading a system to make it unavailable to legitimate users. | An attacker floods the Kubernetes API server with requests, causing it to become unresponsive. | Implement rate limiting, network policies, and resource quotas to prevent abuse. |
| Elevation of Privilege | Gaining higher privileges (eg: admin rights) than intended. | A compromised container gains root access to the host node and escalates privileges across the cluster. | Use Pod Security Policies (PSPs), enforce least privilege principles, run containers as non-root users, and implement strict RBAC policies. |
DREAD
DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) helps prioritize threats based on their potential impact and likelihood. It assigns a score to each threat based on these factors, allowing teams to focus on the most critical threats first.
| Factor | Description | Key Question | Example |
|---|---|---|---|
| Damage | The potential impact or severity of the threat if it is successfully exploited. | How much damage will the attack cause? | A compromised Kubernetes node allows attackers to access sensitive data across the cluster. |
| Reproducibility | How easily the threat can be reproduced or repeated by an attacker. | How easy is it to reproduce the attack? | An attacker can repeatedly exploit a misconfigured API server to gain unauthorized access. |
| Exploitability | The effort or resources required to exploit the threat. | How much effort is required to exploit the vulnerability? | Exploiting a weak password policy requires minimal effort using automated tools like brute force scripts. |
| Affected Users | The number of users or systems impacted by the threat. | How many users or systems will be affected? | A DoS attack on the Kubernetes API server affects all users and workloads relying on the cluster. |
| Discoverability | How easily the threat can be discovered by an attacker. | How easy is it to discover the vulnerability? | An exposed Kubernetes dashboard with no authentication is easily discoverable through network scanning tools. |
MITRE ATT&CK
More Information
MITRE ATT&CK is a comprehensive knowledge base of adversary tactics and techniques based on real-world observations. It provides a framework for understanding how attackers operate and helps organizations identify potential threats to their Kubernetes environments.
- tactics - what attackers aim to do?
- techniques - how attackers do it?
Tactics
Tactics represent the high-level goals that an attacker is trying to achieve during an attack. Each tactic defines a specific phase in the attack lifecycle.
| Tactic | Description | Example |
|---|---|---|
| Initial Access | Techniques used to gain initial entry into a system. | Phishing, exploiting software vulnerabilities. |
| Execution | Techniques the attacker uses to run malicious code on a system. | Scripting, command-line interfaces. |
| Persistence | Methods an attacker uses to maintain access even after a system reboot or interruptions. | Setting up startup scripts, modifying registry entries. |
| Privilege Escalation | Techniques used to gain higher-level permissions on a system or network. | Exploiting vulnerabilities or misconfigurations. |
| Defense Evasion | Methods used to avoid detection by security tools. | Obfuscation, file modification. |
| Credential Access | Techniques for stealing user credentials. | Keylogging, credential dumps. |
| Discovery | Methods to gather information about a network or system to further the attack. | Scanning, enumeration. |
| Lateral Movement | Techniques used to move within a network. | Exploiting trust relationships, remote services. |
| Collection | Gathering data of interest, such as sensitive files or credentials. | Data from local files, browser history. |
| Exfiltration | Techniques to transfer data out of the target network. | Using encrypted channels, covert channels. |
| Impact | Techniques that result in disruption or damage to systems. | Data encryption, destruction of data. |
Techniques
Techniques are specific methods employed by attackers to accomplish a tactic. Each technique can have multiple variants that describe variations on how the technique may be executed.
| Tactic | Technique | Example |
|---|---|---|
| Execution | PowerShell | Using PowerShell scripts to execute commands. |
| Execution | JavaScript | Running malicious JavaScript code in a web browser. |
Sub-techniques
Some techniques have sub-techniques that provide more granularity.
| Technique | Sub-technique | Description |
|---|---|---|
| Credential Dumping | LSASS Memory | Extracting credentials from the Local Security Authority Subsystem Service memory. |
Mitigation and Detection
For each technique, MITRE ATT&CK typically provides recommendations for mitigations and detection strategies.
| Aspect | Description |
|---|---|
| Mitigation | Recommendations to prevent or reduce the impact of a technique. |
| Detection | Strategies to identify and respond to potential exploitations by adversaries. |
Supply Chain Compliance Frameworks
Understand what is supply chain compliance frameworks?
We know that Compliance Frameworks define what to do or what needs to be done to meet legal, regulatory, and industry standards and Threat Modeling Frameworks define how to do it by providing a structured approach to identifying and addressing potential security threats.
Both of the frameworks are securing the internal components of the Kubernetes environment or application , what about the external components your application depends on? (For example, libraries, APIs, third-party services, docker images, etc.)
All these need to be secured and compliant as well, and this is where Supply Chain Compliance Frameworks come into play. Supply Chain Compliance Frameworks are structured guidelines and best practices that organizations follow to ensure they meet regulatory requirements and industry standards for their supply chain.
- verify the integrity and authenticity of external components and services that integrates into the Kubernetes environment or application.
There are some key components to secure supply chain;
- Artifact - The binaries and container images are signed and verified to ensure their integrity and authenticity.
- Metadata - SBOM will detail all the components, libraries, and dependencies that are included in a software artifact, which can be used to assess security risks and vulnerabilities.
- Attestation - Signed statements about the software artifacts and their metadata like SBOM. For example, this SBOM is signed by the Kubernetes project and verified by the Kubernetes community.
- Policy - Integrate policy with Kubernetes Admission Controller to enforce policies on signed artifacts and SBOMs before they are deployed into the cluster.
Artifact
Artifacts are the output of a build system. They are the software components that are produced by the build process. Artifacts can be things like container images, binaries, packages, tarballs, etc.
These artifacts will be deployed into production environments. So, it's important to verify the integrity and authenticity of these artifacts before deploying them.
In Kubernetes, artifacts are signed during the process of building and deploying using tools like Cosign and Notary. These tools can sign and verify container images and other artifacts to ensure their integrity and authenticity.
Metadata
References
Metadata is the data that describes the software artifacts. Meaning that, it provides information about what's inside the artifact. Metadata can include information like the software version, dependencies, build environment, etc.
SBOM
One of the most important type of metadata is Software Bill of Materials (SBOM) - Ingredient List. An SBOM is a list of all the components, libraries, and dependencies that are included in a software artifact. It provides a detailed inventory of the software components, their versions, and sources, which can be used to assess security risks and vulnerabilities. It contains two formats;
- CycloneDX - A lightweight SBOM standard designed for use in application security contexts and supply chain component analysis.
- SPDX - A standard format for communicating software bill of materials information, which is widely used in open source and commercial software projects.
Here's an example of an SPDX file tailored for a Kubernetes-related project in the SPDX tag-value format:
SBOM will be generated for each release of the Kubernetes project and signed for authenticity.
In Kubernetes, SBOMs can be generated using tools like Syft and Grype. These tools can analyze container images and generate SBOMs in various formats, including CycloneDX and SPDX.
To verify the integrity of the SBOM, you can use tools like Cosign to sign and verify the SBOM files. You can also use sha512sum to generate a checksum for the SBOM file and verify it against the original file.
This will ensue that the SBOM file has not been tampered with and is authentic.
Attestation
sha512sum vs Attestation
sha512sum is different from Attestation. sha512sum is used to ensure the downloaded file matches what the server published, meaning it will ensure the file's integrity during transit (file content is not changed).
But Attestation adds another layer of security (trust) by ensuring that the file is not only intact (complete) but also authentic and verified by a trusted party. This means that the file was created by a trusted source and has not been tampered with since it was signed.
Metadata is useful, but how do we ensure that the metadata is trustworthy? This is where Attestation comes into play. Attestation is signed statements about the software artifacts and their metadata like SBOM. For example, this SBOM is signed by the Kubernetes project and verified by the Kubernetes community.
The trusted party (eg; Kubernetes release team) will generate the SBOM and sign it using a private key to create an attestation. The attestation will include the SBOM and a signature that can be verified (authenticity) using the public key of the trusted party.
Here is the process of creating an attestation using Cosign:
Attestation Framework: in-toto
Refereces
One of the widely used attestation frameworks is in-toto. It provides a framework for securing the software supply chain by creating and verifying cryptographically signed attestations. It provides a mechanism to verify that all steps in the supply chain were executed as expected and that the resulting artifacts have not been tampered with.
Policy
Now, we have the signed artifacts and SBOMs with attestations, but how do we ensure that these artifacts and SBOMs are compliant with our policies at different stages of the software supply chain as well as only deploy verified trustworthy artifacts? This is where Policy comes into play. Policies are the rules and guidelines that define what is acceptable and what is not in your Kubernetes environment to ensure compliance and security.
In this case, it can help to prevent insecure or non-compliant artifacts from being deployed into production. There are multiple tools that can enforce policies in Kubernetes;
- OPA (Open Policy Agent) - A general-purpose policy engine that can enforce policies in Kubernetes and other systems.
- Kyverno - A Kubernetes-native policy engine that can validate, mutate, and generate resources based on policies.
- Sigstore - A tool for signing and verifying container images and other artifacts, which can be used to enforce policies on signed artifacts.
Sigstore's policy controller can be integrated with Kubernetes Admission Controller to enforce policies on signed artifacts and SBOMs before they are deployed into the cluster.