Argo CD security hardening guide

Argo CD security hardening: what to lock down before the first sync

Argo CD needs to be hardened before its first sync because it will hold deploy rights to your production clusters. Its own configuration becomes part of your attack surface. Hardening covers seven controls that the platform team should plan together: project boundaries, least-privilege RBAC and cluster roles, repository allow-lists, repo-server limits, Redis TLS, secrets handling, and audit through Kubernetes events. Each control limits what a compromised user, repository or component could do with the deploy rights Argo CD already has.

The default install does not give you these limits, and hardening is harder than the quick start suggests. The repo-server runs Helm and Kustomize on repository content, so an untrusted repository or a template that reads files outside its path is a risk you must control. The built-in admin user is also enabled until someone turns it off, using the admin.enabled setting. RBAC and tracking behavior also changed between 2.14 and 3.0. Update and delete permissions now apply only to the application itself, log access needs an explicit logs, get permission, and annotation-based resource tracking is the default. Policies copied from an older instance may grant too little or too much, so test them against the upgrade notes for your version.

The controls depend on one another, which is why they should be designed in one pass. Project boundaries determine which namespaces and clusters a role can target, so RBAC and project design must be settled together. Repository allow-lists only work once repositories are defined as Kubernetes Secrets, because Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap. Secrets handling and repository definitions therefore change at the same time. Repo-server limits and allow-lists constrain what rendering can reach, so they belong in the same review. Redis is a disposable cache, so Redis TLS protects traffic and access rather than recovered data. Confirm the TLS setup for your Argo CD version before you rely on it.

Before the first sync, decide who may hold administrative access, disable the admin user once SSO or local users work, and name an owner for the repository allow-list. Record each decision in writing. Argo CD authenticates API requests only with JSON Web Tokens, uses TLS between its components, and redacts cluster, Git and OAuth2 credentials from responses and logs. Treat these as built-in properties to verify in your environment, not as settings you can skip. Confirm which Kubernetes events your cluster retains and forwards, because audit depends on them. When you ask a partner for a fixed-scope quote, ask for each control to appear in the scope with a named verification step.

Which Argo CD components carry the security boundary

Argo CD's security boundary is set by a small group of objects and components, and each one controls a different part of what gets deployed, from which sources, to which clusters, and with which credentials. The RBAC policy decides who can act, AppProjects decide what an application may pull and deploy, and the remaining components carry out those decisions with the access you grant them. Redis is left out because it holds only disposable cache data.

AppProjects set deployment boundaries

AppProjects are the main deployment boundary inside Argo CD. They define which source repositories an application may pull from, which destination clusters and namespaces it may deploy to, and which Kubernetes resource kinds it may create. Check that no project is left with broad permissions by default, and that each team's applications belong only to projects that match its repositories and namespaces. Test a deliberately out-of-bounds application to confirm the project rejects it.

RBAC policy governs user actions

The RBAC policy maps users and groups to what they may do with applications, projects and other Argo CD objects. Since the 2.14 to 3.0 upgrade, update and delete permissions apply only to the application itself, and reading logs requires an explicit logs, get permission. Review the policy after every upgrade, and confirm that group names from your identity provider match the claim that Dex-based RBAC now reads, federated_claims.user_id. The policy does not limit what deployed workloads can do inside the cluster.

Repository Secrets hold Git access

Since Argo CD 3.0, repository definitions are stored as Kubernetes Secrets instead of entries in the argocd-cm ConfigMap. Whoever can read those Secrets can see the repository credentials they contain, so Kubernetes RBAC on the Argo CD namespace is the control that matters here. Check who can get or list these Secrets, use the narrowest Git credentials each repository allows, and keep the set of defined repositories aligned with the source repositories each AppProject permits.

Repo-server runs repository content

The repo-server renders manifests by running Helm and Kustomize against repository content. Anyone who can change a repository Argo CD reads can influence what runs there, so untrusted repositories and out-of-tree file references are the risks to control. The repo-server does not decide what is allowed to deploy, since AppProjects and RBAC handle that. Confirm which repositories it can reach, keep its traffic on TLS, and review the resource requests and limits set for it in your manifests.

Application controller applies cluster changes

The application controller compares live cluster state with Git and applies changes to destination clusters using the credentials it holds for them. It is the component that turns a permitted project into real changes, so the clusters and namespaces it can write to define your blast radius. It can be sharded across replicas for scale, but sharding spreads the work without narrowing what each replica can reach. Review which cluster credentials it holds before onboarding each cluster.

