Rancher Security: Hardening Rancher Manager, RBAC, Tokens and CIS Benchmarks

Rancher Manager sits in front of every Kubernetes cluster it manages, so one Rancher administrator account or one long-lived API token can reach all of them. Hardening the individual clusters is necessary but not sufficient: the Rancher server, its global roles, its tokens and its own local cluster form a control plane above Kubernetes that needs its own controls. This guide covers how authentication and impersonation work in Rancher, global and cluster roles, token time-to-live settings, the API audit log, the Rancher webhook, and the CIS-based hardening guides for RKE2 and K3s. It is written for platform and Kubernetes engineers and security teams running Rancher Manager 2.8 or later; settings are taken from the Rancher Manager documentation (latest, 2.15 series) as checked on 8 November 2026. Kubernetes fundamentals are covered in the Kubernetes Security Guide and are not repeated here.

This is an independent guide from NHI Mgmt Group, based on SUSE's public documentation as of November 2026. It is not sponsored or reviewed by SUSE. Product features change, so confirm settings against SUSE's current documentation.

Key takeaways

• Rancher is a tier-zero system. Administrators and anyone with access to the Rancher local cluster control every downstream cluster, so treat them like domain administrators.
• Change the new-user default. Users who first sign in through an external identity provider get the Standard User global role by default, which includes Create Clusters; most organisations should grant User-Base and assign cluster access explicitly.
• Tokens outlive passwords. Rancher documents that some cluster tokens are created with ttl=0 and never expire, and that changing a password does not invalidate tokens; set auth-token-max-ttl-minutes and kubeconfig-default-token-ttl-minutes deliberately.
• Turn on the API audit log. AUDIT_LOG_ENABLED is false by default; without it you cannot tell who used the authentication proxy to act on a downstream cluster.
• Harden clusters with the matching guide. Rancher's RKE2 and K3s hardening guides map to specific CIS Kubernetes Benchmark versions (CIS v1.12 for Kubernetes 1.32 and above) and the compliance scan tooling checks them with kube-bench.

How identity and access work in Rancher

Users exist only on the upstream Rancher server. They authenticate with local accounts or an external provider (Active Directory, LDAP, SAML providers such as Okta, Keycloak and Ping Identity, OIDC, GitHub and others). When a user acts on a downstream cluster, the request goes through Rancher's authentication proxy, which authenticates the caller and forwards the call with Kubernetes impersonation headers. On each downstream cluster Rancher creates RoleBindings and ClusterRoleBindings that refer to Rancher users, plus a service account per user whose only permission is to impersonate that user.

• cattle-cluster-agent: runs in each downstream cluster and connects back to Rancher; its credentials are how Rancher manages the cluster, so protect the cattle-system namespace on every cluster.
• Authorized cluster endpoint (ACE): lets kubeconfig users talk directly to a downstream API server, bypassing the Rancher proxy. It must be enabled manually for registered RKE2 and K3s clusters. Use it for resilience, knowing that requests then do not pass through Rancher's audit log.
• Local cluster: the cluster that hosts Rancher itself. Anyone with administrative Kubernetes access to it can read Rancher's data, including stored credentials, so restrict it to the platform team.
• Bootstrap admin: the first account is named admin. If no bootstrap password is set, Rancher generates a random one; after first login the new password must be at least 12 characters. Rancher itself enforces only a minimum password length, so username and password policy should live in the identity provider.

Admin roles and privileged access

• Escalate and bind: Rancher honours the Kubernetes escalate and bind verbs on GlobalRoles. The documentation warns that either verb lets a user bypass Rancher's privilege escalation checks and potentially become an administrator. Grant them only to administrators and alert on any role that contains them.
• Non-admin defaults: non-administrative users have no access to existing clusters or projects until an owner assigns membership. Keep it that way and grant access through IdP groups rather than individual users, so leavers lose access when the group changes.
• Kubernetes RBAC still applies: Rancher roles become Kubernetes RBAC objects downstream. Review them with the same rigour as native roles; see the Kubernetes RBAC Guide.

Integrations, API tokens and service accounts

Rancher issues bearer tokens for UI sessions, the Rancher CLI, kubeconfig files and API keys. A token in a downloaded kubeconfig is a credential to a production cluster that can be copied anywhere (MITRE ATT&CK T1528 Steal Application Access Token).

• ttl=0 system tokens: Rancher lists kubectl-shell-*, agent-*, compose-token-*, helm-token-* and drain-node-* tokens as created with no expiry. Inventory them through /v3/tokens and delete those no longer needed.
• Revocation on leave: password changes do not invalidate tokens. Offboarding must delete the user's tokens or deactivate the account; disabling the user only in the IdP may leave API tokens working until they expire.
• Automation identities: CI pipelines, Terraform providers and GitOps tooling that call the Rancher API should use dedicated accounts with scoped roles and short-lived tokens stored in a secrets manager. See the Kubernetes NHI Security Guide.
• Cloud credentials: credentials Rancher uses to provision nodes in cloud providers are stored by Rancher and should be scoped to the minimum provisioning permissions in each cloud account (T1078.004 Cloud Accounts covers their misuse).

If a kubeconfig leaks, follow the Leaked Kubeconfig Response guide and delete the Rancher token behind it as well as rotating any cluster-native credentials.

Logging and detection

The Rancher API audit log records calls made through Rancher, including those proxied to downstream clusters. It is configured with environment variables on the Rancher deployment.

Rancher applies default redactions to sensitive headers and body fields, and AuditPolicy custom resources add further redactions or filters. Test higher levels with your redaction policy before enabling them, because request bodies can include secrets. Also collect Kubernetes API server audit logs from the local and downstream clusters; see the Kubernetes Audit Log Detection Guide.

