SPIKE: Research and evaluate best practices policies and compare to existing available policies

Evaluate best practices policies upstream and existing policies and suggest which policies to enable.

If there is a similar policy upstream, most of the cases are implemented differently and not the same.

Upstream Best Practices policies	Description	Corresponding policies in BB
add-network-policy	This policy will create a new NetworkPolicy resource named `default-deny` which will deny all traffic anytime a new Namespace is created.	No similar policy in BB. Istio has similar policy, does this mean this policy is handled by Istio??
add-networkpolicy-dns	Add Network policy for DNS	No similar policy in BB.
add-ns-quota	This policy will generate ResourceQuota and LimitRange resources when a new Namespace is created.	No similar policy in BB.
add-rolebinding	This policy generates a RoleBinding called `<userName>-admin-binding` in the new Namespace which binds to the ClusterRole `admin` as long as a `cluster-admin` did not create the Namespace. Additionally, an annotation named `kyverno.io/user` is added to the RoleBinding recording the name of the user responsible for the Namespace's creation.	No similar policy in BB.
add-safe-to-evict	The Kubernetes cluster autoscaler does not evict pods that use hostPath or emptyDir volumes. To allow eviction of these pods, the annotation cluster-autoscaler.kubernetes.io/safe-to-evict=true must be added to the pods.	No similar policy in BB.
check-deprecated-apis	This policy validates for APIs that are deprecated or scheduled for removal.	disallow-deprecated-apis
disallow-cri-sock-mount	This policy validates that the sockets used for CRI engines Docker, Containerd, and CRI-O are not used.	No similar policy in BB.
disallow-default-namespace	This policy validates that Pods specify a Namespace name other than `default`. Rule auto-generation is disabled here due to Pod controllers need to specify the `namespace` field under the top-level `metadata` object and not at the Pod template level.	disallow-namespaces.yaml
disallow-empty-ingress-host	An ingress resource needs to define an actual host name in order to be valid. This policy ensures that there is a hostname for each rule defined.	No similar policy in BB.
disallow-helm-tiller	Tiller can lead to privilege escalation as restricted users can impact other users. It is recommended to use Helm v3+ which does not contain Tiller for these reasons. This policy validates that there is not an image containing the name `tiller`.	No similar policy in BB.
disallow-latest-tag	The ':latest' tag is mutable and can lead to unexpected errors if the image changes. A best practice is to use an immutable tag that maps to a specific version of an application Pod. This policy validates that the image specifies a tag and that it is not called `latest`.	disallow-image-tags
require-drop-all	Capabilities permit privileged actions without giving full root access. All capabilities should be dropped from a Pod, with only those required added back. This policy ensures that all containers explicitly specify the `drop: ["ALL"]` ability. Note that this policy also illustrates how to cover drop entries in any case although this may not strictly conform to the Pod Security Standards.	add-default-capability-drop - similar but different
require-drop-cap-net-raw	This policy ensures that all containers explicitly drop the CAP_NET_RAW ability. Note that this policy also illustrates how to cover drop entries in any case although this may not strictly conform to the Pod Security Standards.	No similar policy in BB.
require-labels	Define and use labels that identify semantic attributes of your application or Deployment. A common set of labels allows tools to work collaboratively, describing objects in a common manner that all tools can understand. The recommended labels describe applications in a way that can be queried. This policy validates that the label `app.kubernetes.io/name` is specified with some value.	require-labels
require-pod-requests-limits	This policy validates that all containers have something specified for memory and CPU requests and memory limits.	require-cpu-limit, require-memory-limit at container level
require-probes	Liveness and readiness probes need to be configured to correctly manage a Pod's lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic `livenessProbe` is performed by the kubelet to determine if the Pod's containers are running or need to be restarted. A `readinessProbe` is used by Services and Deployments to determine if the Pod is ready to receive network traffic. This policy validates that all containers have one of livenessProbe, readinessProbe, or startupProbe defined.	require-probes different than bb. bb has not check for startupProbe
require-ro-rootfs	A read-only root file system helps to enforce an immutable infrastructure strategy; the container only needs to write on the mounted volume that persists the state. An immutable root filesystem can also prevent malicious binaries from writing to the host system. This policy validates that containers define a securityContext with `readOnlyRootFilesystem: true`.	require-ro-rootfs
restrict-image-registries	Images from unknown, public registries can be of dubious quality and may not be scanned and secured, representing a high degree of risk. Requiring use of known, approved registries helps reduce threat exposure by ensuring image pulls only come from them. This policy validates that container images only originate from the registry `eu.foo.io` or `bar.io`. Use of this policy requires customization to define your allowable registries.	restrict-image-registries
restrict-node-port	A Kubernetes Service of type NodePort uses a host port to receive traffic from any source. A NetworkPolicy cannot be used to control traffic to host ports. Although NodePort Services can be useful, their use must be limited to Services with additional upstream security checks. This policy validates that any new Services do not use the `NodePort` type.	disallow-nodeport-services
restrict-service-external-ips	Service externalIPs can be used for a MITM attack (CVE-2020-8554). Restrict externalIPs or limit to a known set of addresses. See: https://github.com/kyverno/kyverno/issues/1367. This policy validates that the `externalIPs` field is not set on a Service.	restrict-external-ips

Edited Oct 15, 2025 by Daniel Chen