Kubernetes RBAC limits cluster credentials

The cluster credentials Argo CD uses are only as narrow as the Kubernetes RBAC granted to them. Argo CD redacts cluster credentials from API responses and logs, but redaction does not limit what a credential can do. Scope each cluster identity to the namespaces and resource kinds its projects allow, and avoid cluster-admin where a namespaced role is enough. Verify with a test that each identity cannot write outside its target namespaces.

Argo CD security hardening decisions and their operational trade-offs

This table compares the main hardening choices for Argo CD, from project layout and instance scope to repository allow-lists, Application creation rights, cluster role scope and disabling the admin user. Each row shows when an option fits and what it costs to run day to day, so teams can weigh tighter control against review workload and onboarding speed. The main takeaway is that stricter boundaries usually add review effort and a written break-glass procedure, and that choice should follow the number of teams and clusters involved.

Decision	Option that fits	Day-to-day cost	When to choose the other option
Project layout	Per-team AppProjects that limit destinations, source repositories and resource kinds for each team	More projects to review and keep in step with team changes, and a longer path when a team needs a new destination	A single shared AppProject fits a small platform team with few environments, where one review owner can keep up with all changes
Instance scope	Namespace-scoped Argo CD instances for teams that must not see or touch other tenants' Applications	Several control planes to upgrade, back up, monitor and patch on the release cadence	A cluster-scoped instance fits one platform team that manages shared clusters and wants a single place for access and audit
Repository sources	Explicit allow-list of repository URLs in each AppProject	Each new repository needs a reviewed change before teams can deploy from it, which slows onboarding	Allowing all repositories fits a sandbox or a trusted internal monorepo, but it leaves the repo-server running Helm and Kustomize on content nobody has reviewed
Application creation	Application creation restricted to the platform team, with teams changing manifests through Git	Platform engineers handle requests, so queues can form during busy release periods	Letting application teams create Applications themselves fits mature teams with per-project RBAC and tested guardrails in their AppProject
Cluster role scope	Argo CD roles limited to the namespaces and resource kinds each AppProject needs, with the controller's cluster permissions reviewed	More role tuning and testing after each new resource kind, and some deployments fail until permissions are added	Broader cluster roles fit early pilots or clusters where Argo CD must manage many resource types, but they widen the blast radius of a compromised controller
Admin user	Set admin.enabled to false after local users or SSO are working and tested	Break-glass access needs a written, tested procedure and a named owner, or an outage can leave no way in	Keeping admin enabled fits a first install or a lab, and it should be time-limited and documented in the install record
Break-glass procedure	Written steps for regaining access through an approved identity path, tested before admin is disabled	Reviewing and rehearsing the procedure on a schedule, and updating it after identity provider changes	Skipping a written procedure is only sensible when the team can rebuild access quickly from configuration in version control

Argo CD security hardening sequence, step by step

This sequence moves an Argo CD instance from default settings to one where each team deploys only from approved repositories to approved clusters, with access, credentials and audit checked along the way. Each step closes with a test that proves the control works before the next step begins.

