KCSA — Regulatory & Data Protection
Regulatory & Data Protection
Organizations running workloads on Kubernetes often process sensitive data — personal information, financial records, healthcare data. Regulations like GDPR, HIPAA, and PCI DSS impose strict requirements on how this data is handled. For the KCSA exam, you must understand which regulations apply, what they require, and how Kubernetes features map to those requirements.
Why Regulations Matter for Kubernetes
Data does not exist in a vacuum. It lives in databases running as Kubernetes pods, travels through Kubernetes services, and is processed by containerized applications. When regulated data enters a Kubernetes cluster, the cluster becomes subject to those regulations.
Non-compliance can result in:
| Consequence | Example |
|---|---|
| Financial penalties | GDPR fines up to €20M or 4% of global annual revenue |
| Legal liability | HIPAA violations can lead to criminal charges |
| Business loss | PCI DSS non-compliance can revoke the ability to process credit cards |
| Reputation damage | Data breaches erode customer trust |
Kubernetes does not make you compliant by default — you must configure and operate it to meet regulatory requirements.
Regulations Overview
The following table compares the major regulations you may encounter on the KCSA exam.
| Regulation | Full Name | Region | Focus | Mandatory? | Key K8s Impact |
|---|---|---|---|---|---|
| GDPR | General Data Protection Regulation | EU (global reach) | Personal data protection | Yes (law) | Encryption, access control, data residency, right to deletion |
| HIPAA | Health Insurance Portability and Accountability Act | US | Healthcare data (PHI) | Yes (law) | Audit logging, encryption, access control, BAAs |
| PCI DSS | Payment Card Industry Data Security Standard | Global | Payment card data | Yes (industry mandate) | Network segmentation, encryption, key management, access control |
| SOC 2 | System and Organization Controls 2 | US/Global | Service organization controls | Voluntary (customer-driven) | Security, availability, monitoring, access control |
| FedRAMP | Federal Risk and Authorization Management Program | US | Federal cloud security | Yes (for federal contracts) | Comprehensive security controls (based on NIST 800-53) |
GDPR Requirements in Kubernetes
The General Data Protection Regulation (GDPR) applies to any organization that processes personal data of EU residents, regardless of where the organization is located.
Core GDPR Principles Mapped to Kubernetes
| GDPR Principle | Description | Kubernetes Control |
|---|---|---|
| Lawfulness & Transparency | Process data lawfully, tell users what you do | Application-level concern (not K8s-specific) |
| Purpose Limitation | Collect data only for specified purposes | Namespace isolation, RBAC (limit who accesses what data) |
| Data Minimization | Collect only what is needed | Pod security (limit environment variables with sensitive data) |
| Accuracy | Keep data accurate and up-to-date | Application-level concern |
| Storage Limitation | Don’t keep data longer than necessary | Log rotation policies, data lifecycle management |
| Integrity & Confidentiality | Protect data through appropriate security | Encryption at rest, TLS in transit, RBAC, Network Policies |
| Accountability | Demonstrate compliance | Audit logging, policy-as-code, documentation |
GDPR Technical Requirements in Kubernetes
| Requirement | Kubernetes Implementation |
|---|---|
| Encryption at rest | Enable etcd encryption, encrypted PersistentVolumes (StorageClass encryption) |
| Encryption in transit | TLS for API server, service mesh mTLS, ingress TLS termination |
| Access control | RBAC with least privilege, namespace-level isolation |
| Audit logging | Kubernetes API audit logging enabled and forwarded to central log system |
| Data residency | Node affinity rules to restrict pods to specific regions/zones |
| Right to erasure | Application-level data deletion; consider PV data lifecycle |
| Breach notification | Runtime threat detection (Falco), centralized alerting (72-hour notification requirement) |
GDPR requires that you can demonstrate compliance — not just that you are compliant. Audit logs, policy enforcement records, and documentation are essential evidence.
PCI DSS Requirements in Kubernetes
The Payment Card Industry Data Security Standard (PCI DSS) applies to any organization that stores, processes, or transmits credit card data. PCI DSS v4.0 has 12 high-level requirements organized into six goals.
PCI DSS Requirements Mapped to Kubernetes
| PCI DSS Requirement | Description | Kubernetes Implementation |
|---|---|---|
| 1. Network Security Controls | Install and maintain network security controls | Network Policies, CNI enforcement, namespace isolation |
| 2. Secure Configurations | Apply secure configurations to all components | CIS Benchmark compliance, admission controllers, Pod Security Standards |
| 3. Protect Stored Data | Protect stored account data | Encryption at rest (etcd, PVs), Secret management (Vault) |
| 4. Encrypt Transmissions | Encrypt cardholder data in transit | TLS everywhere, service mesh mTLS |
| 5. Protect Against Malware | Protect systems against malicious software | Image scanning, runtime security (Falco), admission control |
| 6. Secure Development | Develop and maintain secure systems | Secure CI/CD, image signing, vulnerability scanning |
| 7. Restrict Access | Restrict access by business need-to-know | RBAC, namespace isolation, service account controls |
| 8. Identify Users | Identify users and authenticate access | OIDC, X.509 certificates, no shared accounts |
| 9. Physical Access | Restrict physical access to cardholder data | Cloud provider responsibility (data center security) |
| 10. Log and Monitor | Log and monitor all access | Kubernetes audit logging, centralized logging, SIEM integration |
| 11. Test Security | Test security regularly | kube-bench, kube-hunter, penetration testing, vulnerability scanning |
| 12. Security Policies | Maintain security policies | Policy-as-code, documented procedures, security training |
Cardholder Data Environment (CDE) Isolation
PCI DSS requires that the Cardholder Data Environment — any system that stores, processes, or transmits card data — be isolated from non-CDE systems.
In Kubernetes, CDE isolation can be achieved through:
| Method | Description |
|---|---|
| Dedicated namespace | Run CDE workloads in a dedicated namespace with strict RBAC |
| Network Policies | Default-deny ingress/egress; allow only necessary traffic to/from CDE pods |
| Dedicated nodes | Use taints and tolerations to schedule CDE pods only on hardened, dedicated nodes |
| Dedicated cluster | Most restrictive — run CDE workloads in a completely separate cluster |
The level of isolation required depends on the organization’s risk assessment and PCI DSS scope.
HIPAA Safeguards in Kubernetes
The Health Insurance Portability and Accountability Act (HIPAA) protects Protected Health Information (PHI) — any health data that can identify an individual.
HIPAA Safeguard Categories
| Safeguard Type | Focus | Kubernetes Relevance |
|---|---|---|
| Administrative | Policies, procedures, workforce training | Security policies, access management procedures |
| Physical | Facility access, workstation security | Cloud provider data center security |
| Technical | Access control, audit controls, transmission security | RBAC, audit logging, encryption |
HIPAA Technical Safeguards Mapped to Kubernetes
| HIPAA Requirement | Description | Kubernetes Implementation |
|---|---|---|
| Access Control | Restrict access to ePHI to authorized persons | RBAC, namespace isolation, service account controls |
| Audit Controls | Record and examine activity in systems with ePHI | API audit logging, application-level audit trails |
| Integrity Controls | Protect ePHI from improper alteration or destruction | Admission controllers, immutable containers, read-only filesystems |
| Transmission Security | Encrypt ePHI in transit | TLS, service mesh mTLS |
| Authentication | Verify identity of persons seeking access to ePHI | OIDC, X.509 certificates, MFA for cluster access |
Business Associate Agreements (BAAs)
If using a managed Kubernetes service (EKS, GKE, AKS) for HIPAA workloads, you must have a Business Associate Agreement (BAA) with the cloud provider. All major cloud providers offer HIPAA-eligible services and BAAs.
Data Residency and Sovereignty
Data residency refers to the physical location where data is stored. Data sovereignty refers to the legal jurisdiction governing that data.
Why It Matters
- GDPR may require that EU citizen data stays within the EU
- Certain government regulations require data to remain within national borders
- Business contracts may specify data location requirements
Kubernetes Controls for Data Residency
| Control | How It Works |
|---|---|
| Node affinity | Schedule pods to nodes in specific regions or availability zones |
| Topology constraints | Use topologySpreadConstraints to control pod placement |
| Taints and tolerations | Mark region-specific nodes; only pods with matching tolerations can run there |
| Namespace labels | Label namespaces with region metadata for policy enforcement |
| Multi-cluster federation | Run separate clusters in different regions with region-specific policies |
# Example: Schedule pod only on EU nodes
apiVersion: v1
kind: Pod
metadata:
name: eu-data-processor
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/region
operator: In
values:
- eu-west-1
- eu-central-1
containers:
- name: processor
image: myregistry.io/data-processor:v2.1.0
Data residency is a shared responsibility — Kubernetes provides scheduling controls, but the organization must define and enforce the policy.
Encryption Requirements
Almost every regulation requires encryption. In Kubernetes, encryption must be addressed at two levels:
Encryption at Rest
| What | How | Kubernetes Feature |
|---|---|---|
| Secrets in etcd | EncryptionConfiguration resource | aescbc, secretbox, or KMS provider |
| Persistent Volumes | StorageClass-level encryption | Cloud provider encrypted volume classes (EBS, PD, Azure Disk) |
| Backups | Encrypt backup data | Velero with encryption, cloud provider backup encryption |
# Example: EncryptionConfiguration for etcd secret encryption
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: <base64-encoded-key>
- identity: {}
Encryption in Transit
| What | How | Kubernetes Feature |
|---|---|---|
| API server communication | TLS certificates | Built-in — API server requires TLS |
| etcd communication | Peer and client TLS | etcd --cert-file, --key-file, --peer-cert-file |
| Pod-to-pod traffic | Service mesh mTLS | Istio, Linkerd, Cilium |
| Ingress traffic | TLS termination | Ingress controller with TLS certificates |
| Kubelet communication | TLS | Kubelet serving certificates |
PCI DSS and HIPAA specifically require encryption of sensitive data in transit. GDPR requires “appropriate technical measures” which courts have interpreted to include encryption.
Audit Trail Requirements
Regulations universally require audit trails — the ability to answer “who did what, when, and to which data.”
Kubernetes Audit Logging
Kubernetes API server audit logging captures all API requests. The audit policy defines what to log.
| Audit Level | What Is Logged |
|---|---|
| None | Nothing — event is not logged |
| Metadata | Request metadata (user, timestamp, resource, verb) — no body |
| Request | Metadata + request body |
| RequestResponse | Metadata + request body + response body |
Audit Requirements by Regulation
| Regulation | Audit Requirements | Kubernetes Implementation |
|---|---|---|
| GDPR | Record processing activities, demonstrate compliance | API audit logging (Metadata level minimum), policy enforcement logs |
| HIPAA | Log all access to ePHI, review logs regularly | API audit logging (Request level for sensitive resources), centralized log analysis |
| PCI DSS | Log all access to cardholder data, retain logs for 1 year | API audit logging, centralized SIEM, log retention policies |
| SOC 2 | Log security-relevant events, monitor for anomalies | API audit logging, runtime detection (Falco), alerting |
Audit logs must be stored securely, forwarded to a centralized system, and retained according to regulatory requirements. Kubernetes audit logs on the API server alone are not sufficient — they must be shipped to durable, tamper-resistant storage.
Key Takeaways for the Exam
| Concept | What to Remember |
|---|---|
| GDPR | EU personal data protection law; requires encryption, access control, data residency, right to erasure, 72-hour breach notification |
| HIPAA | US healthcare data law; requires technical, administrative, and physical safeguards for PHI; BAAs with cloud providers |
| PCI DSS | Payment card security standard; 12 requirements; CDE must be isolated; network segmentation critical |
| SOC 2 | Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy |
| FedRAMP | US federal cloud security program based on NIST 800-53 |
| Data residency | Control data location using node affinity, taints/tolerations, multi-cluster federation |
| Encryption at rest | etcd encryption (EncryptionConfiguration), encrypted PersistentVolumes |
| Encryption in transit | TLS for API server, etcd, kubelet; service mesh mTLS for pod-to-pod |
| Audit logging | Four levels: None, Metadata, Request, RequestResponse; ship to centralized, durable storage |
| Shared responsibility | Cloud provider handles physical/infrastructure security; customer handles cluster configuration and workload security |
