diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
index e588ecc3695..7b14d2ae472 100644
--- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
+++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
@@ -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