Running healthcare workloads on Kubernetes requires deliberate configuration against HIPAA's Technical Safeguards (45 CFR §164.312). A default Kubernetes cluster — installed with kubeadm defaults, unmodified pod security settings, and default RBAC — fails multiple Technical Safeguard requirements. The configuration delta between default and HIPAA-eligible is well-defined by the CIS Kubernetes Benchmark (currently v1.8.0 for Kubernetes 1.29), NIST SP 800-190 (Application Container Security Guide), and OCR guidance on cloud-native healthcare systems. The following is not a survey of options — it is the specific configuration that passes OCR examination.
Pod Security Standards
Kubernetes Pod Security Standards replaced Pod Security Policies (deprecated in 1.21, removed in 1.25) as the mechanism for enforcing pod-level security constraints. For HIPAA workloads, the Restricted profile is the minimum: it requires running as non-root, dropping all Linux capabilities, disabling privilege escalation, and using a seccomp profile. The enforcement point is the admission controller — configure the pod-security admission controller with enforce: restricted on all namespaces that process PHI. Namespaces that do not process PHI can use baseline or privileged enforcement, but PHI namespace isolation requires Restricted enforcement.
The specific pod spec requirements for HIPAA workloads: securityContext.runAsNonRoot: true; securityContext.allowPrivilegeEscalation: false; securityContext.capabilities.drop: [ALL]; securityContext.seccompProfile.type: RuntimeDefault or Localhost. These settings map to CIS Benchmark recommendations 5.2.2 through 5.2.9. Document the mapping explicitly — OCR auditors will ask for the mapping between your Kubernetes configuration and the HIPAA Security Rule control it satisfies.
The CIS Kubernetes Benchmark Level 2 recommendations are the appropriate baseline for HIPAA workloads. Level 1 is appropriate for general production hardening. For PHI processing, Level 2 adds etcd encryption configuration, API server audit logging, and admission controller hardening that are required for HIPAA Technical Safeguards compliance.
Network Policies for PHI Namespace Isolation
HIPAA's access control requirement (§164.312(a)(1)) includes technical policies and procedures for electronic information systems that contain PHI to allow access only to authorized persons or software. Kubernetes default network policy allows all pod-to-pod communication within a cluster. For HIPAA, PHI namespaces must have explicit NetworkPolicy resources that allow only required ingress and egress. The default-deny pattern: create a NetworkPolicy that selects all pods in the PHI namespace with an empty podSelector and empty ingress/egress rules (denying all traffic), then add specific allow rules for required communication paths (app tier to database, app tier to audit log sink). Use Calico or Cilium as the CNI — both support full NetworkPolicy enforcement; the default kube-proxy-based networking does not enforce NetworkPolicy.
HashiCorp Vault Integration for Secrets Management
Kubernetes Secrets are base64-encoded, not encrypted, by default. etcd encryption at rest (NIST SP 800-111) addresses the storage encryption requirement, but Kubernetes Secrets are still accessible to any pod with the correct RBAC permissions. For HIPAA workloads, use HashiCorp Vault (or AWS Secrets Manager with the External Secrets Operator) to inject secrets at pod startup via the Vault Agent Sidecar Injector. Secrets are never stored in Kubernetes etcd — they are fetched from Vault at runtime and held in memory in the pod. Vault provides access logging (satisfying §164.312(b) audit controls), dynamic secrets with automatic rotation (satisfying §164.312(a)(2)(iv) encryption/decryption mechanisms), and policy-based access control that maps to HIPAA minimum necessary.
Audit Log Configuration for §164.312(b)
- Configure the Kubernetes API server audit policy (--audit-policy-file) to log at RequestResponse level for all requests to PHI-related resources — the default None policy produces no audit logs
- Route audit logs to an immutable sink outside the cluster — an S3 bucket with Object Lock, Azure Immutable Blob, or Google Cloud Storage with bucket lock — not to cluster-local storage
- Configure retention to satisfy HIPAA's 6-year documentation requirement (§164.530(j)) — most default log retention configurations are 30-90 days
- Enable Falco for runtime behavioral audit logging — Kubernetes API server logs show API calls; Falco logs actual process execution, file access, and network activity within pods, which is the access record HIPAA requires
- Configure node-level audit logging via auditd — systemd journal logs are not sufficient for HIPAA; auditd with rules targeting file access to PHI data directories provides the host-level audit trail
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.