rules-kubernetes

failureThreshold of 1 or 2 may cause unnecessary restarts during transient slowdowns. Consider 3+ for liveness probes to allow the app to recover without a full restart.

automountServiceAccountToken: true injects the service account token into every pod. If the workload doesn't call the Kubernetes API, set this to false to reduce the blast radius of a compromise.

ClusterRoleBinding to cluster-admin grants full superuser access to every resource in the cluster. Use a scoped Role/RoleBinding with least-privilege permissions instead.

Using the default service account. Create a dedicated service account for each workload with only the permissions it needs.

hostIPC: true grants the container access to the host's IPC namespace (shared memory, semaphores), enabling cross-process data injection and exfiltration. Remove hostIPC or set it to false.

hostNetwork: true shares the host's network namespace, bypassing network policies. Remove it and use Service resources for inter-pod communication.

hostPID: true shares the host PID namespace, allowing the container to see and signal all processes on the node — a trivial container escape path. Remove hostPID or set it to false.

hostPort binds the container directly to the host node's port, limiting scheduling to nodes where that port is free and bypassing network policies. Use a Service of type NodePort or LoadBalancer instead.

Using ':latest' or no image tag makes deployments non-reproducible. Pin to a specific image digest or version tag.

No liveness probe defined. Without a liveness probe, Kubernetes cannot restart containers stuck in a deadlock or infinite loop. Add livenessProbe with appropriate httpGet or exec check.

No readiness probe defined. Without a readiness probe, Kubernetes routes traffic to pods before they are ready to serve requests. Add readinessProbe to avoid serving errors during startup.

No resource limits defined. Without CPU and memory limits, a misbehaving container can starve the entire node. Add resources.limits.cpu and resources.limits.memory.

No securityContext defined on container(s). Without explicit securityContext, containers inherit permissive defaults. Add securityContext with at minimum: runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false.

allowPrivilegeEscalation: true permits processes inside the container to gain more privileges than the parent (e.g., via setuid binaries). Set it to false in every container securityContext.

Privileged pods have root access to the host kernel — equivalent to running as root on every node. Remove 'privileged: true' and use specific capabilities (securityContext.capabilities.add).

runAsUser: 0 runs the container as root. Set runAsNonRoot: true and specify a non-zero runAsUser (e.g., 1000) in the securityContext.

Secret value appears hardcoded in the manifest. Use secretKeyRef to reference a Kubernetes Secret instead: valueFrom.secretKeyRef.name/key

Single-replica Deployment has no availability during node maintenance or rolling updates. Set replicas >= 2 for production workloads to maintain uptime during disruptions.

CAP_SYS_ADMIN is nearly equivalent to root on the host — it allows mounting filesystems, ptrace, namespace manipulation, and many other privilege escalation paths. Remove SYS_ADMIN and use only the specific capabilities your workload requires.

Wildcard resource '*' in RBAC grants access to all Kubernetes resources including secrets. Enumerate only the specific resources needed.

Wildcard RBAC verb '*' grants unrestricted access to the resource. Specify only the verbs your workload actually needs (get, list, watch, create, update, delete).

A writable root filesystem lets an attacker persist payloads across pod restarts and modify binaries. Set readOnlyRootFilesystem: true and mount only specific writable paths via emptyDir or PersistentVolumeClaim.

Granting cluster-admin via RoleBinding or ClusterRoleBinding gives full control over the cluster. Avoid granting this except to core administrators. Use Least Privilege.

Using hostNetwork: true allows a pod to bind to the host's network interfaces, sniffing node traffic and bypassing network policies. This is extremely dangerous.

Running Kubernetes pods with privileged: true allows the container to bypass nearly all security controls and access the host node. Do not use this unless absolutely required (e.g. for CNI plugins or node agents).

Explicitly setting runAsUser: 0 forces a pod to run as the root user. This is a severe security risk. Set runAsNonRoot: true and specify an unprivileged user ID.