Kubernetes compliance under SOC 2

System Organization Controls (SOC 2) is an auditing procedure developed by the American Institute of Certified Public Accountants (AICPA) to ensure service providers manage data securely. SOC 2 applies to all companies that process, store, or transmit client information in the cloud, and the cost of non-compliance can be significant in terms of penalties, legal action, or damage to a company’s reputation. 

• 👋 Read more articles in our compliance series: 
• ✅ An essential guide to achieving compliance with Kubernetes
• ✅ The definitive guide to compliance with cloud-managed Kubernetes
• ✅ Introducing Compliance Score: simplifying compliance assessment
• ✅ Kubernetes compliance & GDPR
• ✅ Kubernetes compliance & HIPPA
• ✅ Kubernetes compliance & ISO 27001

It is therefore important for businesses that handle sensitive data to understand what they must do to meet various criteria in their data security and management practices.

In this article, we will discuss the five trust services criteria (TSC) of SOC 2 and how they apply to Kubernetes compliance. We will also explore how to leverage Kubernetes security features and tools to meet SOC 2 requirements, as well as implement continuous cluster monitoring best practices and automated audit scanning tools to maintain compliance.

Understanding SOC 2 compliance for Kubernetes clusters

SOC 2 compliance requirements are divided into five trust services criteria (TSCs):

• Security: Security of customer data, including access control, data encryption, and vulnerability management; the only mandatory requirement for SOC 2 compliance
• Availability: Availability of customer data; disaster recovery and business continuity planning
• Processing integrity: Accuracy and completeness of customer data; data validation and change management
• Confidentiality: Protection of customer data from unauthorized disclosure, including via access control and data encryption
• Privacy: Protection of customer data from unauthorized use, such as through the use of data retention and disposal policies

Kubernetes has security features such as network policies, labels, and namespaces for securing cluster workloads. However, there are challenges in securing Kubernetes clusters for SOC 2 compliance. 

One of the biggest obstacles is the highly dynamic and ephemeral nature of containerized workloads, which makes it difficult to implement and manage security controls on network resources. Kubernetes clusters may spin up and shut down pods and services very rapidly, posing a challenge to maintaining a current network diagram for the cluster. This is because pod IP addresses change upon re-creation in the cluster and network reassignment is needed to ensure that network resources using the pods as endpoints remain in service. 

This is particularly important for SOC 2-compliant workloads, where it is critical to ensure proper segmentation so that environments with sensitive data or personally identifiable information (PII) are separated from other network services. This division will protect you against a breach in the case of privilege escalation attacks.

Kubernetes security features and tools for meeting SOC 2 requirements

Kubernetes has several built-in features and design patterns that are useful for managing and securing SOC 2-compliant workloads. For one, the containerization of applications in Kubernetes allows for workload isolation, making it easier to ensure that sensitive customer data is protected. 

However, Kubernetes includes a variety of other features, which we discuss below. These allow for fine-grained access control of cluster resources, thus enhancing the security of customer data in your network.

Network segmentation of publicly accessible and internal components

Network segmentation of publicly accessible and internal components involves dividing the network into isolated segments for better security and manageability. In the context of Kubernetes, this is achieved through the use of Ingress and ClusterIPs.

The Kubernetes Ingress API object allows the administrator to manage access by external parties to the network’s cluster services based on the IP address, hostname, or URL path of the incoming request. This lets organizations make sure only authorized users are granted permissions, reducing the risk of a security incident.

Firewalling of ingress and egress traffic between applications

Organizations must control traffic flow at the IP address or port level to specify how an application is allowed to communicate with other applications within the network. In the context of Kubernetes, firewalling is achieved through the use of network policies.

Kubernetes network policies define the traffic rules for pods in a cluster; these allow the cluster administrator to control pod-to-pod network communication. They can also limit network access between pods based on their namespaces, label selectors, or IP blocks. In this way, organizations restrict communication to authorized pods only, thus decreasing the threat of a breach.

A container network interface (CNI) is necessary when implementing Kubernetes network policies. By applying these to a pod, traffic policy can be switched from default-allow to default-deny, where only allow-listed traffic is permitted. This enables fine-grained control of network traffic between applications, ensuring that only authorized traffic is granted access and improving the overall system’s security.

Encryption of data in transit

Encryption of data in transit is an important requirement for service providers, as sensitive data and PII are often processed and transmitted over internal and public networks in the cloud.

