Checks

Full control of the resources within a namespace. In some cluster configurations, this is excessive. In others, this is normal (a gitops deployment operator like flux)

Viewing secrets at the namespace scope can lead to escalation if another service account in that namespace has a higher privileged rolebinding or clusterrolebinding bound.

Webhooks can silently intercept or actively mutate/block resources as they are being created or updated. This includes secrets and pod specs.

Ability to add AWS IAM to RBAC bindings via special EKS configmap.

According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

The ports which are lower than 1024 receive and transmit various sensitive and privileged data. Allowing containers to use them can bring serious implications.

Security context controls the allocation of security parameters for the pod/container/volume, ensuring the appropriate level of protection. Relying on default security context may expose vulnerabilities to potential attacks that rely on privileged access.

The NET_RAW capability grants attackers the ability to eavesdrop on network traffic or generate IP traffic with falsified source addresses, posing serious security risks.

The SYS_MODULE capability grants attackers the ability to install and remove kernel modules, posing serious security risks.

HostPath present many security risks and as a security practice it is better to avoid critical host paths mounts.

Binding to anonymous user to any clusterrole or role is a security risk.

Binding to system:masters group to any clusterrole or role is a security risk.

A Gatekeeper policy that references image repositories for prefix-matching is using open-ended and ambiguous pattern, and can potentially match unintended repositories.

Ensure that all containers use images only from trusted registry domains.

Opening up ports to allow connections from the public internet is generally to be avoided. You should restrict access to IP addresses or ranges that are explicitly required where possible.

You should not expose infrastructure to the public internet except where explicitly required

Kubernetes Kubelet authorization configuration is inspected to confirm the mode is not AlwaysAllow.

If authorization settings are absent, the effective mode requires manual verification.

Kubernetes Kubelet is evaluated for X.509 client certificate authentication by checking if its config sets authentication.x509.clientCAFile to validate clients on the HTTPS endpoint.

Kubernetes Node kubeconfig at /etc/kubernetes/kubelet.conf is evaluated for file ownership root:root. The check focuses on who owns the file that defines the kubelet's API client settings and certificates.

Kubernetes Kubelet kubeconfig at /etc/kubernetes/kubelet.conf must have owner-only permissions (0600 or stricter). The check evaluates the file mode to ensure it is not more permissive than 0600.

Kubernetes Kubelet configuration file config.yaml (e.g., /var/lib/kubelet/config.yaml) is evaluated to confirm ownership by root:root when the kubelet uses a config file via --config.

Kubernetes Kubelet configuration file (/var/lib/kubelet/config.yaml) is evaluated for restrictive file permissions. When kubelet uses --config, the file is expected to be owner-only readable/writable (600) or more restrictive.

Kubernetes Kubelet configuration for its HTTPS endpoint is evaluated to ensure anonymous authentication is disabled, requiring authenticated requests (authentication.anonymous.enabled=false).

Kubernetes Kubelet configuration is inspected for the readOnlyPort setting and whether it is set to 0 to disable the unauthenticated HTTP endpoint.