Rancher Security Review
A single Rancher GlobalRole can quietly grant cluster-owner access on every cluster it manages, present and future. We test its global roles, cluster and project bindings, authentication proxy and API tokens. CREST-certified testers, fixed price from £3,740 for a 3-day single-management-server 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.”
A single GlobalRole’s inheritedClusterRoles field can grant cluster-owner access on every cluster Rancher manages, including ones added later. We check whether yours does.
Why a Rancher global role can reach every cluster it manages
Rancher’s own permission model sits in two layers. Global permissions, such as the built-in Administrator and Standard User roles, define what an account can do outside any particular cluster, while cluster and project roles, such as Cluster Owner and Cluster Member, apply only inside the specific cluster or project a user has been added to; Rancher’s own documentation on managing RBAC confirms both layers are implemented on top of Kubernetes RBAC and enforced by Kubernetes itself. A new external-provider user is assigned Standard User by default, which already includes permission to create clusters, and non-administrative users get no access to any existing cluster or project until an Owner grants it directly. We test which global role and which cluster or project roles every account actually holds, not what its job title implies it should hold.
A custom GlobalRole can carry an inheritedClusterRoles field naming a cluster-scoped role such as cluster-owner, and Rancher documents that any account holding that GlobalRole becomes an owner on every downstream cluster that exists today, and on any cluster added afterwards too, automatically. The same GlobalRole resource respects the escalate and bind verbs that Kubernetes itself restricts on role creation, and Rancher warns that a wildcard verb on GlobalRoles carries both implicitly, which can let a holder grant themselves permissions their own account never had. This is the same access model we review directly at cluster level under our Kubernetes penetration testing, extended here across every cluster a single Rancher server manages. We test every custom GlobalRole for an inheritedClusterRoles or inheritedNamespacedRules grant that reaches further than its name suggests, and for escalate or bind verbs sitting on an account that should not hold them.
Every request a user makes against a downstream cluster through the Rancher UI or kubectl passes through Rancher’s own authentication proxy, which authenticates the caller and sets Kubernetes impersonation headers before forwarding the call, using a service account that impersonates the user against that specific cluster. Sign-in to that proxy can come from local accounts or an external provider such as Active Directory, SAML, OIDC or GitHub, and Rancher links the external identity to a local principal that shares its user ID and access rights from that point on. We review the global roles, cluster and project bindings, authentication proxy configuration and API tokens on your own Rancher server, the same way we review a client’s own configuration, and we never test Rancher’s underlying codebase.
SCOPE
What we review on a single Rancher management server
Global Permissions: Administrator, Standard User and Custom Roles
Rancher’s authorisation layer works alongside Kubernetes RBAC rather than replacing it: global permissions define what a user can do outside any particular cluster, and both global permissions and cluster or project roles are enforced by Kubernetes underneath. A new user signing in through an external authentication source is assigned the default Standard User role, which grants Create Clusters, Create RKE Templates and Use Catalog Templates on top of basic User-Base login access, while Administrator carries every global permission Rancher ships, including Manage Roles, Manage Users and Manage Authentication. We test which global role every account actually holds, and whether the default has been narrowed with a custom GlobalRole where Administrator or Standard User grants more than the account needs.
Cluster and Project Roles Scoped to One Managed Cluster
Below the global layer, Rancher assigns Cluster Owner or Cluster Member, and their project-level equivalents, inside the specific cluster or project a user is added to, and the account that creates a cluster or project is made its Owner automatically. A Cluster Owner can manage cluster backups, storage, catalogues and cluster membership, while a Member gets only the narrower set, such as viewing nodes and cluster catalogues, and a non-administrative user gets no access to any existing cluster or project until an Owner assigns it. This is the same Kubernetes RBAC boundary we test directly on a single cluster under our Kubernetes penetration testing, so we map every Rancher-issued cluster and project role against the Kubernetes Role or ClusterRole it actually resolves to.
GlobalRole inheritedClusterRoles Reaching Every Downstream Cluster
A custom GlobalRole can carry an inheritedClusterRoles field naming a cluster-scoped role, such as cluster-owner, and Rancher’s own documentation confirms that any user holding that GlobalRole becomes an owner on every current downstream cluster, and is made owner automatically on any cluster added afterwards too. The equivalent inheritedNamespacedRules field reaches a named namespace, such as a monitoring namespace, on every cluster the moment that namespace exists there. We test every custom GlobalRole for an inheritedClusterRoles or inheritedNamespacedRules grant that reaches further than the role’s name suggests, and flag one attached to a broad group rather than a single named account.
Escalate and Bind Verbs on Custom GlobalRoles
Rancher enforces the same restriction Kubernetes places on role creation: the escalate verb lets a holder add any permission to a GlobalRole, even one their own account does not have, and the bind verb lets them create a GlobalRoleBinding to a GlobalRole they could not otherwise use, which Rancher’s documentation warns can together let a user become an administrator. A wildcard verb granted on the GlobalRoles resource carries escalate and bind implicitly, which is easy to miss when a custom role is written with a single wildcard for convenience. We test every custom GlobalRole for escalate, bind or wildcard verbs on GlobalRoles, and trace whether any account holding one can reach full Administrator.
Authentication Proxy, Impersonation and Kubeconfig Access
Every kubectl command run through Rancher against a downstream cluster passes through Rancher’s own authentication proxy, which authenticates the caller and sets Kubernetes impersonation headers before forwarding the request to that cluster’s API server; Rancher communicates with each downstream cluster using a service account that impersonates the calling user, so the permissions actually enforced are whatever that impersonated identity is bound to in Kubernetes RBAC. By default Rancher also generates a kubeconfig file carrying credentials for proxying through the Rancher server to reach a downstream cluster’s API server, so anyone holding that file inherits whatever the proxy resolves for the account it belongs to. We test what the impersonation path and any exported kubeconfig actually resolve to for each role tier, not just what the Rancher dashboard displays.
Provisioning Drivers Across Hosted and Imported Clusters
Rancher’s provisioning drivers decide which platforms it can create or manage a cluster on, and its documentation confirms support for hosted providers including Google GKE, Amazon EKS and Microsoft AKS; for a hosted cluster Rancher does not provision the Kubernetes control plane itself, it integrates with that provider’s own cloud API instead, while still letting an operator create and manage Kubernetes RBAC for that cluster from the Rancher UI. Whichever platform a downstream cluster runs on, the same Rancher global, cluster and project role model is applied to it. Where a managed cluster is itself a hosted Google Kubernetes Engine cluster, the platform-specific IAM and control-plane questions sit with our dedicated GKE review, and here we test how consistently Rancher’s own RBAC layer is applied across every cluster type it manages.
Authorized Cluster Endpoint Bypassing the Proxy
An Authorized Cluster Endpoint lets a user connect straight to a downstream cluster’s Kubernetes API server without routing the request through Rancher’s authentication proxy, using a kube-api-auth microservice as a webhook to authenticate the caller instead. Rancher’s documentation confirms this endpoint is only available on RKE2 and K3s clusters provisioned or registered with Rancher, not on clusters from a hosted Kubernetes provider such as Amazon EKS, and it is typically enabled to keep access working if the Rancher server itself is down or far from the cluster. We test whether an Authorized Cluster Endpoint is enabled on eligible clusters, and whether its own access controls match what the Rancher-proxied path enforces.
Cluster Agent and Cluster Controller Tunnel
Each downstream cluster runs a cluster agent, called cattle-cluster-agent, which opens an outbound tunnel to a matching cluster controller inside the Rancher server; Rancher’s architecture documentation confirms the cluster controller uses that tunnel to configure access control policies on the cluster and to apply the roles and bindings defined by Rancher’s global policies. If the cluster agent is unavailable, the cluster controller can fall back to connecting through a Rancher system agent instead. We test how the cluster agent authenticates to the Rancher server, what it is able to apply inside the downstream cluster, and whether the tunnel is reachable from anywhere it should not be.
API Keys and Bearer Tokens Scoped to a Cluster
A Rancher API key is made up of an endpoint, an access key, a secret key and a bearer token, and Rancher’s documentation confirms a key can optionally be scoped so it only works against the Kubernetes API of one named cluster; where that cluster has an Authorized Cluster Endpoint configured, a scoped token can be used directly against the cluster’s own API without proxying through the Rancher server at all. Key expiration is bound by the server’s configured maximum token time-to-live, and a key that is never given an expiration or is left over after a project ends stays valid until someone deletes it. We test which API keys exist, whether they are scoped to the cluster they are meant for, and whether any unscoped or unexpiring key is still active.
Authentication Providers and Principal Linking
Rancher ships local authentication as a built-in provider active by default, which its own documentation describes as intended strictly for small deployments and testing, recommending external authentication for production with local kept only as an emergency fallback. Rancher’s authentication proxy integrates with external providers including Microsoft Active Directory, GitHub, Microsoft Entra ID, OpenLDAP, FreeIPA, Microsoft AD FS and Keycloak over OIDC or SAML, and configuring one links an external principal to a local administrator principal that shares its user ID and access rights from then on. We test which providers are actually configured, whether local accounts remain enabled beyond emergency use, and what access the linked principal carries once external authentication is switched on.
OUR PROCESS
Rancher Security Review: From Scope to Attestation
Scope and Access
We agree the Rancher server, the downstream clusters it manages and the authentication providers in scope, plus at least one account or API key for each global and cluster role tier.
Role and Proxy Mapping
We map every global permission, custom GlobalRole, cluster and project role, and authentication proxy binding against the access it actually grants.
Manual Testing
A CREST-certified tester manually tests global role boundaries, cluster and project role scoping, escalate and bind exposure, and authentication proxy and API token handling, chaining findings toward a cluster they should not reach.
Reporting 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 Rancher 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 Rancher 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 Rancher 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 Rancher 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 Rancher server?
At minimum, one account or API key for each distinct global and cluster or project role tier in use, ideally scoped rather than full Administrator. Where external authentication is configured through Active Directory, SAML or OIDC, tell us which groups map to which Rancher roles so we test the ones that actually matter.
Will testing touch the clusters Rancher manages?
Our focus is Rancher’s own role configuration, its global roles, cluster and project bindings, authentication proxy and API tokens, rather than the workloads running inside each downstream cluster. If you also want the Kubernetes RBAC and workloads inside a specific managed cluster tested, we scope that separately and agree any production exclusions in writing first.
How long does a Rancher security review take?
A single Rancher server with a typical number of managed clusters sits in our 3-day single-management-server scope, with a report landing around 5 working days after kickoff. A large number of managed clusters, several external authentication providers or extensive custom GlobalRoles extend that scope.
Do you need admin access or our source code?
No. Testing is black-box against the running Rancher server and its role configuration by default. Sharing exported GlobalRole or RoleTemplate definitions is optional, and it speeds up scoping the custom roles we would otherwise have to reconstruct from the live server.
How is this different from your Kubernetes penetration testing?
Our Kubernetes penetration testing covers the RBAC and workloads on an individual cluster, self-managed or on any cloud. This page is the layer above it: the global roles, cluster and project roles, authentication proxy and API tokens that decide who can reach which of the clusters a single Rancher server manages. Clients running a multi-cluster estate often scope both together.
What authentication providers do you check?
We test whichever provider you have configured, whether that is Rancher’s built-in local authentication or an external provider such as Active Directory, GitHub, Microsoft Entra ID, OpenLDAP, AD FS or Keycloak over OIDC or SAML. We check what your provider maps external groups onto inside Rancher, and whether local accounts remain enabled for daily use rather than as an emergency fallback.
Does SUSE have a customer penetration-testing policy for Rancher?
Self-hosted Rancher is software you run yourself, so there is no vendor notification process to follow before testing your own instance. Where a downstream cluster is itself a hosted provider, such as Amazon EKS, Google GKE or Microsoft AKS, that provider’s own customer testing policy applies to that cluster and we confirm its current terms during scoping.
Are your testers CREST certified?
Yes. Every Rancher 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 Rancher management server
A single Rancher GlobalRole can quietly grant cluster-owner access on every cluster it manages, present and future. We test its global roles, cluster and project bindings, authentication proxy and API tokens. CREST-certified testers, fixed price from £3,740 for a 3-day single-management-server scope, quoted within 24 hours.