Inventory repositories, clusters and access paths
The platform team lists every Git repository Argo CD will read, every destination cluster and namespace, and every person or group that will create or sync applications. Record which repositories contain Helm charts or Kustomize overlays, because the repo-server runs those tools on repository content and those inputs need the closest review. The step is done when application owners have reviewed the list. Closing check: compare the inventory against the live Applications and confirm each one maps to a known repository and cluster.
Define AppProjects with source and destination allow-lists
Create one AppProject per team or trust boundary. Each project lists the repository URLs it may pull from and the clusters and namespaces it may deploy to, and cluster-scoped resource kinds stay out of the allowances unless a named owner needs them. Assign every Application to its project before any automated sync is enabled. Closing check: create a test Application in one project that points to a repository outside its source list, and confirm Argo CD refuses the sync with a permission error and no resources change.
Move repository definitions into Kubernetes Secrets
Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap, so each repository and its credentials must be defined as a Kubernetes Secret in the Argo CD namespace. Use deploy keys or short-lived tokens where the Git host supports them, and limit who can read or change those Secrets with Kubernetes RBAC. Read the upgrade notes for your exact version before migrating. Closing check: confirm each repository connects in the UI or CLI, and confirm the argocd-cm ConfigMap holds no repository entries.
Write least-privilege RBAC for applications and logs
Write Argo CD RBAC policies that grant each role only the actions it needs within its project. Since the 2.14 to 3.0 change, update and delete permissions apply only to the Application itself, so policies must be tested against that behavior. Log access requires an explicit logs, get permission, which should be granted only to roles that need it. Closing check: sign in as a user in a read-only group and attempt a sync, a delete and a log view in one project. Confirm each action is denied and that status reads succeed in the allowed project.
Confirm the federated_claims.user_id mapping for Dex
If you use Dex-based RBAC, confirm that role mappings reference the federated_claims.user_id claim, which the 3.0 upgrade notes say Dex-based RBAC now uses. Test with one account from each connector you plan to use, such as SAML, LDAP or GitHub. If you connect to an OIDC provider directly, check the claims your provider sends and how Argo CD maps them, using the user management documentation. Closing check: sign in with each test account, confirm the expected role is granted, and confirm an unmapped account receives no project permissions.
Restrict cluster credentials and confirm component TLS
Limit each cluster credential to the namespaces and resource kinds its project needs, and use a dedicated service account for each destination cluster. Check the current Argo CD security documentation to confirm that traffic between components uses TLS and that the Redis connection is configured with TLS as that documentation describes. Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs, so verify that behavior in your own environment. Closing check: inspect the component configuration to confirm encrypted connections, and confirm a test credential does not appear in API output or logs.
Test break-glass access before disabling admin
Keep the built-in admin user enabled until a separate emergency path has been tested. The user management documentation recommends using admin only for initial setup and disabling it with admin.enabled set to false once local users or SSO are configured. Define who holds the break-glass credential, where it is stored, and how it is rotated after use. Closing check: complete a documented break-glass sign-in in a test environment, then set admin.enabled to false and confirm admin login fails while SSO users keep their access.
Turn on audit and confirm events are captured
Enable audit collection for Argo CD and the cluster, and route Kubernetes events and Argo CD logs to the platform's log store. Confirm which actions produce records in your version, including syncs, RBAC denials and changes to Application and AppProject objects, and alert on denied actions. The compliance lead should confirm that retention and ownership of these records match your obligations. Closing check: trigger one denied sync and one successful sync in the test environment, then confirm both appear in the log store with the user identity attached.

What drives the effort and cost of Argo CD security hardening

This table lists the factors that expand or shrink hardening work on an Argo CD installation, with a way to keep each one contained. Read each row as a question to answer about your own environment before requesting a fixed-scope quote. The main takeaway is that most effort comes from how many teams, repositories and clusters the access model must cover, so standardizing those early lowers both one-time work and ongoing review.

Driver	Why it changes effort or cost	How to keep it down
Number of teams and AppProjects	Each AppProject needs its own source, destination and role boundaries, and each one must be reviewed and tested.	Standardize a small set of project templates and generate AppProjects from them rather than writing each by hand.
Source repositories and third-party content	Repositories that hold third-party Helm charts or Kustomize overlays need allow-list decisions, pinning and review of rendered output.	Consolidate repositories where ownership allows, and restrict sources to an approved list of repositories and chart registries.
Clusters and namespaces each project may reach	Every destination cluster and namespace pair widens the blast radius and adds a permission set to verify.	Limit each project to named destinations and avoid wildcard namespaces. Confirm the cluster-scoped resources each project may create.
SSO and group mapping complexity	Mapping identity provider groups to Argo CD roles takes more work when groups are nested, duplicated or owned by several directories.	Reuse one RBAC model across environments, map a short list of groups, and confirm which claim your identity provider sends for role matching.
Existing Kubernetes audit log pipelines	Argo CD events must be collected and correlated with cluster audit logs, and gaps in the existing pipeline add integration work.	Confirm early whether your current log platform already ingests cluster audit events and which Argo CD events you need to retain.
Compliance evidence requirements	Assessors often ask for evidence of access reviews, change history and configuration baselines, which must be produced and kept.	Agree the evidence list before work starts and generate it from version-controlled configuration. DeployOpen prepares evidence but does not issue audit reports.
Supported minor release tracking	Only the three most recent minor versions receive patch releases, so the team must track upgrades and patches on a quarterly rhythm.	Pin a supported minor version, document the upgrade path, and confirm with your team who owns the quarterly patch review before go-live.

How to contain untrusted manifests in the repo-server

