HIPAA Compliance on Kubernetes: A Technical Guide

Running healthcare workloads on Kubernetes requires careful attention to HIPAA compliance. Container orchestration introduces unique challenges around Protected Health Information (PHI) — but with the right architecture, Kubernetes meets every HIPAA technical safeguard requirement.

What HIPAA Requires Technically

HIPAA's Security Rule defines three safeguard categories. The technical safeguards most relevant to Kubernetes are: Access Control (unique user identification, automatic logoff after inactivity), Audit Controls (record who accessed PHI and what action they took), Integrity (PHI must not be improperly altered or destroyed), and Transmission Security (encrypt PHI in transit using strong TLS).

HIPAA doesn't mandate specific technologies — it requires demonstrable controls. Kubernetes provides the primitives; architecture and configuration determine whether you achieve compliance.

Access Control: RBAC for Healthcare Workloads

Kubernetes Role-Based Access Control (RBAC) maps directly to HIPAA's minimum necessary standard. Each user, application, and service should access only the PHI required for its specific function — nothing more.

• Namespace isolation — separate namespaces for PHI services vs. administrative and monitoring workloads
• Service account least privilege — application pods get only the API permissions they actually need
• No shared credentials — every human user gets a distinct identity, never a shared kubeconfig file
• MFA for all cluster access — require multi-factor for kubectl, dashboards, and CI/CD pipeline runners
• Quarterly access reviews — audit RBAC bindings and remove stale permissions promptly

PHI Encryption: At Rest and In Transit

HIPAA requires encryption of PHI both at rest and in transit. For encryption at rest: enable etcd encryption at the API server level for all Kubernetes Secrets, use encrypted storage classes (EBS with KMS on AWS, Azure Disk with CMK) for PersistentVolumes holding patient data, and never store PHI in container images, environment variables, or ConfigMaps.

For encryption in transit: deploy a service mesh (Istio or Linkerd) for automatic mutual TLS between all pods, enforce HTTPS-only ingress with no HTTP fallback for patient-facing endpoints, and require TLS 1.2 or higher — disable TLS 1.0 and 1.1 at the ingress controller.

Audit Logging: The HIPAA Audit Trail

HIPAA requires audit controls that record who accessed PHI, when, and what they did. The Kubernetes API audit log records every API server interaction — reads, writes, deletes. Configure your audit policy to capture at minimum: pod creation and deletion, secret access, and ConfigMap changes.

Forward logs to an immutable destination: AWS CloudWatch, Azure Monitor, or Splunk. Retain for at least 6 years per HIPAA requirements. Application-level audit trails must log: user identity, timestamp, action performed, and record accessed. Structured JSON logging makes records queryable during HIPAA audits and investigations.

Recommended tooling: Falco for runtime threat detection and PHI access anomaly alerts, Sysdig Secure for compliance reporting and audit trail visualization, and OpenSearch for long-term queryable audit log retention.

Network Segmentation for PHI Workloads

Not all workloads need access to PHI. Kubernetes NetworkPolicies create hard enforcement boundaries between services. Apply a default-deny posture first: only explicitly authorized services connect to PHI databases, PHI services make no arbitrary outbound connections, and all ingress is allowlisted to specific callers only. This limits PHI exposure to the minimum set of services with a documented, legitimate need.

Container Security for PHI Environments

• Minimal base images — Alpine or distroless images reduce attack surface significantly
• No root containers — enforce runAsNonRoot: true on all PHI workload pods
• Read-only root filesystems — prevent runtime file modification with readOnlyRootFilesystem: true
• Image scanning in CI/CD — scan every image with Trivy or Grype before deployment
• Private registries only — pull from your internal registry, never public Docker Hub in production

Apply Kubernetes Pod Security Standards (Restricted profile) to all namespaces handling PHI. This enforces all of the above controls automatically at the cluster admission level, removing the need for per-pod configuration.

HIPAA Kubernetes Pre-Launch Compliance Checklist

Before go-live for any PHI workload, verify and document these controls:

• RBAC configured with least-privilege roles for all service accounts
• MFA required for all human cluster access (kubectl, dashboard, CI/CD runners)
• etcd encryption enabled and verified for all Kubernetes Secrets
• All PersistentVolumes using encrypted storage classes with customer-managed keys
• Service mesh deployed with mTLS enforcement between all services in PHI namespaces
• HTTPS-only ingress with TLS 1.2+ enforced; TLS 1.0 and 1.1 disabled
• API server audit logging enabled, forwarding to SIEM, retained for 6 years minimum
• NetworkPolicies isolating PHI namespaces with default-deny ingress and egress posture
• Pod Security Standards (Restricted profile) applied to all PHI namespaces
• Business Associate Agreements (BAAs) signed with all cloud providers and vendors handling PHI