For data transmission within the cluster, it is recommended to use a service mesh such as Istio to encrypt all traffic between pods and secure communication between services. The Istio service mesh provides the ability to enforce TLS for encryption between services within the mesh. For encryption of transmission over public networks, cert-manager automates the management and issuance of certificates in the cluster to secure network resources, such as Ingress resources and the Istio service mesh.

Enforce workload isolation to limit blast radius

Implementing security controls to prevent unauthorized access and other vulnerabilities is a critical security requirement in SOC 2 compliance, as the consequences resulting from an un-contained data breach can be severe. Organizations must limit the blast radius of security breaches by applying the principle of least privilege; this will ensure that only authorized users have access to network resources utilized by workloads handling sensitive data.

Identity-aware microsegmentation enables DevSecOps teams to enforce workload isolation in clusters running multiple applications on the same cluster; they achieve this by securing the workloads individually with workload-specific policies and access controls. In Kubernetes, identity-aware microsegmentation can be implemented using the following approaches:

• Kubernetes RBAC (Role-based access control) restricts resource permissions based on users’ roles.
• Kubernetes namespaces provide a mechanism for scoping a cluster into isolated sub-clusters with their own groups of cluster resources.
• Kubernetes labels apply network policies to a subset of cluster resources within the same namespace.
• Lightweight Directory Access Protocol (LDAP) using OpenID Connect (OIDC) providers manages user authentication and authorization to restrict access to sensitive data to authorised users.

Guidelines for ensuring SOC 2 compliance over time

As SOC 2 audits are typically conducted annually, organizations must establish robust monitoring practices, which we discuss in the following sections. These will ensure that your security controls and operations continue to comply with SOC 2 requirements over time. For Kubernetes compliance under SOC 2, such practices are aided by scanning and policy enforcement tools to identify security vulnerabilities and misconfigurations in the cluster.

Continuous logging, monitoring, and automated audit scanning

Setting up continuous logging, monitoring, and automated audit scanning is critical to demonstrate and maintain continuous SOC 2 compliance, as well as mitigate any active threats. For Kubernetes clusters, continuous monitoring should be implemented at each layer in the cluster infrastructure stack, which includes container images in pods and network communications involving cluster resources.

Scanning container images enables you to detect security vulnerabilities inherited from external dependencies, such as open-source packages and third-party registries.

Preventing misconfigurations

It is important to implement strict security policies to prevent any misconfigurations. Kubernetes’ Pod Security Standards and Pod Security Admission enforce policies to make sure pods are deployed with the necessary security contexts and capabilities. Alternatively, CNCF projects such as Kyverno explicitly list required capabilities and enforce security policies across the cluster.

Open Policy Agent (OPA) works to identify misconfigurations such as the use of default passwords. This is particularly important in Kubernetes environments managed by DevSecOps teams, where misconfigurations may be inadvertently introduced via automated deployment tools in a CI/CD pipeline. OPA is a policy engine that integrates with Kubernetes to provide fine-grained control over resource access and configuration. 

By leveraging OPA, DevSecOps teams can ensure that all configurations and policies adhere to compliance standards such as SOC 2.

Traffic logging

Logging traffic to monitor access to network resources and sensitive customer data in the cluster is key to ensuring data is being managed properly. FluentD, Prometheus, and Grafana are popular tools for collecting and visualizing logs from the Kubernetes cluster; these allow DevSecOps engineers to monitor for all instances of access being granted to network resources, pods, and storage.

Automated audit scanning

Automated audit scans are essential for ensuring that Kubernetes clusters are SOC 2 compliant. Scanning the Kubernetes cluster against Kubernetes security frameworks such as the CIS Benchmark can help you identify and remediate security misconfigurations. This, in turn, assists organizations in preventing breaches involving sensitive customer data, which can result in significant penalties and loss of customer trust.

Conclusion

Ensuring SOC 2 compliance is crucial for companies that handle sensitive client information, as the cost of non-compliance can be significant in terms of financial penalties and damage to reputation. DevSecOps engineers can adhere to the needed criteria by leveraging existing Kubernetes security tools and following best practices for cluster security. ARMO Platform powered by Kubescape gives you over 200 security controls out-of-the-box, based on recognized industry frameworks, as well as RBAC visualization. All of which help you achieve compliance. The dashboards and notifications that monitor drift, will ensure your compliance over time.

Unifying AppSec, CloudSec and DevSec

The only runtime-driven, open-source first, cloud security platform:

Continuously minimizes cloud attack surface

Secures your registries, clusters and images

Protects your on-prem and cloud workloads

Powered by Kubescape & eBPF

See ARMO in Action