A single NetworkPolicy with policyTypes [‘Ingress’, ‘Egress’] and only the specified egress rule creates a default-deny for all other traffic (both ingress and egress) for the selected pods, while explicitly allowing the required egress. This is the correct, minimal implementation of a default-deny policy for a pod.

The combination of runAsNonRoot: true (which will prevent running as UID 0) and an explicit runAsUser: 1000 is the most secure and declarative approach. It ensures the pod runs as a specific non-root user and provides a safety net by explicitly rejecting root. Letting the runtime assign a random UID is less predictable for storage/volume permissions.

The principle of least privilege means granting only the necessary permissions. The correct method is to explicitly add the required SYS_TIME capability while explicitly dropping other capabilities (like NET_ADMIN, SYS_ADMIN, etc.) that the container does not need. This is more precise than just adding one capability to a container that may have inherited others.

While not always ideal, directly inspecting the node’s network namespace for the container (using nsenter or similar with the container’s PID) with tools like ss or netstat provides the most immediate and reliable view of active network connections from that container, which is crucial for incident response. Ephemeral containers require the feature gate and may not be available; logs won’t show active connections.

The mutable nature of the ‘latest’ tag is the core security issue. It breaks reproducibility and can lead to unintentional deployment of a new, potentially vulnerable or compromised image. Using an immutable identifier like a SHA256 digest (@sha256:…) ensures the exact, verified image is always deployed.

A LimitRange object defined in a namespace can specify default resource limits (and requests) for Pods. If a Pod is created without a memory limit, the default from the LimitRange is applied automatically. This enforces the requirement at the API level before the Pod is scheduled. (Note: PSP is deprecated; the modern equivalent is the Pod Security Admission controller).

A rule with verbs: [‘*’] and resources: [‘*’] with no other restrictions is equivalent to the cluster-admin role, granting full control over all resources in the cluster. This violates least privilege. The correct approach is to define rules that specify only the required verbs (e.g., [‘get’, ‘list’]) and resources (e.g., [‘pods’, ‘pods/log’]) for the specific debugging tasks.

A primary security advantage is that secrets mounted as volumes (especially as readonly files) are not exposed in the pod’s process environment (e.g., not visible via /proc/[pid]/environ or tools like `env` inside the container). Secrets set as environment variables can be more easily leaked through logging, core dumps, or inspection.

The Kubernetes API server is the brain of the cluster. Unrestricted network access means any attacker who compromises credentials (or finds a vulnerability) can gain full control. The first line of defense is network segmentation: using firewall/security group rules to ensure the API server endpoint (6443) is only accessible from strictly necessary, trusted source IP ranges (e.g., control plane nodes, administrator jump hosts).

A single NetworkPolicy with policyTypes [‘Ingress’, ‘Egress’] and only the specified egress rule creates a default-deny for all other traffic (both ingress and egress) for the selected pods, while explicitly allowing the required egress. This is the correct, minimal implementation of a default-deny policy for a pod.0