Is Your Kubernetes Setup Secure? A Complete Best‑Practice Checklist

Application Deployment

Health Checks

readiness probe – determines when a container can receive traffic.

liveness probe – determines when a container should be restarted.

Container Readiness Probe

If no readiness probe is set, kubelet assumes the application is ready immediately after container start.

Fatal Errors and Container Crash

Uncaught exceptions, typo‑related crashes in dynamic languages, and failure to load headers or dependencies should cause the container to exit so kubelet can restart it.

Passive Liveness Probe Configuration

Liveness probes should restart containers that become stuck, such as infinite loops that consume 100 % CPU and prevent readiness checks.

Difference Between Liveness and Readiness Probes

When both probes target the same endpoint they act as a single check; kubelet will detach the container from the service if it is not ready.

Application Independence

Readiness probes must not depend on downstream services like databases, APIs, or third‑party services, because failures can cascade and cause downtime.

Re‑connecting to Dependent Services

Applications should keep trying to reconnect to dependencies (e.g., databases) instead of exiting on initial failure.

Graceful Shutdown

On SIGTERM, stop accepting new connections, finish in‑flight requests, kill keep‑alive connections, and then exit; ensure the pod endpoint is removed from the service.

Fault Tolerance

Physical hardware failures

Cloud provider or hypervisor issues

Kernel panics

Run multiple replicas using Deployments, DaemonSets, ReplicaSets, or StatefulSets, and spread pods across nodes with anti‑affinity rules.

Pod Disruption Budgets

Define a PDB to guarantee a minimum number of pods remain available during node drains or other disruptions.

Resource Usage

Set memory limits and requests for all containers.

Set CPU requests to ≤ 1 CPU unless a compute‑intensive job requires more.

Avoid CPU limits unless you have a strong use case.

Use LimitRange in namespaces to provide default limits.

Configure appropriate QoS classes to influence eviction decisions.

Labeling Resources

Apply technical tags (name, instance, version, component, part, manager) and business/security tags (owner, project, business‑unit, confidentiality, compliance) to pods and other objects.

Logging

Log to stdout/stderr for passive collection; use active logging only when necessary and avoid sidecar loggers if the application can emit proper formats.

Scaling

Never store state on the container’s local filesystem; use PersistentVolumes or external storage. Use Horizontal Pod Autoscaler (HPA) for variable workloads, avoid Vertical Pod Autoscaler (VPA) in production, and enable Cluster Autoscaler for node‑level scaling.

Configuration and Secrets

Externalize configuration with ConfigMaps and store sensitive data in Secrets, mounting Secrets as volumes rather than environment variables.

Governance

Namespace Limits

Enforce ResourceQuota and LimitRange to cap CPU, memory, storage, and object counts per namespace.

Pod Security Policies

Restrict host process/network namespace access.

Disallow privileged containers.

Run containers with read‑only filesystems.

Avoid running containers as root.

Limit Linux capabilities and prevent privilege escalation.

Network Policies

Define NetworkPolicy objects to control pod‑to‑pod traffic within and across namespaces, effectively creating a firewall for the cluster.

RBAC

Disable automatic mounting of the default ServiceAccount, grant only the minimum privileges needed, and create distinct roles such as ReadOnly, PowerUser, Operator, Controller, and Admin.

Custom Policies

Use Open Policy Agent to restrict image sources to trusted registries and enforce unique, approved hostnames for Ingress resources.

Cluster Configuration

Approved Kubernetes Settings

Follow the CIS Kubernetes Benchmark; tools like kube-bench can automate checks. Disable anonymous auth, insecure ports, and profiling, and ensure the API server runs with secure settings.

Authentication

Prefer ServiceAccount tokens for workloads, use OpenID Connect (OIDC) for user SSO, and avoid static tokens, basic auth, and other insecure methods.

Logging Strategy

Retain logs for 30‑45 days, collect logs from nodes, control plane, and audit logs, and use a daemonset (not sidecars) to gather logs, forwarding them to a central aggregation system such as the EFK stack or cloud‑native solutions.