Skip to content

docs: add docs on kspp and cis hardening#480

Open
Iheanacho-ai wants to merge 1 commit intosiderolabs:mainfrom
Iheanacho-ai:kspp
Open

docs: add docs on kspp and cis hardening#480
Iheanacho-ai wants to merge 1 commit intosiderolabs:mainfrom
Iheanacho-ai:kspp

Conversation

@Iheanacho-ai
Copy link
Copy Markdown
Member

fixes #468 and #84

@Iheanacho-ai Iheanacho-ai marked this pull request as draft April 8, 2026 15:24
@talos-bot talos-bot moved this to In Review in Planning Apr 8, 2026
Signed-off-by: Amarachi Iheanacho <amarachi.iheanacho@siderolabs.com>
@Iheanacho-ai Iheanacho-ai marked this pull request as ready for review April 8, 2026 18:19
To verify the active kernel command line on a node:

```bash
talosctl read /proc/cmdline --nodes <node-ip>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't work in Omni but I think there's an omnictl command to get the kernel args

Talos follows the recommendations of the Kernel Self-Protection Project (KSPP), a Linux kernel initiative that eliminates entire classes of vulnerabilities through kernel configuration and runtime settings.

Kernel hardening in Talos operates at three levels:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you're missing a step for build time security. There is hardening we do in the kernel config that can't be changed after the kernel has been built and adds security. Things like not allowing kernel modules to be loaded by userspace processes.


- **Kernel module signature verification (`module.sig_enforce=1`)**: This control allows only cryptographically signed modules to be loaded into the kernel. It ensures that anything entering the kernel can be traced back to a trusted source, preventing tampering via unsigned drivers, a common persistence technique in compromised systems.

- **Process memory write restriction (`proc_mem.force_override=never`)**: Building on that same principle of limiting what can influence running code, this control prevents any process from writing to /proc/PID/mem of another process. Without it, a compromised process could modify another process's memory directly, a technique commonly used in process injection attacks.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was added in 1.13


Every check in section 1.1 will fail on Talos. This section is entirely concerned with file permissions and ownership of control plane configuration files, things like pod specification files and PKI certificates. kube-bench expects to find these at paths like `/etc/kubernetes/manifests/` and `/etc/kubernetes/pki/`, which is where kubeadm-based clusters store them.

Talos does not use static pod manifests to run control plane components. Instead, Talos uses `machined`, its init system, specially designed to run Kubernetes, to manage system-level services including `etcd`, `kubelet`, and the container runtime. Talos services run under the `system` namespace in containerd, separate from Kubernetes workloads. PKI is managed by `trustd`, Talos's dedicated trust daemon, which handles certificate distribution across the cluster. This means the manifest files and PKI paths kube-bench looks for simply do not exist, not because the controls are missing, but because Talos's architecture does not require them.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Talos actually does use static pod manifests for control plane components (scheduler, controller-manager, etc). Only etcd and kubelet are started by machined


Many organizations need to run CIS benchmarks on a regular cadence and produce audit reports. Because the **section 1.1** and several **section 1.2** failures on Talos are architectural false positives rather than real security gaps, including them in a report creates noise and requires manual explanation each time.

kube-bench supports a `--skip` flag that lets you exclude specific checks by ID, so the report contains only results that are meaningful for Talos clusters.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we provide an example command with --skip flag so people can run and get an all PASS output?


## OS-level hardening

Talos's architecture eliminates entire categories of OS-level risk that traditional Linux hardening guides address:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're missing SELinux

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: In Review

Development

Successfully merging this pull request may close these issues.

3 participants