Add documentation about kernel module autoloading security (#15451)
parent
31bd87aea6
commit
5ab1671aa3
|
|
@ -114,6 +114,36 @@ client applications from escaping their containers should use a restrictive pod
|
|||
policy.
|
||||
|
||||
|
||||
### Preventing containers from loading unwanted kernel modules
|
||||
|
||||
The Linux kernel automatically loads kernel modules from disk if needed in certain
|
||||
circumstances, such as when a piece of hardware is attached or a filesystem is mounted. Of
|
||||
particular relevance to Kubernetes, even unprivileged processes can cause certain
|
||||
network-protocol-related kernel modules to be loaded, just by creating a socket of the
|
||||
appropriate type. This may allow an attacker to exploit a security hole in a kernel module
|
||||
that the administrator assumed was not in use.
|
||||
|
||||
To prevent specific modules from being automatically loaded, you can uninstall them from
|
||||
the node, or add rules to block them. On most Linux distributions, you can do that by
|
||||
creating a file such as `/etc/modprobe.d/kubernetes-blacklist.conf` with contents like:
|
||||
|
||||
```
|
||||
# DCCP is unlikely to be needed, has had multiple serious
|
||||
# vulnerabilities, and is not well-maintained.
|
||||
blacklist dccp
|
||||
|
||||
# SCTP is not used in most Kubernetes clusters, and has also had
|
||||
# vulnerabilities in the past.
|
||||
blacklist sctp
|
||||
```
|
||||
|
||||
To block module loading more generically, you can use a Linux Security Module (such as
|
||||
SELinux) to completely deny the `module_request` permission to containers, preventing the
|
||||
kernel from loading modules for containers under any circumstances. (Pods would still be
|
||||
able to use modules that had been loaded manually, or modules that were loaded by the
|
||||
kernel on behalf of some more-privileged process.)
|
||||
|
||||
|
||||
### Restricting network access
|
||||
|
||||
The [network policies](/docs/tasks/administer-cluster/declare-network-policy/) for a namespace
|
||||
|
|
|
|||
Loading…
Reference in New Issue