THNKBIG has implemented HIPAA-compliant Kubernetes architectures for healthcare technology firms, health systems, and digital health companies. Our team brings deep experience in both the technical implementation and the audit documentation required to satisfy healthcare compliance officers and external HIPAA auditors. Contact us to discuss your HIPAA Kubernetes architecture.

You can absolutely run PHI on Kubernetes, but you must layer in HIPAA-aligned controls across infrastructure, platform, and applications. Kubernetes is not HIPAA-compliant by default.

What You Need for HIPAA on Kubernetes

1. Encryption at Rest

• Enable etcd encryption for Kubernetes Secrets using AES-GCM-256.
• Use a KMS provider (AWS KMS, Azure Key Vault, GCP KMS) for key management; never store encryption keys in the cluster.
• Enforce encrypted persistent volumes via StorageClasses (e.g., AWS EBS encryption, Azure encrypted managed disks, GCP CMEK-backed disks).
• Ensure all PHI databases (managed or self-hosted) use storage-level encryption.

2. Encryption in Transit

• Use a service mesh (Istio, Linkerd) to enforce mTLS between all pods handling PHI.
• Prefer mesh-based mTLS over ad‑hoc application TLS; use both where possible.
• At ingress:
• Terminate TLS with valid certificates at the ingress controller.
• Use cert-manager (e.g., with Let’s Encrypt) for automated certificate issuance/renewal.
• Enforce TLS 1.2+ and explicitly disable TLS 1.0 and 1.1.

3. Access Controls

• Enable and strictly configure RBAC:
• Define least-privilege roles per workload and team.
• No cluster-admin for developers; use namespace-scoped permissions.
• Integrate Kubernetes with your IdP (AD, Okta, etc.) via OIDC; avoid shared credentials.
• Implement NetworkPolicies:
• Default-deny in PHI namespaces.
• Explicitly allow only required paths (e.g., app pods → PHI databases only).

4. Audit Logging

• Enable API server audit logging:
• Use RequestResponse or at least Metadata level for PHI namespaces.
• Capture who did what, when, and from where.
• Ship logs to immutable storage:
• Examples: S3 with Object Lock, Azure Blob immutable storage, GCS with retention locks.
• Retain logs for at least six years.
• Ensure application logs record PHI access events (user identity, resource, timestamp, action).

5. Cloud Provider BAAs

• Obtain a Business Associate Agreement (BAA) from your cloud provider before storing PHI.
• Use only HIPAA-eligible services covered by the BAA.
• Managed Kubernetes (EKS, AKS, GKE) is HIPAA-eligible when in-scope under the BAA.
• Maintain documentation of which services are in-scope vs out-of-scope for PHI.

Mapping to HIPAA Technical Safeguards

• Access Controls (164.312(a))
• Kubernetes RBAC with least-privilege roles and bindings.
• Scoped service accounts; no broad cluster-wide permissions.
• Audit Controls (164.312(b))
• API server audit logs at Metadata/RequestResponse level.
• Centralized, tamper-resistant log storage with long-term retention.
• Integrity Controls (implicit in 164.312)
• RBAC + NetworkPolicies + Pod Security Admission (or Pod Security Standards).
• Runtime security tools (e.g., Falco) to detect anomalous behavior and unauthorized changes.
• Encryption at Rest (164.312(a)(2)(iv))
• etcd encryption with AES-GCM-256.
• Encrypted node volumes and persistent volumes.
• Encryption in Transit (164.312(e))
• mTLS via service mesh between services.
• TLS at ingress and, ideally, at the application layer.

Evidence for Audits

Automate evidence collection so you can produce it on demand:

• Kubernetes audit logs showing access to PHI namespaces.
• RBAC exports (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings).
• Pod Security Admission / Pod Security Standards configurations and NetworkPolicy manifests.
• Runtime security logs (e.g., Falco) demonstrating policy enforcement.
• OPA/Gatekeeper or similar policy-as-code reports showing continuous compliance.

Timelines and Practical Notes

• Healthcare organizations in Texas and California typically reach HIPAA technical compliance on an existing Kubernetes cluster in 3–6 weeks.
• Most of the time is spent on documentation and audit logging gaps, not on basic control implementation.
• A reference architecture plus evidence templates significantly accelerates compliance.

Bottom Line

• Yes, you can run PHI on Kubernetes (EKS, AKS, GKE, or on-prem), but you must explicitly configure HIPAA-aligned controls.
• Focus on:
• Encryption at rest (etcd + volumes)
• Encryption in transit (mTLS + TLS)
• RBAC and network isolation
• Comprehensive, immutable audit logging
• With the right architecture and documentation, Kubernetes can meet HIPAA technical safeguard requirements for healthcare organizations in Texas, California, and beyond.