The repo-server is the Argo CD component that fetches Git content and renders it into Kubernetes manifests, and it does this by running Helm and Kustomize on whatever the repository contains. The Argo CD security documentation names this as the risk to control: a repository from an untrusted source, a chart pulled in without review, or a Kustomize overlay that reads files outside its own directory can cause rendering work to reach well beyond the application it was meant to deploy. Treat the repo-server as a component that executes third-party logic, not as a passive file reader, and plan its controls on that basis. Start with the AppProject allow-lists. Each project should list the repository URLs it may read from and the destination clusters and namespaces it may deploy to. Remove wildcard entries unless a team has a documented reason for them, and make sure no project can point at a repository outside the approved list. Next, review third-party Helm charts before they enter the repository. Someone on the platform team should check the chart source, the dependencies it pulls, and any templates that run lookups or generate cluster-scoped objects. Pin chart versions so a later upstream change cannot alter what gets rendered without a visible commit in your own history. Kustomize overlays need a boundary too. Confirm that each application's overlays reference only files within their own directory tree or in approved remote bases, and check the rendered output for paths that escape the repository. The aim is that a pull request touching one application cannot silently change what another application renders. Where your team relies on the file access settings or flags documented for the installed Argo CD version, record them in your runbook so reviewers know what the repo-server is permitted to read. Isolate the repo-server in its own namespace and apply a Kubernetes NetworkPolicy that limits its egress to the Git hosts, Helm registries and any internal artifact sources it needs, and limits ingress to the components that call it. Set CPU and memory requests and limits so a heavy or hostile render cannot starve the rest of the control plane, and review the replica count and parallelism settings for the same reason. Resource limits and concurrency settings should be confirmed against the current operator manual for your installed version, because defaults and parameter names change between minor releases. Finally, treat repository credentials as secrets. Under Argo CD 3.0 and later, repositories are defined as Kubernetes Secrets, so restrict read access to those Secrets with RBAC, use read-only deploy credentials where the host supports them, and rotate them on a schedule your security team sets. Before go-live, run a short verification pass. Attempt to add an unapproved repository to a project and confirm it is rejected. Render a test overlay that references a file outside its directory and confirm the render fails. Check the repo-server pod's effective limits and its NetworkPolicy from inside a test pod. Record the results with the Argo CD version and the date, so the same checks can be repeated after each upgrade.

Secrets handling, identity and audit controls to set

These controls decide who can act in Argo CD, what credentials could leak, and whether a change can be traced afterward. Each one depends on a separate layer: Argo CD itself, the cluster's audit policy, Git hosting, and the secret tooling you choose. Confirm which layer owns each control before you sign off on the hardening plan.

JWT-only API authentication and token lifetime

Argo CD authenticates API requests only with JSON Web Tokens, so the work is in how those tokens are issued and how long they last. Set session and token lifetimes deliberately, and confirm with your identity provider how quickly a removed user loses access. Test that a revoked account cannot keep using an existing CLI or automation token.

TLS for all Argo CD traffic

Argo CD uses TLS for traffic between its own components, which includes the path to Redis. Check that the Redis connection is encrypted in your install, since the Redis TLS setting depends on how the HA manifests are deployed. Verify certificate issuance, rotation and trust for every internal hop, not only the external UI endpoint.

Redaction of credentials in responses and logs

Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs. Treat that as a claim to test, not a guarantee for your environment. Sample API output and controller, repo-server and API server logs, and confirm your logging pipeline does not capture other fields that carry tokens or repository URLs with embedded credentials.

Repository credentials and external secret managers

Since Argo CD 3.0, repositories must be defined as Kubernetes Secrets rather than in argocd-cm. Restrict who can read those Secrets with RBAC, and decide whether credentials should come from an external secret manager through an operator instead of being stored directly in the cluster. Confirm the rotation process for Git tokens and deploy keys.

Encrypting Secrets stored in Git

Any Secret committed to Git is only as protected as its encryption and the key that opens it. Choose between sealing, encrypting in place, or referencing an external store, and document who holds the decryption keys. Plan key rotation and confirm that repository history and forks cannot expose plaintext values after a mistake.

Disabling the built-in admin user

The user management guidance recommends using the built-in admin user only for initial setup and disabling it with admin.enabled set to false once local users or SSO are configured. Before disabling it, confirm that at least one named administrator can log in through SSO and that a documented break-glass path exists. Record who approved the change.

Audit trail from Argo CD and the cluster