Alert on: new Administrator or Manage Users bindings; GlobalRoles containing escalate or bind; changes to token TTL settings or the authentication provider; tokens created with long TTLs; kubeconfig downloads for production clusters outside working hours; changes in the cattle-system namespace; and failed logins at volume.

Metrics:

• Number of global Administrators, reviewed monthly (target: a small named list plus break-glass).
• Percentage of users whose global role is User-Base rather than Standard User.
• Count of active tokens older than the maximum TTL policy, and of ttl=0 tokens not owned by system components.
• Percentage of downstream clusters passing the matching CIS profile in compliance scans.
• Time from leaver event to deletion of that user's Rancher tokens.

Hardening baseline

Rancher server

1. Front Rancher with a Layer 7 firewall: block public access to /version and /rancherversion, which disclose the Rancher and Go versions, and apply rate limits to cluster creation and login endpoints. Rancher recommends rate limiting at the WAF rather than in the application.
2. Use an external identity provider: enforce MFA and username policy there, and use it for session restrictions Rancher does not provide (concurrent sessions, location).
3. Set the new user default to User-Base and grant cluster and project roles through IdP groups.
4. Tighten token settings: lower auth-token-max-ttl-minutes, set kubeconfig-generate-token = false, and evaluate token hashing in a test instance first.
5. Enable the API audit log at level 1 or 2 with redactions and forward it.
6. Keep TLS at 1.2 or above: the default minimum is TLS 1.2; consider CATTLE_TLS_MIN_VERSION = 1.3 where all clients support it.
7. Restrict the Rancher webhook: by default it accepts traffic from any source. Use Calico or Cilium network policies so only the Kubernetes API server (control plane host CIDRs) can reach pods labelled app rancher-webhook.
8. Protect the local cluster: dedicated nodes, no application workloads, admin access only for the platform team, encrypted and tested etcd backups.

Downstream clusters

• Follow the matching hardening guide: Rancher's tables map Kubernetes versions to CIS Benchmark versions for RKE2 and K3s (CIS v1.12 for Kubernetes 1.32 and above, CIS v1.11 for 1.29 to 1.31). Harden node operating systems before installing Kubernetes, as the guides recommend.
• Protect registration ports: keep 6443 (Kubernetes API on K3s and RKE2) and 9345 (RKE2 node registration) behind an external load balancer, because their TLS certificates list node public IP addresses in SANs.
• Pod Security Admission: apply restricted policies through Rancher's PSA configuration templates and keep exemptions to the documented Rancher system namespaces.
• SELinux: on SELinux-enforcing hosts install the rancher-selinux, rke2-selinux or k3s-selinux packages rather than switching SELinux off.
• Run compliance scans on a schedule and track failures to remediation. See the CIS Benchmarks Guide.

Rollout and rollback: make global setting changes (token TTLs, new-user default, kubeconfig-generate-token) in a non-production Rancher first and announce them, because shorter TTLs break scripts that use old tokens. Enable audit logging and webhook network policies one cluster at a time and keep the previous Helm values so a change can be reverted with a Helm upgrade. Token hashing is the exception: it is irreversible, so it needs a full test cycle before production.

Small versus large estates: a team with a handful of clusters can run one Rancher with Administrator limited to two or three people and project-level access for everyone else. Large estates should separate production and non-production into different Rancher instances, manage roles as code, and route all automation through dedicated, short-lived identities.

Common misconfigurations

• Standard User as everyone's default: every employee who signs in through SSO can create clusters and grant others access to them, which spreads cluster ownership and cloud spend without review.
• Long-lived kubeconfig tokens: 90-day default maximums, tokens embedded in downloaded kubeconfigs and shared in chat or committed to repositories, and no deletion at offboarding.
• Audit log never enabled: the default is off, so investigations of proxied changes to downstream clusters have no Rancher-side record.
• Custom roles with escalate or bind: created to solve a delegation problem, they quietly allow self-promotion to administrator.
• Rancher exposed to the internet without a WAF: version endpoints readable, no rate limiting, and the login page open to password spraying against local accounts.
• Treating the local cluster as a general workload cluster: application pods and wide kubectl access on the cluster that holds Rancher's own data.

Framework mapping

Practitioner checklist

• List every global Administrator and Manage Users holder and cut the list to named, MFA-protected people plus one vaulted break-glass account.
• Change the New User Default global role from Standard User to User-Base.
• Search GlobalRoles and custom roles for escalate and bind verbs and remove them from non-administrators.
• Lower auth-token-max-ttl-minutes and kubeconfig-default-token-ttl-minutes, and set kubeconfig-generate-token to false.
• Review /v3/tokens for ttl=0 and long-lived tokens and delete unused ones; add token deletion to offboarding.
• Enable the API audit log with AUDIT_LEVEL 1 or 2 and redaction policies, and forward it to the SIEM.
• Block /version and /rancherversion and rate-limit Rancher endpoints at a WAF.
• Apply network policies so only the API server reaches the Rancher webhook.
• Harden RKE2 and K3s clusters with the guide matching their CIS Benchmark version and schedule compliance scans.
• Restrict the local cluster to Rancher alone and test etcd backup restores.

Standards and references

• SUSE Rancher: Rancher Security Guides
• SUSE Rancher: Rancher Security Best Practices
• SUSE Rancher: Using API Tokens
• SUSE Rancher: Global Permissions
• SUSE Rancher: Enabling the API Audit Log
• SUSE Rancher: Rancher Webhook Hardening
• CIS: Kubernetes Benchmark
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Kubernetes Security Guide · Kubernetes RBAC Guide · Kubernetes NHI Security Guide · Leaked Kubeconfig Response · Kubernetes Security Checklist