Achieve and Enforce GDPR Compliance for Containers & Kubernetes

Glen Kosaka Cloud Security

The GDPR (General Data Protection Regulation) for the protection of privacy provides both specific and vague requirements for personal data protection by enterprises. Therefore, the path to GDPR compliance is murky and ambiguous. For modern cloud-native deployments such as containers and using Kubernetes it can be even more confusing for security and compliance teams.

While GDPR contains many provisions which are outside the scope of cyber security teams, such as consent and removal of personal data or organizational processes, its basic data protection and breach reporting requirements directly impact cyber security efforts. This article will focus on the cyber security aspects of GDPR compliance for modern cloud-native infrastructures including containers, Kubernetes, and public or private cloud deployments.

For GDPR compliance planning, the first question to be asked is “How are you protecting personally identifiable information (PII) as prescribed by GDPR in your container and/or Kubernetes deployments?”

If your answer is ‘We’re enforcing GDPR compliance for containerized applications with our traditional firewalls, endpoint security, and compliance tools,‘ then you are at risk for huge fines after your next breach.

GDPR compliance requires ‘reasonable effort’ to protect data, but relying on antiquated security tools which are blind to container network traffic, attacks, and vulnerability exploits will not impress the governing body. It will not meet some of the basic audit questions of GDPR compliance regulators, such as:

  • Was there reasonable effort made to protect these new infrastructures from attacks?
  • Are there demonstrable controls for detecting and preventing attacks unique to these cloud-native and container environments?
  • Is there capability to capture details of breaches in container deployments for the required forensic and reporting purposes of GDPR?

Failure to provide evidence for the above answers can lead to increased fines in the event of a data breach.

What Does GDPR Compliance Mean for Cyber Security Teams?

There are many aspects of GDPR compliance that affect overall data protection and compliance efforts but some have specific implications for cyber security teams. It can be difficult to parse out actionable security requirements from the GDPR text.

Types of data considered to be part of GDPR compliance include:

  • Names, addresses, national ID’s (e.g. US Social Security number), email addresses and account numbers
  • Medical records, including health and genetic data
  • Cookies, IP addresses, or other location data for an individual
  • Ethnicity, race, sexual orientation, or political opinions associated with an individual

Most security professionals will focus on Article 32 for guidance on their GDPR compliance program, which contains technical guidance on cyber security controls. Articles 24, 25, 28, 33, 34 & 35 also have some broad guidance for designing risk-based controls and notification requirements. Sample requirements include:

  • Taking into account the “state of the art … implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.”
  • Reporting of breaches within 72 hours after discovery.

But what is ‘state of the art’ for container security? And what is the risk of breach in a containerized environment?

State of the Art – Basic Data Hygiene for Containers

In a cloud-native, container based environment, ‘state of the art’ for GDPR compliance means utilizing technologies and processes that provide protections unique to these modern deployments. Here is a mapping of traditional cyber security measures to the state of the art:

  • Identify and fix vulnerabilities and configurations which can be exploited. [State of the Art] End-to-end vulnerability management for the entire pipeline, including build, ship, and run-time. Includes compliance checks such as the CIS Benchmarks for Kubernetes and OpenShift.
  • Encrypt protected data that can’t be anonymized. [State of the Art] Use encryption for pod-to-pod network communications and for data at rest, in containers, databases, and mapped volumes.
  • Monitor and firewall network traffic to identify and prevent attacks. [State of the Art] Use a Layer7 container firewall, network policies, and other container-optimized network tools to detect attacks, segment traffic, block attacks, and quarantine containers.
  • Protect web applications from attacks. [State of the Art] Inspect all internet ingress traffic to web front-end pods as well as egress connections for application layer attacks such as sql injection, tunneling, and dns attacks.
  • Provide alerting, logging, and forensics for suspicious activity. [State of the Art] Utilize SYSLOG, webhooks, container logging (prometheus, fluentbit…) for SIEM integration, container packet capture, container security event logs, and admission control events to support anomaly detection and forensics.

