Argo CD Security Review
Argo CD syncs your cluster to whatever Git access, RBAC roles and destination privileges your team configured. We test those projects, policies, repository credentials and cluster secrets, not Argo CD’s own code. CREST-certified testers, fixed price from £3,740 for a 3-day single-cluster scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Argo CD ships only two built-in roles, role:readonly and role:admin. Every other permission in the system comes from the policy.csv your team writes.
An Argo CD instance is only as locked down as the projects, RBAC policy and cluster credentials your team configured
Every Argo CD Application belongs to a project, and Argo CD’s own documentation on projects confirms that an application left unassigned falls into the default project, which is created automatically with the widest possible specification: any source repository, any destination cluster and namespace, and every Kubernetes resource kind whitelisted. Locking that project down, or moving applications into scoped projects with their own source repository and destination restrictions, is a decision your platform team has to make; Argo CD does not make it for you.
Access to the Argo CD API and UI is controlled entirely by the policy.csv your team writes into the argocd-rbac-cm ConfigMap, built on two pre-defined roles, role:readonly and role:admin, which Argo CD itself defines as read-only access to all resources and unrestricted access to all resources respectively. The policy.default setting decides what any authenticated user gets if no explicit rule matches them, and if anonymous access is switched on in argocd-cm, unauthenticated visitors assume that same default role too. We test which policy.csv rules and default role are actually in force against what the platform team intended.
We review the projects, policy.csv rules, admin account, SSO configuration, repository credentials and destination cluster secrets configured on your own Argo CD instance, the same way we test client configuration on a Kubernetes cluster rather than Kubernetes itself. We never test Argo CD’s own codebase or attempt to find vulnerabilities in the open-source project.
SCOPE
What we review on a single-cluster Argo CD deployment
Projects and Source Repository Restrictions
Every Application belongs to a project, and Argo CD documents that an application left unassigned falls into the default project, created automatically with sourceRepos set to a wildcard so any Git repository can be used as a source. Locking a project’s sourceRepos down to the specific repositories a team actually owns is what stops a compromised or malicious repository elsewhere in the organisation from being synced through that project. We test which projects exist, what their sourceRepos actually allow, and whether the default project has been left at its original, unrestricted specification.
Destination Clusters and Namespaces
A project’s destinations field lists the clusters and namespaces its applications are allowed to deploy into, and Argo CD’s global projects feature lets a namespaceResourceBlacklist, clusterResourceWhitelist or destinations list be inherited by every project matching a label selector rather than set individually. We test which clusters and namespaces each project can actually reach, whether a project meant for a single namespace can deploy cluster-scoped resources, and whether global project inheritance has widened access beyond what an individual project’s own specification shows.
RBAC Policy.csv and Built-in Roles
Argo CD ships two pre-defined roles, role:readonly for read-only access to all resources and role:admin for unrestricted access to all resources, and every other permission comes from the p and g lines your team writes into the policy.csv held in the argocd-rbac-cm ConfigMap. The policy.default setting decides what an authenticated user with no matching rule is granted, and role inheritance lets one role be built on top of another. We test the actual policy.csv against what each group and user is meant to hold, and whether policy.default grants more than intended by default.
Project Roles and CI Pipeline Tokens
A project role is a named set of policies scoped to that project alone, and Argo CD documents issuing a JWT token against a project role, for example to give a CI pipeline permission to sync a single application without letting it change that application’s source or destination. Those tokens can be created with an expiry, listed, and individually revoked. We test which project role tokens exist, what a CI pipeline’s token can actually reach beyond the sync it was issued for, and whether an old token has ever been revoked.
Admin Account and Local Authentication
Argo CD ships one built-in admin user with full access to the system, and its documentation recommends using admin only for initial configuration before switching to SSO or dedicated local users. On Argo CD 1.9 and later the initial admin password is generated and stored in the argocd-initial-admin-secret; the password itself is kept as a bcrypt hash in the argocd-secret Secret, and changing it immediately revokes every admin JWT already issued. We test whether the admin account is still in everyday use, whether its initial secret was ever rotated, and who still holds a valid admin session.
SSO via Dex or an External OIDC Provider
Argo CD bundles Dex to delegate authentication to an external identity provider over OIDC, SAML, LDAP or GitHub, configured through connector settings in the argocd-cm ConfigMap, and an organisation can instead point Argo CD directly at its own OIDC provider without Dex. Whichever route is used, the groups and email claims an identity provider returns are what the policy.csv actually keys its g lines against. We test how those claims map onto RBAC groups, and whether a group claim from the identity provider grants more than the platform team intended.
Repository Credentials
Argo CD stores the credentials it uses to reach private Git repositories, SSH keys, HTTPS username and password or access token pairs, or a GitHub App’s installation ID and private key, and supports credential templates so one set of credentials covers every repository under a given URL prefix. A GitHub App credential needs only read-only access to a repository’s contents, but a broader template applied to an entire organisation’s URL prefix hands that same access to every repository Argo CD later connects under it. We test which credentials are configured, what scope they actually carry, and whether a template has been applied more broadly than the applications that use it need.
Destination Cluster Secrets
To manage a cluster other than the one it runs in, Argo CD stores that cluster’s credentials as a Kubernetes Secret in its own namespace, holding the bearer token of the argocd-manager ServiceAccount created when the cluster was added, plus any TLS configuration or cloud role details needed to reach its API server. That token can be rotated by deleting it on the managed cluster and re-running the add command, but nothing forces that rotation to happen on its own. We test what the argocd-manager ServiceAccount can actually do on each managed cluster, and whether its bearer token has ever been rotated since the cluster was added.
Automated Sync and Self-Healing
An application’s automated sync policy can prune resources removed from Git, and its self-heal option reverts any change made directly against the live cluster back to the state defined in Git; Argo CD documents both as inactive unless explicitly enabled. Whoever can edit the tracked Git repository or the application’s sync policy effectively controls what changes are allowed to persist in the cluster, whatever an operator does through kubectl. We test which applications have prune and self-heal enabled, and who can reach the Git repository or Argo CD configuration that drives them.
API and UI Exposure
Authentication to the Argo CD API is performed exclusively with JSON Web Tokens, issued either by Argo CD itself for the local admin user or by the configured identity provider for SSO users, and anonymous access can be switched on in argocd-cm so that unauthenticated visitors assume the policy.default role without logging in at all. How the argocd-server is exposed, behind your own ingress, through a load balancer, or reachable only inside the cluster, determines who can reach that authentication boundary in the first place. We test how the server is actually exposed, whether anonymous access is enabled, and what an unauthenticated or low-privilege session can reach.
OUR PROCESS
Argo CD Security Review: From Scope to Attestation
Scope and Access
We agree which Argo CD instance, projects and destination clusters are in scope, plus at least one login for each RBAC role and a read-only kubeconfig for the clusters it manages.
Project and Policy Mapping
We map every project’s source repositories, destination clusters, RBAC policy.csv rules and project role tokens against the access they actually grant.
Manual Testing
A CREST-certified tester manually tests RBAC boundaries, project restrictions, repository and cluster credential exposure, and sync permissions, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Argo CD pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Argo CD Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
3 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote6 to 8 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Argo CD For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Argo CD Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Argo CD instance?
We need at least one login for each distinct RBAC role in use, ideally a role:readonly account rather than the built-in admin, plus a read-only kubeconfig for every cluster Argo CD manages. Read access to your current projects and policy.csv speeds up scoping but is not required to start.
Will testing touch our live data?
Testing focuses on projects, RBAC policy, repository credentials, destination cluster access and sync configuration rather than the contents of the applications Argo CD deploys. Where proving a finding needs a test sync or a scoped test application, we agree the exact scope with you first and remove anything we create once testing is complete.
Is this hosted on our infrastructure?
Argo CD is almost always self-hosted inside your own Kubernetes cluster, so the engagement is scoped to the projects, policy and credentials your team configured on that installation rather than to a vendor-hosted platform.
How long does an Argo CD security review take?
A single cluster with a typical set of projects, a handful of managed destination clusters and one identity provider integration sits in our 3-day single-cluster scope, with a report landing around 5 to 8 working days after kickoff. An instance managing many external clusters or running a large number of projects extends that scope.
What is out of scope for a single-cluster review?
Testing Argo CD’s own source code, the underlying Kubernetes control plane, and the CI pipelines that produce the manifests Argo CD syncs are not included, and we do not run denial-of-service testing against the argocd-server. Vulnerabilities in the applications Argo CD deploys are scoped and quoted separately.
Do you need our source code or admin access?
No. We test with the role accounts and access you provide, and we do not need standing admin access to Argo CD beyond what is needed to verify a specific finding during the engagement.
Does the Argo Project have a policy on customer penetration testing?
Argo CD is open-source software you run inside your own cluster, so there is no vendor notification process to follow before testing your own instance, and a genuine vulnerability in Argo CD’s own code is reported through the Argo Project’s published security policy on GitHub instead.
Are your testers CREST certified?
Yes. Every Argo CD engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Argo CD cluster
Argo CD syncs your cluster to whatever Git access, RBAC roles and destination privileges your team configured. We test those projects, policies, repository credentials and cluster secrets, not Argo CD’s own code. CREST-certified testers, fixed price from £3,740 for a 3-day single-cluster scope, quoted within 24 hours.