Argo CD records Kubernetes events for application activity, but the Kubernetes API audit policy must capture changes to Applications, AppProjects and Secrets, including who made each change and the request content. Confirm with the platform owner how long events and API audit logs are kept, where they are shipped, and who can read them.

What to monitor, back up, upgrade and document after hardening

Hardening only protects you if denials are visible. Argo CD records sync outcomes on each Application and emits Kubernetes events, so the monitoring question is which denials matter and who acts on them. A sync blocked by a repository or destination outside an AppProject's allow-list is usually a deliberate control working, but a sudden rise can also mean a team has changed a path or a new cluster has been added without review.

Sync failures from denied sources: Alert on syncs rejected because the repository or destination is not permitted by the AppProject.
RBAC denials: Review denied actions in the API server logs to separate misconfigured roles from attempted misuse.
Unexpected Application creation: Track new Application objects and compare their project and destination against the approved map.
Kubernetes events: Forward events emitted by Argo CD components to your central log store, and confirm the event reasons your version produces before writing alert rules.
Ownership: Name who receives each alert and what the response is.

Before relying on any alert, trigger a known denial in a non-production cluster and confirm it reaches the right queue.

How to test that Argo CD security hardening works and fails safely

Each hardening control should be tested by trying to do the thing it is meant to block, and the team should write down what a correct failure looks like before the test runs. A control that has never been seen to refuse a request has not been proven. The suite below covers source repositories, destinations, log access, project scope, token handling, admin login and audit output, and it should run in a non-production instance built the same way as production. Start with the project boundaries. Create a test Application in a project that does not list the repository, using a Git URL outside the allow-list. The expected result is that Argo CD refuses the Application, the status shows a project validation error, and no resources from that repository appear in the target cluster. Repeat the test with a destination cluster or namespace that the project does not permit. Confirm the exact error text in your version, because the wording changes between releases, but the outcome should not change: refusal, no reconciliation and no partial deployment. Next, test least privilege with real accounts, not administrator sessions. A user who can view an Application but lacks the logs, get permission should receive a denial when reading pod logs. A user limited to one project should fail when they try to update or delete an Application owned by another team. Since the 2.14 to 3.0 upgrade notes say update and delete RBAC now apply only to the Application itself, include a case that confirms the user cannot change resources beyond their granted scope. Then send a deliberately invalid token and a request with no token. Both should be rejected, and the rejection should be the same status code the team recorded as expected. The login tests need an explicit order. Set admin.enabled to false in a test instance, then confirm that local admin login fails, that a user signing in through the configured SSO provider still succeeds, and that the break-glass account documented for emergencies still works. Keep the break-glass credential out of routine use and test it inside a planned window. Finally, trigger each denial above and confirm an audit event appears in the sink your organization uses, with the user, action and outcome recorded. If an event is missing, the control has not been fully proven, even if the denial itself worked. Record every test in a register with a test ID, the control it covers, the steps, the expected failure, the observed result, the Argo CD version tested, the date and the location of the evidence. Rerun the full suite after each patch release and each minor upgrade, because the project ships minor versions quarterly and supports only the three most recent. Treat any failed test as a blocker until it is fixed or formally accepted. This register also gives independent auditors clear evidence to review, although DeployOpen prepares that evidence and does not issue any assessment.

Argo CD security hardening questions buyers ask

How much effort does Argo CD security hardening take?

Effort depends mostly on how many clusters, repositories, teams and identity groups one Argo CD instance serves, and on how much of the current access model has to change. A single cluster with one team and a few Git repositories is a small job. Larger estates take longer because each Argo CD project needs defined destinations, source boundaries and role mappings, and each repository needs a reviewed allow-list entry. Other drivers include the current RBAC state, whether the admin user and local accounts are still active, how repositories are declared (Argo CD 3.0 requires repositories as Kubernetes Secrets), and whether Helm or Kustomize content comes from sources you do not control. A quote should split the work into inventory, design, changes, testing and handover, and state what is excluded.

Can our in-house platform team harden Argo CD without a partner?

Yes, many platform teams can, provided someone knows Kubernetes RBAC, the Argo CD operator manual and your identity provider well enough to test changes safely. The main steps are documented publicly: limit projects to the destinations and sources they need, keep the built-in admin user for initial setup only, and disable it once SSO or local users are configured. The usual risk is not knowing the steps but finding the time to test them. Changes to RBAC, resource tracking and repository definitions can lock out users or stop deployments if they go straight to production. A partner is worth considering when the team lacks capacity, wants an outside review of the design, or needs the work written up as evidence. Before deciding, check whether your team can run every change in a non-production cluster first.

