Argo CD for healthcare

Start by classifying every cluster by the data it may hold, not by the team that uses it. The HIPAA Security Rule attaches to electronic protected health information (ePHI) wherever it is created, received, maintained or transmitted, so a test cluster that receives a copy of production records is in scope. Most healthcare platforms end up with three groups: production clusters that hold ePHI, non-production clusters that may contain only data that cannot identify a patient, and shared tooling such as the Argo CD control plane, monitoring and artifact storage.

• Production ePHI clusters: Any cluster that stores, processes or can reach patient records. Treat its Argo CD applications, credentials and logs as in scope.
• Non-production clusters: Test and development clusters that use synthetic or de-identified data. Write the data rule down, because engineers will otherwise copy records to reproduce a defect.
• Shared tooling: Components that serve every environment. Classify them at the level of the most sensitive cluster they can reach.
• Written data rules: Record which data sets may enter each environment and who approves an exception.
• Named ownership: Assign an owner to each cluster so that reclassification and access reviews have someone to answer to.

Check that each cluster has a named data classification and that the cluster inventory shows which group it belongs to.

An Argo CD AppProject is the boundary that defines which Git sources an application may use, which clusters it may deploy to and which Kubernetes resources it may create. Separate projects for production and non-production mean that a change approved for one environment cannot be synced into the other through a shared configuration. Projects are also where your access model for the environment is enforced.

• Separate projects by environment: Create one project for production patient-data workloads and another for non-production work. Use names that a reviewer can read in an audit log.
• Restrict source repositories: The sourceRepos field limits which repositories a project may read. Production projects should list only the repositories that hold reviewed production manifests.
• Limit cluster-scoped resources: Use clusterResourceWhitelist and namespaceResourceBlacklist to stop applications from creating cluster roles, admission webhooks or namespaces that the platform team did not approve.
• Scope RBAC to the project: In Argo CD 3.0 and later, update and delete permissions apply only to the application itself, so project policies need to grant those actions deliberately.
• Keep the default project empty: Make sure no patient-data application sits in the default project, which allows broad access unless you restrict it.

Check that every application names a project and that no production application appears under the default project.

Destinations tell a project which cluster and namespace it may deploy into. Correct Git content can still be applied to the wrong place when an Application manifest points at the wrong server or namespace, so the project should refuse that deployment before any resource is created. Destination rules are the technical control that keeps a non-production pipeline from writing into a production namespace.

• Server allowlist: Each entry in destinations should name the exact API server of the cluster the project may use. Avoid wildcards for production projects.
• Namespace patterns: Limit production destinations to the namespaces that hold patient-data workloads, and keep test namespaces out of those entries.
• Block cross-environment registration: Confirm that non-production users cannot register a production cluster, because a registered cluster can then appear as a destination.
• Paired repository paths: Map production repository paths to production clusters only, so the pairing is visible in review.
• Cluster credential handling: Argo CD redacts cluster credentials from API responses and logs, but anyone who can create or edit cluster secrets can change where the control plane can deploy. Restrict that permission to a small group.

Test the restriction by creating a deliberately wrong Application in a sandbox project and confirming that Argo CD rejects it.

Sync windows let an Argo CD project allow or deny automated sync during set periods. Healthcare organizations commonly freeze changes around month-end billing runs, accreditation surveys, public health campaigns or clinical system go-lives. A sync window turns that freeze into a control the platform enforces, not only a calendar entry that engineers are expected to respect. Confirm the window syntax and the behavior of manual sync against the documentation for your Argo CD version before you rely on it.

• Deny windows for freezes: Define deny windows on production projects for each documented freeze period, and record who approved each one.
• Allow windows for approved changes: Where production changes happen on a fixed schedule, allow sync only during that period and deny it at other times.
• Manual sync exceptions: Decide whether emergency manual sync is permitted during a deny window, who may use it and how the exception is recorded. Make the exception path part of the incident runbook.
• Time zone alignment: Set windows in the time zone of the team that approves and watches the change, and test the schedule around daylight saving transitions.
• Drift during freezes: A blocked sync does not correct configuration drift. Expect applications to show OutOfSync during a freeze and plan how those differences will be reviewed afterward.

Confirm that a sync attempted during a freeze is blocked in a non-production environment and that the blocked attempt appears in the logs your reviewers will read.

The Argo CD control plane holds the credentials and deployment permissions for every cluster it manages, so its location decides how far a compromise or outage can spread. Two patterns are common. A shared tooling cluster runs one instance that reaches production and non-production clusters, which centralizes RBAC and upgrades but places production credentials in one system. A dedicated instance inside the production boundary isolates production but adds an installation to operate and patch. Choose based on the network path each cluster can accept and the staffing you have to run each instance.

• Shared control plane: Protect it as a production system, because it can deploy to patient-data clusters. Restrict the network paths it uses and its administrative access.
• Dedicated production instance: Limits blast radius and keeps production RBAC separate, at the cost of separate upgrades and monitoring.
• High availability requirements: The HA manifests need at least three nodes because of pod anti-affinity rules, and IPv6-only clusters are not supported.
• Recovery dependencies: Argo CD keeps its data in Kubernetes objects and treats Redis as a disposable cache, so recovery depends on the Git repositories and the stored cluster objects. Back up and test restoring both.
• Identity and transport: Use SSO, disable the built-in admin user once SSO is configured, and confirm that TLS covers traffic between components.

Document the network path from the control plane to each cluster and confirm that no production cluster must accept inbound connections from non-production networks.