Skip to main content

More Info:

Verifies pods are owned by a controller (Deployment, StatefulSet, DaemonSet, Job). A naked pod is not rescheduled if its node dies.

Risk Level

Low

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. Identify naked pods (run on any machine with kubectl access):
  2. For each naked pod, export its manifest (run on any machine with kubectl access):
  3. Convert the pod manifest into a controller manifest (run on any machine with kubectl access; edit with your editor of choice):
    • Open the exported file:
    • Change the top-level kind: Pod to an appropriate controller, e.g.:
      • For a stateless app: kind: Deployment, apiVersion: apps/v1
      • For a singleton: kind: Deployment with spec.replicas: 1
      • For node-wide: kind: DaemonSet, apiVersion: apps/v1
    • Wrap the existing pod spec under the controller spec, for example for a Deployment:
    • Remove fields that are not valid under a template (e.g. status:, metadata.resourceVersion, metadata.uid, metadata.selfLink, metadata.creationTimestamp).
  4. Apply the new controller and delete the naked pod (run on any machine with kubectl access):
  5. Confirm the controller created replacement pods and workloads are healthy (run on any machine with kubectl access):
  6. Re-run the audit to verify no remaining naked pods (run on any machine with kubectl access):
On any machine with kubectl access:
  1. Identify naked pods (no controller ownerReference, excluding core namespaces):
  1. For each reported pod, export its spec and remove fields that must not be in a controller template, then wrap it in a Deployment (example for default myapp-pod):
Adjust the generated myapp-deployment.yaml as needed (labels, replicas, affinity, etc.), then create the Deployment:
  1. Once the new controller-created pod is Running and Ready, delete the original naked pod:
  1. Repeat steps 2–3 for every naked pod, choosing the appropriate controller type (Deployment/StatefulSet/DaemonSet/Job) and adapting the manifest kind and spec accordingly.
  2. Verification (same logic as the audit):