HIPAA Compliance on Kubernetes: A Technical Guide

Healthcare organizations want Kubernetes. HIPAA compliance teams are nervous. Can you run PHI on a container platform? Yes — with the right controls. Here's what you need.

HIPAA on Kubernetes: The Basics

HIPAA doesn't prescribe specific technologies — it requires safeguards for Protected Health Information (PHI). The key controls map to: access controls (who can access PHI), audit controls (logging access), integrity controls (preventing unauthorized modification), and transmission security (encryption in transit).

Kubernetes can satisfy all of these. It just requires explicit configuration — the defaults aren't HIPAA-compliant.

Encryption at Rest

PHI must be encrypted when stored. For Kubernetes Secrets containing sensitive data, enable encryption at rest on the etcd datastore. Use a KMS provider (AWS KMS, Azure Key Vault, GCP KMS) for key management — don't store encryption keys on the cluster itself.

Persistent volumes must use encrypted storage. On AWS, use EBS volumes with encryption enabled. On Azure, use encrypted managed disks. Database storage, whether managed services or self-hosted, needs encryption at the storage layer.

Encryption in Transit

All traffic carrying PHI must be encrypted. Service mesh (Istio, Linkerd) provides automatic mTLS between all pods — no application changes required. Without service mesh, applications need to implement TLS themselves.

Ingress must terminate TLS with valid certificates. Use cert-manager with Let's Encrypt for automatic certificate management. Ensure TLS 1.2 minimum — disable older protocols.

Access Controls

RBAC is mandatory. Define roles with minimum necessary permissions. No cluster-admin for developers. Namespace-scoped access where possible. Integrate with your identity provider (Active Directory, Okta) using OIDC — no shared credentials.

Network policies enforce pod-level access control. PHI databases should only accept connections from specific application pods. Default-deny policies in PHI namespaces, with explicit allows for legitimate traffic.

Audit Logging

HIPAA requires logging of PHI access. Enable Kubernetes audit logging with an appropriate policy — log all access to PHI namespaces at the RequestResponse level. Ship logs to immutable storage (S3 with Object Lock, Azure Blob with immutable storage).

Application-level logging matters too. Log who accessed what PHI and when. These logs support breach investigations and compliance audits. Retain for six years minimum.

Cloud Provider BAAs

Your cloud provider must sign a Business Associate Agreement (BAA) before you run PHI on their infrastructure. AWS, Azure, and GCP all offer BAAs — but you must request them and ensure you're using HIPAA-eligible services.

HIPAA compliance on Kubernetes is achievable. The key is explicit configuration — encryption, access controls, audit logging, and network segmentation. With proper controls, Kubernetes can host healthcare workloads that auditors will approve.

Key Takeaways

• HIPAA compliance on Kubernetes requires controls at the infrastructure, platform, and application layer — no single tool or configuration achieves compliance alone.
• Key technical controls include encryption at rest (etcd and persistent volumes), encryption in transit (mTLS between services), audit logging, and RBAC with least-privilege access.
• Healthcare organizations in Texas and California running Kubernetes on AWS EKS, Azure AKS, or on-premise clusters can achieve HIPAA compliance with the right architecture and documented evidence.

HIPAA Technical Safeguards in Kubernetes

HIPAA's Technical Safeguard requirements map directly to Kubernetes configuration decisions. Access controls require RBAC with role bindings scoped to specific namespaces and resources — no service account should have broader access than its workload requires. Audit controls require Kubernetes API server audit logging at the Metadata level for all requests, with logs shipped to a tamper-resistant destination and retained for the required period.

Encryption of PHI at rest requires etcd encryption using the AES-GCM-256 provider for Kubernetes Secrets, and StorageClass configuration that enforces encrypted persistent volumes. For managed Kubernetes (EKS, AKS, GKE), the control plane handles etcd encryption, but node-level volume encryption requires explicit configuration. Encryption in transit between services requires either TLS at the application layer or mTLS via a service mesh — preferably both.

Audit Logging and Evidence Collection

HIPAA audits require demonstrable evidence that controls exist and are enforced. Kubernetes audit logs, RBAC policy exports, Pod Security Admission configurations, and network policy manifests together form the technical evidence package. Automate evidence collection using OPA/Gatekeeper policy compliance reports and Falco runtime security audit logs.

Healthcare organizations we work with across Texas and California often discover that achieving HIPAA technical compliance on Kubernetes takes three to six weeks for an existing cluster — primarily because documenting existing controls and filling gaps in audit logging requires more effort than the controls themselves. THNKBIG's cybersecurity practice accelerates this process with a compliance-ready Kubernetes architecture and evidence documentation templates. Contact us.