End-to-End Vulnerability Management

A comprehensive vulnerability management program is required to prevent exploits on containers, the orchestrator (e.g. Kubernetes), and the hosts they run on. As pipelines become more automated, it is critical to be able to demonstrate how vulnerability scanning and management is automated into the pipeline.

For vulnerabilities without patches available, or in production containers already running, a technique called ‘virtual patching‘ can address the risk of exploit.

NeuVector Vulnerability Explorer identifies critical vulnerabilities and which are ‘virtually patched.’


Compliance Checks

Compliance and auditing checks such as the CIS Benchmarks for Kubernetes are critical to continuously audit configurations and remove misconfigurations that could open an attack vector. These standard benchmarks as well as custom checks or scripts can be used to demonstrate GDPR compliance against misconfiguration risk.

NeuVector is also the first to implement Red Hat Openshift benchmarks for automatically auditing configurations of OpenShift deployments.

Network Segmentation and Firewalling

A cornerstone of defense in depth is the ability to segment, or firewall, network traffic to allow only authorized connections and protocols and block potential attacks. This is difficult to achieve in a container deployment without a true layer 7 container firewall which can inspect all internal, ingress, and egress connections.

The security industry is moving from a blacklist-based firewall approach to a declarative, whitelist-based approach. Traditional firewall rules with bad-IP blacklists had too many false positives and were difficult to manage, and this can’t be tolerated in modern cloud deployments with continuous deployments and updates. More information about container segmentation patterns can be found here.

Beyond container segmentation and threat detection, advanced network security for defense in depth includes container packet captures for forensics, quarantine of suspicious containers, and the use of deep packet inspection (DPI) for data loss prevention (DLP).

For GDPR compliance, security teams must be able to demonstrate that they use state of the art technical controls to prevent breaches. After a breach, this reporting would include segmentation (firewall) rules, forensic data, vulnerability scans results and documented processes to monitor and log access to all systems.

In NeuVector, the firewall, process, and file rules can be shown in the console or in version-controlled NeuVector CRD yaml files which are used to implement ‘Security as Code.’

Console Screen Shot for Network Rules


CRD ‘Security as Code’ yaml File Snippet


Security teams are also able to demonstrate to regulators how unauthorized connections are detected, blocked, logged, alerted, and packet captured in NeuVector. For example, packet capture of network threats are automatically triggered as seen below.

Automated packet capture of network attacks


Full network packet captures in rotating pcap files can also be initiated manually or automatically on containers/pods with suspicious activity.

For security best practices and ’10 Steps to Automate Container Security’ see this article and downloadable e-book.

Using DPI and DLP to Detect GDPR Compliance Violations

GDPR does not specifically require organizations to inspect network traffic for protected data violations. But organizations which take GDPR compliance seriously and implement defense in depth will monitor all channels for data breaches including file shares, social networks, web applications, gateways, api services, and blogs. In a container environment, especially where public cloud, hybrid cloud, and multi-cluster architectures are used, even east-west (internal) traffic needs to be monitored because there is a blurring distinction (or even no notion) of a data center edge any more.

By implementing DLP systems that monitor both internet-bound and internal data communications from containers, the risk of breach can be dramatically reduced. For example, NeuVector uses deep packet inspection (DPI) to inspect the network payload of container communications. Built-in and custom DLP sensors can be enabled to detect potential policy violations, with alerts and visualization like below.

Network Container DLP

Detecting credit card data violations in container connections


However, in GDPR the responsibility for data protection lies not only within an enterprise but extends to relevant external organizations, also called ‘data processors.’

Monitor Communications Externally with Partners, Suppliers, Vendors

Organizations, as ‘data controllers,’ must not only monitor and protect data within the enterprise but also to external contractors and partners. GDPR compliance extends beyond corporate boundaries to any external party (SaaS vendors, payroll companies, licensed channels) which may handle its sensitive data. Not only are there legal contracts required between these ‘data processors,’ but each organization must be able to show GDPR compliance, including the ability to detect and report data breaches.

