Kubernetes manifest files are the blueprint of your container infrastructure, but they're also a common source of security vulnerabilities. A single misconfigured YAML file can expose your entire cluster to attack. This comprehensive checklist covers the essential security items every engineering team should verify when reviewing Kubernetes manifests, from RBAC configurations to network policies and resource constraints.

Key Takeaways

•Security by design: Implement security controls in your Kubernetes manifests from day one. Review RBAC permissions, pod security contexts, and network policies before deployment.
•Automate security checks: Use tools like OPA Gatekeeper, Falco, and kubectl-score to catch misconfigurations early in the development process.
•Follow principle of least privilege: Grant minimal necessary permissions, use non-root containers, and implement proper resource limits to reduce blast radius.

Essential Pod Security Configuration

Pod security is the foundation of Kubernetes security. Every container in your cluster should run with the minimum privileges necessary to function properly.

Security Context Checklist

✅ Critical Security Context Items

runAsNonRoot: true - Never run containers as root user

runAsUser: > 1000 - Specify explicit non-root user ID

allowPrivilegeEscalation: false - Prevent privilege escalation

readOnlyRootFilesystem: true - Make root filesystem read-only

capabilities.drop: [ALL] - Drop all Linux capabilities by default

💡 Pro Tip

Use Pod Security Standards (PSS) to enforce these configurations cluster-wide. The "restricted" profile covers most of these requirements automatically.

Example Secure Pod Configuration

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    runAsGroup: 1001
    fsGroup: 1001
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: my-app:v1.2.3
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    resources:
      limits:
        memory: "512Mi"
        cpu: "500m"
      requests:
        memory: "256Mi"
        cpu: "250m"

RBAC Security Review

Role-Based Access Control (RBAC) is your first line of defense against unauthorized access. Every service account should have the minimum permissions needed to function.

RBAC Best Practices Checklist

🚫 Avoid These Dangerous Permissions

✗resources: ["*"]
✗verbs: ["*"]
✗cluster-admin binding
✗system:masters group

✅ Secure Permission Patterns

✓Specific resource names
✓Minimal required verbs
✓Namespace-scoped roles
✓Service-specific accounts

Secure RBAC Example

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-service-account
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["app-secret"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: app-service-account
  namespace: production
roleRef:
  kind: Role
  name: app-role
  apiGroup: rbac.authorization.k8s.io

Network Security Configuration

Network policies are essential for implementing defense in depth. They control traffic flow between pods and external resources, reducing the attack surface.

Network Policy Security Checklist

🔒 Default Deny Policy

Start with a default deny-all policy, then explicitly allow required traffic. This ensures no unintended communication paths exist.

📝 Ingress and Egress Rules

• Define specific source and destination pods using labels
• Restrict ports to only those required for functionality
• Use namespace selectors to isolate environments
• Block egress to cluster metadata endpoints (169.254.169.254)

Example Network Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-app-netpol
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: web-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  - to: []
    ports:
    - protocol: TCP
      port: 443  # HTTPS only for external calls

Resource Management and Limits

Proper resource management prevents resource exhaustion attacks and ensures cluster stability. Every container should have both requests and limits defined.

Resource Security Guidelines

Resource Type	Security Requirement	Recommended Values
CPU Limits	Prevent CPU exhaustion attacks	500m-2000m
Memory Limits	Prevent memory bombs and OOM kills	256Mi-2Gi
Storage Limits	Prevent disk space exhaustion	1Gi-10Gi
Process Limits	Control fork bombs	1024 PIDs max

Secrets and Configuration Management

Proper secrets management is crucial for maintaining security. Never store sensitive data in plain text or container images.

Secrets Security Checklist

🚫 Never Do This

• Store secrets in environment variables
• Hard-code credentials in YAML files
• Use default service account tokens
• Mount secrets with world-readable permissions
• Store secrets in ConfigMaps

✅ Security Best Practices

• Use Kubernetes Secrets with proper RBAC
• Implement external secret management (Vault, AWS Secrets Manager)
• Enable encryption at rest for etcd
• Use volume mounts with restrictive permissions
• Rotate secrets regularly

Secure Secret Configuration

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
  namespace: production
type: Opaque
data:
  database-password: <base64-encoded-value>
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app:v1.2.3
        volumeMounts:
        - name: secret-volume
          mountPath: "/etc/secrets"
          readOnly: true
      volumes:
      - name: secret-volume
        secret:
          secretName: app-secrets
          defaultMode: 0400  # Read-only for owner only

Image Security and Supply Chain

Container images are a common attack vector. Implementing image security controls helps prevent supply chain attacks and reduces vulnerabilities.

Image Security Requirements

🔍

Image Scanning

Scan all images for known vulnerabilities before deployment

📝

Image Signing

Use tools like Cosign to verify image authenticity and integrity

🏷️

Immutable Tags

Use specific version tags or SHA digests, never "latest"

🔒

Private Registries

Use private container registries with proper access controls

Automated Security Tools

Integrate automated security tools into your CI/CD pipeline to catch misconfigurations before they reach production.

Recommended Security Tools

OPA Gatekeeper

Policy enforcement for Kubernetes resources

• Enforce security policies

• Validate manifests at admission

• Custom constraint rules

Falco

Runtime security monitoring

• Detect runtime anomalies

• Monitor system calls

• Alert on suspicious activity

kube-score

Static analysis for Kubernetes manifests

• Security best practice checks

• Resource optimization

• CI/CD integration

Security Review Checklist Summary

📋 Complete Review Checklist

Pod Security: Non-root user, read-only filesystem, dropped capabilities

RBAC: Minimal permissions, no wildcards, service-specific accounts

Network Policies: Default deny, explicit allow rules, egress controls

Resource Limits: CPU/memory limits set, prevent resource exhaustion

Secrets Management: Proper mounting, external secret stores, rotation

Image Security: Vulnerability scanning, signed images, immutable tags

Automated Tools: Policy enforcement, runtime monitoring, static analysis

🔒 Secure Kubernetes deployments start with secure manifests.

Kubernetes Manifest Code Review: Security and Best Practices Checklist