Starting in RKE2 v1.37, every cluster runs a small, optional component called security-responder by default. It tells you which CVEs affect the RKE2 version you’re running, and what version to move to next. It does this automatically, in-cluster, without you having to track release notes or CVE feeds yourself.
To do that, it needs to send a small, fixed set of non-identifying facts about your cluster to a SUSE-run endpoint a few times a day. Below you’ll find exactly what that is, what it explicitly is not, and how to turn it off in one line if you’d rather not.
RKE2 is open source, it’s also available with enterprise support and long-term support options as SUSE Rancher Prime for up to 5 years of additional support.
Security Responder closes the “am I affected” gap
Today, if a CVE affects your RKE2 version, you find out by watching release notes, a mailing list, or a security advisory feed, or you don’t find out until an audit or a customer asks. There’s no in-cluster answer to “am I affected, and what do I upgrade to?”
Separately, the RKE2 maintainers have never had visibility into real-world deployment patterns, meaning which Kubernetes versions, CNI plugins, or ingress controllers are actually in use, which makes it hard to know what to prioritize testing and support for. Security-responder is designed to solve the first problem for you, and the second problem for us, using the same minimal signal.
What’s collected
A CronJob running in kube-system sends this payload roughly three times a day:
That’s the entire payload. Here’s what it looks like on the wire:
Minimal mode sends less without turning the feature off
Two modes ship with the component. `recommended`, the default, sends everything in the table above. `minimal` omits node counts, CPU and memory totals, GPU count, and SUSE Rancher Prime version details.
Minimal mode still returns full CVE and upgrade guidance, because that only depends on your version. If your security policy limits what may leave the cluster, this is the setting to reach for before you disable the component outright. The next section shows how to set it.
What’s explicitly not collected
- No workload data, pod contents, logs, or secrets
- No hostnames, cluster names, company names, or any other identifying label
- The payload itself contains no network-level identifiers. IP address isn’t one of the fields sent
- No config file contents beyond the specific fields listed above
- No always-on agent. The CronJob runs, sends one payload, and exits; there’s no persistent daemon watching your cluster
SUSE handles the data it receives in line with the SUSE Privacy Statement. If you would rather send less, use minimal mode. If you would rather send nothing, disable the component with one line of config. Both are covered below.
How it behaves
-
- Mechanism: a Kubernetes CronJob, deployed like any other manifest at /var/lib/rancher/rke2/server/manifests/rke2-security-responder.yaml
- Pod lifecycle: each scheduled run creates a new, short-lived Pod. That Pod sends one payload, then terminates. There’s no single Pod running continuously in the background: three times a day, a fresh Pod spins up, does its one job, and is torn down, the same lifecycle as any other CronJob-managed workload in your cluster. You can confirm this yourself with kubectl get pods -n kube-system -l job-name around a scheduled run.
- Frequency: three times a day (0 */8 * * *)
- Mode: There are two options: “recommended” (default) and “minimal”. The latter reduces the report by redacting node counts, resource totals and Rancher version.
- Offline clusters: if the request fails, whether air-gapped, disconnected, or any other reason, it just doesn’t send that round. No retries, no queueing, no error surfaced. Losing a data point costs nothing.
- Default: on, starting v1.37. We chose default-on because the CVE/upgrade information is only useful if it’s actually running: an opt-in feature that stays unconfigured provides the benefit to no one. If you’d rather it be off, see below.
Changing default options
It is possible to change the default behavior by using a `HelmChartConfig`. The `HelmChartConfig` must be named `rke2-security-responder` and be created in the `kube-system` namespace.
For example, if we want to change the mode to “minimal” and run it once a day at 3am:
Turning it off with one line
One line in your RKE2 config:
Restart or roll the node and it’s gone, with no residual data collection and nothing left running.
How to verify this yourself
- The client is open source: github.com/rancher/rke2-security-responder
- You can inspect the payload directly by reading the manifest and watching the CronJob’s traffic on your own cluster. Nothing here is hidden inside a binary
Typical output
You can view the responder’s output in the logs of the Pod created for a scheduled run. A successful response can look like this:
The messages indicate the following:
– `response received` confirms that the endpoint responded. `versions` is the total number of versions returned, `newer` is the number newer than the running RKE2 version, and `intervalMinutes` is the server-provided recommendation for the next check interval.
– The `warning` message indicates that the running RKE2 version has known CVEs and lists the five most relevant CVEs.
– Each `available version` message identifies a newer RKE2 release, its release date, and a link to its release notes. Upgrade to a release that addresses the reported vulnerabilities.
Tell us what you think
We want feedback on this component, including on the decision to ship it on by default. Open an issue or join the discussion on ADR 010.
Running RKE2 in production? SUSE Rancher Prime adds enterprise support and long-term support options for RKE2, plus centralized management, policy, and security across every Kubernetes cluster you run. Or talk to a SUSE expert.