What do we need to provide before security hardening starts?

Plan to provide five things: cluster access, identity provider admin access, a repository inventory, agreed change windows and a named owner who can make decisions. Cluster access should cover the namespaces and cluster-scoped objects Argo CD manages, plus a non-production environment for testing. Identity provider admin access lets the team configure OIDC or Dex connectors, map groups to roles and confirm which claim RBAC uses, such as federated_claims.user_id in Argo CD 3.0 Dex setups. The repository inventory lists every Git source, chart registry and Kustomize base with its owner. Change windows set when RBAC, project and repo-server changes can be applied. The named owner signs off scope and accepts risk trade-offs. Confirm each item in the written scope before work begins.

How long does Argo CD security hardening usually take?

The duration depends on the same drivers as effort: the number of clusters and projects, the state of identity integration, the repository count and the change windows available. Work is usually scoped in phases, starting with inventory and a design review, then changes in non-production, then production cutover and handover. Each phase waits on client decisions and approvals, so calendar time can exceed hands-on effort. No standard duration applies to every estate, so no figure is given here. Ask for a timeline in the written scope that shows which tasks depend on your access, your identity provider team and your change calendar, and which milestones you must formally accept.

Does DeployOpen issue an audit report after hardening Argo CD?

No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. DeployOpen can prepare the system, its configuration and the evidence an assessor is likely to request, such as documented RBAC roles, project boundaries, repository allow-lists, the admin user setting, Kubernetes event audit trails and change records. The assessor decides which controls apply and whether they are met. Before the work starts, confirm with your auditor which evidence they accept and in what format, and make sure the hardening scope covers every environment inside your assessment boundary.

What happens to our hardening when new Argo CD minors ship?

Argo CD ships a minor release four times a year, about every three months, and only the three most recent minor versions receive patch releases. On October 12, 2026 the project published patch releases v3.5.5, v3.4.11 and v3.3.16, with v3.6.0 in release candidate. A configuration that was hardened on one minor can fall outside patched versions without any change on your side. A support arrangement may cover tracking the release cycle, testing each minor against your RBAC, tracking and repository setup, and promoting changes through staging. In the quote, confirm who runs upgrade tests, how often reviews happen and how a breaking change, such as the RBAC changes in the 2.14 to 3.0 upgrade, is handled in your environment.

Which Argo CD security settings are most likely to break deployments?

Most breakage comes from RBAC, resource tracking and repository changes, so test those first. From Argo CD 2.14 to 3.0, update and delete permissions apply only to the application itself, and reading logs requires an explicit logs, get permission. Annotation-based resource tracking is now the default, so confirm how existing resources are tracked before cutover. Repositories must be defined as Kubernetes Secrets because argocd-cm no longer holds them. Dex-based RBAC uses the federated_claims.user_id claim. Disabling the admin user before SSO roles are confirmed can lock out operators. Run each change in a non-production cluster with a rollback plan and a named approver.

How DeployOpen scopes, builds and hands over Argo CD hardening

DeployOpen hardens Argo CD inside infrastructure you control, working from a written scope that names the projects, repositories, clusters and identity setup in play. The work is planned, built, tested and documented in your environment, then handed over so your own team can operate and audit it.

How we scope

We review your current Argo CD install, version, and how projects, repositories and clusters are registered today.
The written scope lists which AppProjects, RBAC roles, repository allow-lists and repo-server settings are in and out of scope.
Engagements are fixed-scope, so deliverables, timelines and acceptance criteria are agreed in writing before work starts.

How we build

We tighten project boundaries so each application can deploy only to approved repositories, namespaces and clusters.
We replace broad cluster roles with least-privilege RBAC, retire the built-in admin user and confirm SSO group mappings.
We configure repository definitions as Kubernetes Secrets, set repo-server limits and enable Redis TLS, then test each control.

How we hand over

You receive configuration as code, a hardening runbook and a record of each control with the evidence used to verify it.
We document audit steps using Kubernetes events and Argo CD logs, so your team can review access and sync activity.
Walkthroughs cover how to test RBAC and allow-list changes before they reach production clusters.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
A retainer can cover re-testing RBAC and allow-lists when you add projects, clusters or repositories.
Quarterly Argo CD minor releases can be reviewed against the hardened configuration before your own upgrades.

Argo CD security hardening