For security teams, this means being able to restrict the transmission of encrypted sensitive data to only authorized, GDPR compliant partners. The ability to block any unencrypted transmission as well as any transmission to non-authorized partners should also exist.

Inspect Communication Externally and to API Services

Many applications deployed as containers will require communication outside the Kubernetes cluster and even to external API services. It is therefore critical to identify which external connections contain GDPR protected data and monitor these connections in depth. As part of the DevOps and CI/CD pipeline process, application teams should be required to identify and label images which when deployed are subject to GDPR compliance monitoring. This is where requiring image and/or deployment labels can be useful.

For example, in containers and Kubernetes the ability to use container labels during deployment can serve to identify which deployed containers are allowed external connections to data processors which contain GDPR protected data.

In NeuVector, an allowed egress connection starts with defining a new Group with the external address, dns name, and/or container label.

Then, create a network rule to allow connection from a pod group to this partner service. These connections can be required to be encrypted, and further deep packet inspection can validate the type of protected data allowed in the transmission.

Add a DLP sensor to inspect the network payload for protected GDPR data for selected egress flows. Also add credit card and SSN sensors if applicable.

Note that although the network rule requires encrypted connections, if encryption is implemented with a service mesh such as ISTIO, NeuVector can still inspect the network payload for DLP violations before it is encrypted and sent out. This enables granular security policies to be enforced even for encrypted egress connections, such as:

  • Ensure allowed connections to partners are encrypted.
  • Block specific GDPR protected data transmissions to partners that don’t need them, even if encrypted, by using DLP.
  • Block any unencrypted transmission of GDPR protected data by using DLP.

Using the console or CRD yaml files, network security policies are now deployed which are automatically applied to every container with the GDPR labels, eliminating the need to create new rules for each new application deployed.

Reporting Breaches – Being Prepared

As mentioned previously, data breaches are required to be reported to regulators within 72 hours of breach discovery. This is a daunting challenge for many organizations, even the most well prepared. Having all the required data, logs and forensic material readily available through NeuVector will:

  • Decrease the time from the initial hacker’s activity to discovery of the suspicious activity, enabling tracking of activities typically found in the ‘kill chain’ of a breach.
  • Enable security teams to analyze and correlate events to understand the breadth and scope of the breach, and which data was affected.
  • Provide evidence to regulators that ‘state of the art’ protections were in place and that alerting and logging systems have captured breach activity, possibly reducing resulting fines.
  • Improve the level of detail provided in public disclosures and notifications to affected people, possibly retaining customer ‘good will.’

Using PCI, ISO 27001 and Other Regulations to Create a GDPR Security Framework

Because the technical requirements for GDPR compliance can be vague and open to grossly different interpretations, it is useful to draw from other, more specific regulations such as PCI-DSS. For example, PCI is very specific about implementing a vulnerability management program to reduce the risk of vulnerability exploits leading to data breaches. It is also very specific about the need for network firewalling and the requirement for segmentation of network access for CDE (cardholder data environment) vs. non-CDE systems.

For a detailed mapping of PCI0-DSS, ISO 27001, and HIPAA for GDPR compliance, see this post by Audian Paxon. For a discussion of PCI-DSS as related to containers, see this post.

GDPR Compliance Best Practices

GDPR compliance for cyber security teams really means implementing best practices for defense in depth. In a containerized Kubernetes environment, there are new practices as well as modifications of traditional ones required to protect GDPR data.

NeuVector is uniquely positioned to help organizations enforce GDPR compliance.

  • End-to-end vulnerability scanning in the CI/CD pipeline and into production. A vulnerability and compliance management tool to identify and remediate the most critical risks.
  • Configuration auditing and compliance with standards based CIS Benchmarks and custom checks to prevent misconfigurations of container infrastructures.
  • Unique network segmentation and container firewall to detect threats, block attacks, and capture forensic network data.

The NeuVector Container Security Platform provides the ‘state of the art’ security controls for container based deployments. This will enable organizations to protect sensitive data and prove GDPR compliance efforts to regulators.