Which HIPAA technical safeguards Kubernetes helps you meet for ePHI
A covered entity or business associate running ePHI workloads on a self-managed Kubernetes cluster should first separate what the cluster can answer from what it cannot. The technical safeguards in 45 CFR 164.312 contain five standards: access control, audit controls, integrity, person or entity authentication, and transmission security. Together they carry seven implementation specifications. Two are required (unique user identification and the emergency access procedure) and five are addressable. The cluster configuration can support several of these standards directly, but it does not satisfy the Security Rule on its own. The wider rule covers 18 standards and 36 implementation specifications across administrative, physical and technical safeguards, and most of that work sits outside the cluster.
Access control is where the cluster does the most work. Kubernetes does not represent human users as API objects, so the authentication method you configure determines who can reach the API server. Connect the API server to your identity provider through OpenID Connect, then bind users and groups to namespace-scoped roles with least-privilege RBAC so that only staff with a documented need can read namespaces holding ePHI. Audit controls map to Kubernetes API audit logs. Write an audit policy that captures requests against Secrets and ePHI-bearing resources, and send those logs to storage your team controls. For encryption under 164.312(a)(2)(iv), which is addressable, configure encryption at rest for Secrets in etcd, since Secrets are stored unencrypted by default. For transmission security, use TLS between control plane components and at ingress.
Person or entity authentication and integrity are only partly a cluster matter. The cluster can require a verified identity from your OIDC provider, but the identity provider's own controls, including multi-factor authentication, must be confirmed in your environment. Integrity controls under 164.312(c)(1) protect ePHI from improper alteration or destruction. The cluster helps with restricted write access and with admission policies that accept only approved images, but database and application integrity checks belong to the workload design. Pod Security Standards set to Restricted in ePHI namespaces reduce what a compromised container can reach. Automatic logoff is an addressable specification that usually lives in application or identity provider session settings. Document the reasoning for every addressable specification you do not implement, as 164.306(d) requires.
Several requirements sit outside the cluster and need named owners. Risk analysis under 164.308(a)(1) comes first, because the cluster controls you choose should follow from an assessment of where ePHI flows. Policies and procedures, workforce security and training under 164.308(a)(3), physical safeguards under 164.310 for the data centers and hardware you control, and the business associate contracts required by 164.314(a)(2)(i) are organizational work. The emergency access procedure is a required specification, and for Kubernetes it means a documented break-glass process covering cluster-admin credentials and the identity provider. Decide who holds those credentials, how they are stored, and how each use is logged and reviewed. NIST SP 800-66 Rev. 2 gives sample questions for each standard and is useful as a working checklist.
There is no HIPAA certification. HHS has stated that no Security Rule standard requires an entity to certify compliance, and that private certifications do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Civil money penalties are inflation-adjusted, and for penalties assessed on or after January 28, 2026, the top tier is $2,190,294 per violation, with a matching calendar-year cap (45 CFR 102.3). DeployOpen prepares cluster configuration, documentation and evidence, such as audit policies, RBAC bindings and encryption settings. Independent assessors and OCR make the compliance judgment. HHS proposed a Security Rule revision on January 6, 2025, and no final rule had been published as of October 2026, so confirm which requirements apply before you finalize the design.
Mapping each technical safeguard to cluster capabilities and configuration
This table maps each HIPAA technical safeguard in scope to the Kubernetes capability that supports it and the configuration a cluster team must define. Addressable specifications are marked, and each one needs a documented decision on whether it is reasonable and appropriate for your environment, with an equivalent measure if it is not. Confirm exact option names against current Kubernetes documentation before you configure anything.
| Requirement | Kubernetes capability | Configuration needed |
|---|---|---|
| 164.312(a)(1) access control | RBAC roles, RoleBindings and ClusterRoleBindings | Grant least-privilege roles per namespace and team. Limit cluster-admin to a small named group. Review bindings on a set schedule. |
| Unique user identification (required) | Authentication by X.509 certificates, OIDC or other bearer tokens, webhook or authenticating proxy | Individual identities from your identity provider. No shared accounts or shared kubeconfig files. Confirm OIDC option names in current docs. |
| Automatic logoff (addressable) | Token lifetime and session expiry set by the identity provider and kubeconfig handling | Document the session and token lifetime decision. Set idle timeouts in the identity provider. Confirm token settings against current docs. |
| 164.312(a)(2)(iv) encryption and decryption (addressable) | Secrets encryption at rest through an encryption configuration on kube-apiserver | Enable encryption for Secrets in etcd and manage keys outside the cluster. Confirm provider options in current docs. Encrypt etcd snapshots and volumes too. |
| 164.312(b) audit controls (required) | API server audit logging with an audit policy and log backend | Write an audit policy covering ePHI namespaces. Ship logs off the control plane with retention and restricted access. Confirm policy fields in current docs. |
| 164.312(e)(1) transmission security (addressable integrity and encryption) | TLS on kube-apiserver, etcd and kubelet connections | Serve kube-apiserver over TLS behind the load balancer on port 6443. Plan certificate issuance and rotation. Confirm TLS option names in current docs. |
How RBAC and OIDC support access control and unique user identification
Kubernetes does not store normal users as API objects. It trusts whatever the configured authenticator asserts about a caller, using X.509 client certificates, bearer tokens (including OpenID Connect and JWT tokens), webhook token authentication or an authenticating proxy. For the unique user identification implementation specification, the design goal is that every person who touches an ePHI namespace authenticates as one identity that traces back to your central identity provider and its joiner, mover and leaver process. OIDC is usually the strongest fit because disabling a person in the directory stops new sign-ins, although tokens already issued stay valid until they expire, so keep token lifetimes short. Client certificates are harder to operate, since a certificate issued to a user cannot be revoked individually before it expires. Confirm which authentication options your distribution exposes, because packaged and managed clusters differ in what they allow.
Role-based access control is where the documented access grants become enforceable. Under 45 CFR 164.312(a)(1), only persons or software programs granted access rights under 164.308(a)(4) may reach ePHI, so the cluster role model should be a direct translation of the access matrix your organization has documented. Map each grant to a namespaced Role or a ClusterRole, then bind it to a group that the identity provider supplies. Bind people to groups, never to individual subjects one at a time. Reserve cluster-admin for break-glass use only. Pay particular attention to the Secrets resource: the list and watch verbs expose secret values in bulk, so grant them only where a documented need exists. Review bindings on a fixed schedule and compare them with the access register, because drift between the two is the gap an assessor is most likely to test.
RBAC governs what a user can ask the API server to do, but it does not govern what a workload can do once it runs. That is the job of Pod Security Admission, which enforces one of three Pod Security Standards (Privileged, Baseline or Restricted) on each namespace. A user who can create pods in an ePHI namespace could otherwise launch a privileged container that reaches node resources and, from there, data the RBAC model never intended to expose. Set the Restricted level on namespaces that hold ePHI wherever the workloads allow it. Use the warn and audit modes on the same namespace labels to find violations before enforcement blocks a deployment. Where a vendor chart requires Baseline or Privileged, record the exception, the namespace it covers and the reason, so the access model and the risk analysis describe the same cluster.
Every design above assumes the identity provider is reachable. Break-glass accounts cover the case where it is not, or where a privileged fix is needed during an incident. The emergency access procedure is a required implementation specification, so it needs its own written procedure, separate from the normal access process. Define who may invoke it, where the credential is stored and how that storage is sealed, and which alerts fire when it is used, using the API audit events described in the audit controls section. Reconcile each use to an incident or change record afterward, and rotate the credential after every use. Test the procedure on a schedule in a non-production cluster. Ask your privacy and security officers to approve the procedure in writing, and where the distribution allows, bind emergency access to named individuals so unique identification still holds during an emergency.
How to encrypt Secrets at rest and protect etcd backups
This sequence addresses the addressable encryption specification for Secrets and the etcd backups that can hold them. It ends with a documented decision for ePHI-bearing credentials, a scheduled etcd backup with protected snapshots, and a restore drill the compliance file can point to. The platform team leads the work, and the compliance lead approves the decision record.
Confirm Secrets are stored unencrypted in etcd
Start with a baseline. Kubernetes stores Secrets unencrypted in etcd by default, so the platform team creates a test Secret with a known value and reads the raw etcd key through a client that can reach the cluster's etcd endpoints. Confirm the value is readable, and record the Kubernetes version, the distribution, and the kube-apiserver configuration showing no encryption provider is set. Access to etcd sits outside Kubernetes RBAC, so also record which hosts and identities can reach it. The step is done when the baseline record shows the plaintext result and the security owner has reviewed it.
Configure encryption at rest for Secrets
The platform team writes an EncryptionConfiguration for the Secret resource and points kube-apiserver at it, using a key provider the organization controls. Confirm the setup steps and key handling with your distribution vendor, because the procedure differs between distributions. Existing Secrets stay unencrypted until they are rewritten, so the team rewrites them after the change and plans key rotation with the key owner. The step is done when a new test Secret reads back as encrypted in etcd and kube-apiserver restarts cleanly on every control plane node.
Restrict list and watch access to Secrets
Review every Role and ClusterRole that grants get, list or watch on Secrets. List and watch return full object contents, so grant them only to the controllers and people who need them, scoped to a namespace wherever possible. Bind grants to groups from the OIDC identity provider so that access removals flow from the identity system. The step is done when an access review lists which subjects can list or watch Secrets in each namespace that holds ePHI-bearing credentials, and each entry has a named owner.
Decide between etcd encryption and an external store
Compare two paths for ePHI-bearing credentials. The first keeps Secrets in Kubernetes with encryption at rest. The second keeps the value in an external store and mounts it into the pod at runtime through the Secrets Store CSI Driver. The external store is another system to secure, audit, back up and grant access to. Decide per credential class with the security owner and the workload team. The step is done when each credential class has a chosen path and its trade-offs are written into the decision record.
Document the addressable decision under 164.306(d)
Encryption and decryption under 164.312(a)(2)(iv) is an addressable implementation specification. Record the assessment of whether it is reasonable and appropriate for each Secret class, the decision taken, and any equivalent alternative measure, such as the external store path or tightly restricted etcd access, with the reasons it is reasonable. The compliance lead reviews the record and the risk owner signs it. The step is done when the record names the Secrets it covers and links to the configuration and access evidence from the earlier steps.
Set an etcd backup schedule and retention
Kubernetes documentation requires a backup plan for etcd data and uses etcdctl snapshot save to create snapshots. Run etcd with an odd number of members, and note that five members is the recommended production size, so quorum survives a member failure. Set the backup schedule and retention period with the operations owner, and write the procedure for running the snapshot on a control plane node with the correct client certificates. The step is done when snapshot files appear on schedule and the job raises an alert when it fails.
Protect snapshots as ePHI-adjacent data
Treat every etcd snapshot as ePHI-adjacent data, because it can contain Secrets. Whether those Secrets are readable depends on whether encryption at rest was configured before the snapshot was taken, so the team should not rely on that alone. Store snapshots encrypted in storage the organization controls, restrict who can read or copy them, log each access, and apply the same retention and access rules used for the ePHI workloads. The step is done when the storage policy, the access list and sample access logs are in the evidence file.
Test restores with etcdutl
Restores use etcdutl, so run a restore drill with etcdutl snapshot restore into an isolated environment. Confirm the cluster returns with the expected objects, and confirm that restored Secrets can be decrypted, which also requires the encryption key to be recoverable through its own controlled path. Record the snapshot used, the operator, the cluster version and the result. The step is done when a drill has passed and its record is stored with the compliance evidence set.
How API audit logs support audit controls under 164.312(b)
Section 164.312(b) requires hardware, software or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. On Kubernetes, the platform-side mechanism is API server audit logging, which records requests made to the control plane, including requests that read or change Secrets, Pods, ConfigMaps and RBAC bindings in namespaces that hold ePHI. The rule does not name a technology. The cluster supplies the recording, and your organization supplies the examination, the retention decision and the evidence that examination took place.
The first decisions are which requests and which resources to log. Logging every request at full detail produces large volumes and can capture sensitive request content, so the team should decide the audit level for each resource class, and confirm that Secret payloads are not written into the log. Scope the most detailed logging to ePHI namespaces, and keep cluster-wide logging for authentication events and changes to RBAC, admission configuration and namespace creation. Attribution matters as much as coverage. Kubernetes authenticates users through X.509 client certificates, bearer tokens including OpenID Connect, webhook token authentication or an authenticating proxy, so each entry is only as attributable as the identity source behind it. Confirm that your chosen method yields a unique identity per person and per service account.
Log shipping and retention are the next decisions. Audit entries should leave the cluster for a store that cluster administrators cannot quietly alter, so that the trail survives a compromised or misconfigured control plane. Retention is an organizational decision set by your HIPAA policies, legal counsel and any other obligations that apply to you. The supplied facts do not give a retention period, so ask your compliance lead for the requirement and do not infer one from tooling defaults. The audit policy syntax and backend settings also depend on the Kubernetes version you run. Confirm both against the Kubernetes documentation for that version before you write the configuration.
Review is the part auditors test most closely. Name the reviewers, the review frequency and the events they must examine, such as reads of ePHI-bearing Secrets, exec sessions into workloads that touch ePHI, RBAC changes and repeated failed authentication. Define how a suspicious entry is escalated and to whom. Record each review with a date, the reviewer, the scope, the findings and the follow-up actions, because a log that nobody reviews does not show that the mechanism examined activity. Logging is the platform part of the control. The review procedure, the reviewer assignments and the retention decision belong to your organization.
Before go-live, run a short check in a non-production cluster that uses the same audit configuration. Make a few test requests against a sample ePHI namespace, confirm the entries arrive in the external store with the expected identity, and confirm that a reviewer can search for them within the review workflow. Keep the test output with your control evidence. This check does not prove compliance on its own, but it shows whether the audit control works as your written procedure says it does.
What evidence the cluster produces and how to keep it
An assessor reviewing a HIPAA technical safeguard setup will ask to see configuration and logs that show access control, audit controls, encryption and transmission security were in place. The cluster produces much of this material, but each item has a different owner, change rate and storage location, and the cluster cannot supply the organization's own risk analysis or policies.
Identity provider and role bindings
Capture the API server authentication settings, including the OpenID Connect issuer, client and claim mappings, along with the RoleBinding and ClusterRoleBinding objects that grant access to ePHI namespaces. The platform or identity team produces these, and they change whenever a group, role or onboarding rule changes. Store them in version-controlled manifests and link each change to an approved access request so the assessor can trace who was granted what, and when. Kubernetes authenticates users outside the cluster, so confirm the identity provider's own records of user lifecycle are kept too.
Namespace and Pod Security Admission labels
Record which namespaces hold ePHI workloads and the Pod Security Admission labels that enforce a Pod Security Standard level on each one. The platform team sets these labels in namespace manifests, and they change only when a namespace is created or its enforcement level is reviewed. Keep the manifests in the same repository as the rest of the cluster configuration, and export a periodic report showing the live labels so drift from the stored state is visible. Assessors often ask why a namespace was exempted, so keep the written justification with the manifest.
Secrets encryption configuration and proof
Kubernetes stores Secrets unencrypted in etcd by default, so the encryption configuration file for kube-apiserver is central evidence for the encryption specification. Keep that file, the identity of the key provider, and the key rotation procedure in version control with restricted write access. Proof that encryption is active needs a dated check, such as reading a test Secret directly from etcd and confirming it is not stored as plain text. Repeat that check after each control plane change and after each key rotation, and file the output with the change ticket.
API audit policy and sample log records
The audit policy defines which API requests the kube-apiserver records and at what detail level, and it is the main artifact behind the audit controls standard. The platform team owns the policy file, which changes rarely but must be reviewed whenever logging scope changes. Keep the policy in version control, and archive audit logs to a separate log store with defined retention. Pull a small set of sample records for create, update and delete events on ePHI namespaces, then confirm they carry the user, timestamp and object reference an examiner would need.
TLS configuration for kube-apiserver and ingress
List the TLS settings that protect ePHI in transit between clients, the kube-apiserver, the kubelets and the ingress layer, including certificate issuers, minimum protocol versions and cipher configuration. The platform team owns these settings, and certificates renew on their own schedule, so track expiry dates in a monitored inventory. Store the certificate policy and ingress manifests in version control, and keep scan results from a TLS test against each external endpoint. Confirm with the ingress and certificate vendors which protocol versions and ciphers their current releases accept by default.
etcd backup and restore records
Backups of etcd hold the cluster state, including any Secrets not yet protected by encryption at rest, so their handling is part of the safeguard evidence. The operations team produces snapshot records on the schedule set in the backup plan, and restore test records whenever the team rehearses a recovery. Store snapshots in an encrypted, access-controlled location separate from the cluster, and keep a log of each snapshot's time, size, checksum and location. Kubernetes documentation uses etcdctl snapshot save for backups and etcdutl for restores, so record which tool version produced each snapshot.
TLS for ePHI in transit inside and around the cluster
Section 164.312(e)(1) requires technical security measures that guard against unauthorized access to ePHI transmitted over an electronic communications network. Its two implementation specifications, integrity controls and encryption, are both addressable, so you must assess each one, implement it if it is reasonable and appropriate, and otherwise document why and adopt an equivalent measure. In a Kubernetes platform, the first transmission point is kube-apiserver. The kubeadm high availability guide describes at least three control plane nodes with a TCP load balancer in front of kube-apiserver on port 6443. A TCP load balancer forwards the connection without reading it, so confirm that the TLS session runs end to end to each API server and that the serving certificates match the names clients, operators and kubelets use. Record that verification in your risk analysis.
The etcd topology also determines what must be encrypted. The kubeadm guide describes stacked etcd, where etcd members run on the control plane nodes, and external etcd, where a separate cluster serves the API servers. Stacked etcd uses fewer machines and keeps each member beside its API server, but a single node failure removes both roles at once. External etcd adds hosts and separates failure domains, and it adds another set of client and peer connections to secure and rotate. etcd holds cluster state, including Secrets, so its client and peer traffic needs TLS in either design. The etcd documentation expects an odd member count and recommends five members in production. Confirm that your installer generates and rotates these certificates, and name the person or team that owns that rotation.
Client traffic that carries ePHI usually reaches the cluster through an ingress controller or gateway, and its TLS configuration is one of the first things an assessor will ask about. Confirm which controller you run, where its certificates come from, which TLS protocol versions it accepts, and whether it re-encrypts traffic toward pods or sends it in clear text inside the cluster. Whether in-cluster traffic is encrypted by default depends on your distribution and on what you install, and service-to-service encryption depends on how you configure it. Confirm both points with your distribution documentation, your ingress controller documentation and, if you run one, your service mesh. Then map every hop that carries ePHI, including ingress to pod, application to database, and workloads to logging and backup targets, and mark each hop as encrypted, excluded with a documented reason, or still open.
Transmission to outside parties is a separate control question. When ePHI leaves your environment for a business associate, clearinghouse, laboratory or payer, cluster TLS settings do not govern that exchange. Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. Review those contract terms against the actual transfer methods, endpoints and protocols, and confirm which party holds the certificates and keys on each side of the connection. If a partner operates or accesses the cluster, the contract should also state who manages that connection and its certificates.
What Kubernetes leaves to the covered entity
Kubernetes supports some technical safeguards in 45 CFR 164.312, but the Security Rule assigns the rest of the program to the covered entity and its business associates. The cards list the work that stays with your organization. Kubernetes does not provide a HIPAA certification, and HITRUST is a separate third-party program that you would choose and assess on its own terms.
Risk analysis of ePHI systems
The Security Rule requires an assessment of risks to ePHI across every system that creates, receives, maintains or transmits it. The cluster is one component. The analysis must also cover the image registry, CI pipelines, backup targets, log sinks and administrator workstations that touch the workloads. Use HHS OCR's guidance on risk analysis as the reference for method and scope. The 2025 proposed Security Rule revision (90 FR 898) has no final rule as of October 2026, and the Unified Agenda projects final action for July 2027, so track it and reassess your analysis when it changes.
Written policies and workforce procedures
RBAC and audit settings only enforce what someone has decided. Your written policies must cover access granting and removal, role design, secret handling, change control for cluster configuration and incident response. Workforce procedures define who may run kubectl against production, how administrator access is reviewed, and what happens when a person changes roles or leaves. Check that each procedure names an owner and matches what the cluster actually does, because reviewers compare documentation with configuration and logs.
Business associate contracts
A hosting provider, managed Kubernetes service, backup vendor or support firm that can reach ePHI is generally a business associate. Under 45 CFR 164.314(a)(2)(i), the contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. Confirm the provider will sign terms on those points before you place workloads with it. Vendors that see ePHI during troubleshooting also need contracts, even when the cluster runs in your own data center.
Physical safeguards for hardware
Cluster controls depend on the hardware underneath being controlled. The physical standards in 45 CFR 164.310 cover facility access, workstation use and the handling of devices and media. For a self-hosted cluster, that means controlling physical access to the data center or colocation space, to control plane and worker hardware, and to disks that hold etcd data, persistent volumes and backups. Plan how drives and decommissioned nodes are wiped, reused or destroyed. Ask your facility provider which physical controls it documents and whether it can supply them for your assessment.
Emergency access and automatic logoff
On-call staff who reach the cluster through a dashboard, a bastion host or a web console need controls of their own. Emergency access procedure is a required implementation specification in the technical safeguards, so document how a break-glass identity is granted, logged and revoked. Automatic logoff is addressable, so decide session timeouts for identity provider sessions, dashboards and kubectl contexts, and record the decision. Kubeconfig files with client certificates or long-lived tokens may not expire on their own unless you set a limit.
Decision record for addressable specifications
Under 45 CFR 164.306(d), each addressable specification requires an assessment of whether it is reasonable and appropriate. If it is not, you must document why and implement an equivalent alternative measure where that is reasonable and appropriate. In this topic, the encryption and decryption mechanism in 164.312(a)(2)(iv), automatic logoff, integrity controls and transmission encryption are all addressable. Keep one dated record per decision that states the risk, the reasoning, the chosen control and the review date. Reviewers often ask for this record first when a control appears to be missing.
Configuration sequence to run before an assessment
This sequence takes an ePHI cluster from an unscoped build to a state where each HIPAA technical safeguard has a configured control, a recorded decision and evidence an assessor can inspect. Run the steps in order, because later controls depend on the namespaces, identities and risk decisions set earlier. The output is a documented baseline that an independent assessor can review.
Scope ePHI workloads, namespaces and the version plan
Identify every workload, namespace, node pool and data store that creates, receives, maintains or transmits ePHI, and record which ones share the cluster with non-ePHI services. Platform engineering and application owners do this together, with compliance input on what counts as ePHI. Confirm the Kubernetes minor version, since the project maintains only the three most recent minor releases, and write down the upgrade order the version skew policy requires: kube-apiserver first, then kube-controller-manager and kube-scheduler, then kubelets. Done when the scope list names every ePHI namespace and the version path is approved by the platform owner.
Update the risk analysis for the cluster
Review the entity's existing risk analysis and add the cluster as an information system that holds or moves ePHI. Cover the control plane, etcd, worker nodes, image registry, CI/CD path and ingress. Record threats such as stolen kubeconfig credentials, a compromised pod reading Secrets, and unencrypted traffic between services. Link each threat to a risk management decision and the control that addresses it. The security official and system owners sign off on the update. Done when every cluster component appears in the analysis with a rating, an owner and a linked decision.
Set the identity provider and RBAC model
Connect the API server to your identity provider using OpenID Connect so people sign in with their workforce identities, and map group claims to Kubernetes roles. Kubernetes does not store user objects, so the identity provider is the source of truth for who is a user. Define roles by job function, bind them per namespace, and remove default bindings you do not need. Restrict list and watch access on Secrets to the smallest group possible. Require a unique account for every person and avoid shared kubeconfig files. Done when a review of all role bindings matches the access model approved in the risk analysis.
Apply Pod Security Admission labels per namespace
Label each ePHI namespace with a Pod Security Admission enforce level, typically Restricted where workloads allow it and Baseline where a workload needs more. Set the warn and audit labels to the same or a stricter level so violations stay visible. Privileged should not be the default for any ePHI namespace. Application teams confirm their pods run as non-root and do not use host namespaces, and the platform team checks that the labels appear in manifests stored in version control. Done when a server-side dry run of each workload succeeds and the admission warnings have been reviewed and resolved.
Configure Secrets encryption and etcd backups
Enable encryption at rest for Secrets in the API server configuration, using an encryption provider with a key that is held outside etcd. Rewrite existing Secrets so they are stored encrypted, and document the key rotation procedure. Set up etcd snapshots with etcdctl snapshot save on a schedule, store them encrypted in a separate location, and run the cluster with an odd number of etcd members, with five recommended in production. Test a restore with etcdutl in a non-production cluster. If you use an external secrets store through the Secrets Store CSI Driver, record that choice in the risk analysis. Done when a restore test recovers the cluster state and a check of etcd confirms Secrets are stored encrypted.
Enable API audit logging and set retention
Write an audit policy for kube-apiserver that records access to Secrets, RBAC objects, workloads and authentication events at a level suited to ePHI access review. Keep Secret contents out of the audit log while still recording who requested them. Ship logs to a store that cluster administrators cannot quietly alter. Ask your compliance lead to confirm the retention period, since it should follow your own documentation policy and any applicable legal requirements. Test by reading a test Secret and finding that event in the log store with the user identity attached. Done when the test event is retrievable, the audit policy is stored in version control and the retention setting is recorded.
Configure TLS on the control plane and ingress
Issue certificates for kube-apiserver, etcd peer and client traffic, kubelet connections and the ingress controller, using an internal certificate authority or a service you control. In a high availability topology, place a TCP load balancer in front of kube-apiserver on port 6443. Terminate ingress with TLS that meets your organization's approved protocol and cipher policy. Confirm that pod-to-pod traffic carrying ePHI is either encrypted or confined by network policies that the risk analysis accepts. Done when a scan of each endpoint shows the expected protocol and certificate chain, and control plane components verify each other's certificates.
Document addressable decisions and assemble evidence
For each addressable specification, record whether it is reasonable and appropriate for your environment, the chosen implementation, and for any measure not implemented, the reason and the equivalent alternative. Map each control to its configuration file, command output or screenshot, and an accountable owner. Gather the role bindings, Pod Security labels, encryption check, backup restore record, audit policy and sample audit events into one evidence pack. After every upgrade, rerun these checks, because an upgrade can change how these controls behave. Done when every control in the pack has an owner, a verification record and steps an independent assessor can reproduce.
Questions buyers ask about HIPAA and Kubernetes
Does running Kubernetes make us HIPAA compliant?
No. Running Kubernetes does not make an organization HIPAA compliant, and no product can. The Security Rule has no certification, and HHS states that no standard requires an entity to certify compliance. HHS also does not endorse or recognize private certifications, and those certifications do not stop HHS from later finding a violation. Compliance covers your whole program: the risk analysis, policies, workforce training, business associate contracts under 45 CFR 164.314 and the technical controls on the cluster. A well-configured cluster can support the technical safeguards in 45 CFR 164.312, but the evidence for each addressable decision has to come from your organization. If a vendor or partner claims a Kubernetes HIPAA certification, ask them to show the HHS source for it.
What drives the cost of HIPAA safeguards work on Kubernetes?
The main drivers are the size and shape of the written scope. Count the ePHI workloads and the clusters that host them, and note whether you already run an identity provider that can issue OIDC tokens to the API server. Logging and retention targets set how much audit data flows to storage and how long it stays there. Each addressable implementation specification adds analysis, because your organization must document whether it is reasonable and appropriate and, if it is not, document and implement an equivalent alternative. Evidence depth matters as well: a policy-level mapping takes less effort than tested configurations with captured proof. Design, build, hardening and documentation are one-time work, while log storage, certificate rotation, upgrades and periodic review recur. DeployOpen does not publish prices. Ask for a written quote that lists each driver, who performs each task and which items recur.
How long does a HIPAA technical safeguards project on Kubernetes take?
Duration depends on the written scope, and no general figure applies. A project covering one ePHI workload with an existing identity provider and simple logging follows a different path than one covering several clusters, multiple tenants, custom retention rules and external evidence requirements. A useful schedule lists phases: discovery of current controls, design of identity and audit logging, build, verification and handover of documentation. Ask which dependencies set the pace, such as access to environments, identity provider changes, approvals from your security reviewer and change windows for production clusters. Ask also which phases depend on your risk analysis being finished first. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the proposal should name the milestones it commits to and the inputs it assumes from your team.
What does our team need to provide for this work?
Four roles from your organization keep the work moving. A risk analysis owner connects the Kubernetes design to your enterprise risk analysis, because that analysis is yours to perform and keep current. An identity administrator manages the directory, group membership and the OIDC client that the API server will trust. A security reviewer checks design decisions, especially each addressable specification and any alternative measure you choose. Someone must also grant access to the environment, whether that is cloud accounts, data center hosts or an air-gapped network, along with read access to current configuration and audit logs. Name these people in the scope before kickoff. Confirm who fills each role and how much time they can give each week, because the schedule depends on those inputs.
Can our own team implement these HIPAA safeguards on Kubernetes alone?
Yes, an experienced internal team can implement the technical safeguards alone, using HHS guidance and NIST SP 800-66 Rev. 2. Published in February 2024, that NIST resource guide gives key activities, descriptions and sample questions for every Security Rule standard. HHS lists it as informational, and it is not legally binding, so use it as method guidance adapted to your environment. Your team would still need Kubernetes skills in RBAC, API audit policy, Secrets encryption and TLS, plus time for testing and documentation. Policy, workforce training, business associate agreements and the risk analysis stay with the organization whether or not a partner helps. A partner can take on design, build, hardening and evidence preparation within a written scope, while your staff owns decisions and approvals. Choose based on the skills you have and your deadlines, and confirm the division of responsibilities before work starts.
Which HIPAA technical safeguards apply to Kubernetes workloads?
Four of the five standards in 45 CFR 164.312 map most directly to a cluster. Access control under 164.312(a)(1) requires that only persons or software programs granted access rights can reach ePHI, which points to RBAC, OIDC-backed authentication and namespace boundaries. The encryption and decryption mechanism in 164.312(a)(2)(iv) covers Secrets at rest and the data stores behind the cluster. Audit controls under 164.312(b) call for mechanisms that record and examine activity, which in practice means API server audit policy shipped to retained storage. Transmission security under 164.312(e)(1) guards ePHI in transit, so TLS for the API server, ingress and service-to-service traffic needs a design and a verification step. Unique user identification and automatic logoff also map to identity and session settings. Confirm this mapping against your risk analysis before you assign controls to workloads.
Must we encrypt Kubernetes Secrets at rest for HIPAA?
The encryption specification is addressable, so you must decide whether it is reasonable and appropriate, document that decision, and implement it or an equivalent alternative. Kubernetes stores Secrets unencrypted in etcd by default, so the decision has to be made on purpose. Configuring encryption at rest for the API server is one route, and etcd snapshots then hold encrypted values. Access to Secrets also needs least-privilege RBAC, especially list and watch permissions, which can expose values even when storage is encrypted. Teams that use an external store through the Secrets Store CSI Driver move key handling elsewhere, and that setup needs its own review. Whatever you choose, record the reasoning in your risk analysis and test that a raw read from etcd returns ciphertext. Treat the key management path as part of the ePHI system.
Will the HIPAA Security Rule change before we finish?
HHS proposed a major Security Rule revision on January 6, 2025, and no final rule had been published as of October 2026. The proposal appears at 90 FR 898 under RIN 0945-AA22, with comments due March 7, 2025. The latest Unified Agenda lists it under Long-Term Actions and projects final action for July 2027. Plan your first delivery against the current rule, and record which design decisions would need to change if the final rule differs from the proposal. Check the Federal Register and reginfo.gov for the current status before you sign a scope, because projected dates move. Ask your partner to flag in the written scope which controls depend on documentation or policy choices that a final rule could alter.
How DeployOpen scopes HIPAA-ready Kubernetes configuration and evidence
DeployOpen plans, builds and documents self-hosted Kubernetes clusters inside your own cloud accounts, data centers or air-gapped networks. For HIPAA technical safeguards, we prepare the access control, audit logging, Secrets encryption and TLS configuration, along with the evidence that shows how each one works. Independent assessors reach any conclusions about compliance.
How we scope
- The written scope lists which namespaces, ePHI workloads and cluster components fall inside the HIPAA technical safeguards work.
- Scoping maps each access, audit, encryption and transmission control to the cluster setting that implements it.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Build a cluster with a chosen distribution, a high availability control plane and etcd members in an odd-numbered quorum.
- Configure OIDC authentication and least-privilege RBAC so each ePHI namespace grants access only to approved roles.
- Enable encryption at rest for Secrets, enforce Pod Security Standards and terminate TLS for every ePHI data path.
How we hand over
- Deliver API audit log policy, retention settings and sample queries that show who accessed ePHI workloads.
- Document each control, its owner, configuration source and the evidence an assessor would request.
- Provide etcd snapshot and restore runbooks, with a documented plan for the Secrets encryption key.
How we support
- Ongoing support, Kubernetes upgrades and recurring testing are available as retainers agreed separately from the build.
- Upgrade plans cover each minor version step, with the API server upgraded before kubelets.
- Configuration changes to RBAC, audit policy and encryption settings are re-reviewed whenever the scope changes.
Sources and further reading
- 45 CFR 164.312, Technical safeguards, eCFR ↗
- Appendix A to Subpart C of Part 164, Security Standards: Matrix, eCFR ↗
- NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule ↗
- Kubernetes good practices for Secrets ↗
- Kubernetes authentication ↗
- HHS FAQ 2003: Are we required to certify our organization's compliance with the standards? ↗
