Using Claude for Kubernetes Manifest Reviews

1. Why Kubernetes manifests especially need review

A Kubernetes manifest usually starts successfully even when important hardening measures are missing: no resource limit, no restrictive security context, no meaningful readiness probe. The pod runs, the rollout reports success, and the problem only shows up when a single faulty pod destabilizes the entire node through unbounded memory consumption, or when a compromised container gains access to the whole cluster network thanks to missing restrictions. Claude for Kubernetes manifest reviews addresses exactly this gap: it checks YAML definitions systematically against established best practices before they are applied.

The value of such a review lies in the fact that many hardening mistakes repeat structurally and are therefore well suited to automated detection. Claude for Kubernetes manifest reviews knows the common patterns from official Kubernetes documentation and CIS benchmark recommendations and applies them consistently to every submitted manifest, regardless of whether it was written by hand or rendered from a Helm chart. The following sections show concrete review categories, from resource limits through security contexts to RBAC roles.

2. Checking resource limits and requests with Claude

A container without defined resources.limits can in theory claim all the available memory or CPU of a node and thereby crowd out other pods on the same node. Claude for Kubernetes manifest reviews checks every container spec for whether both requests and limits are set for CPU and memory, and points it out when a manifest is submitted entirely without these fields, which happens alarmingly often in grown clusters.

Beyond mere presence, Claude also evaluates the ratio between requests and limits: too large a gap between the two values leads to overcommitment at the node level, which can cause OOM kills during load spikes even though the scheduler has computationally promised enough capacity. Claude suggests setting requests realistically close to typical consumption and limits with a reasonable buffer, instead of setting both values identically or arbitrarily far apart.

# BEFORE — no resource limits, can starve the node
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
      - name: api
        image: myregistry/api:1.4.0

# AFTER — Claude-suggested resource governance
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
      - name: api
        image: myregistry/api:1.4.0
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

3. Matching security contexts against hardening standards

The default security context of a Kubernetes container is more permissive than desirable in most production environments: containers run as root by default, the root filesystem is writable, and privilege escalation is not explicitly disabled. Claude for Kubernetes manifest reviews checks every securityContext block for missing hardening settings and suggests concrete additions: runAsNonRoot: true, an explicitly set runAsUser, readOnlyRootFilesystem: true where possible, and allowPrivilegeEscalation: false.

Reviewing capabilities is especially valuable: many containers do not need any of the standard Linux capabilities that Kubernetes grants without explicit restriction. Claude suggests dropping all capabilities with drop: ["ALL"] and adding back only the ones actually needed via add, for instance NET_BIND_SERVICE for a web server that needs to listen on a privileged port. This approach substantially reduces the attack surface of a compromised container.

# Hardened security context suggested by Claude
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE   # only if binding to a privileged port is required
  seccompProfile:
    type: RuntimeDefault

4. Validating liveness, readiness, and startup probes

Misconfigured probes are one of the most common causes of seemingly random instability in Kubernetes deployments. A liveness probe that is configured too aggressively, for instance with too short a periodSeconds and too few failureThreshold attempts, causes Kubernetes to keep restarting healthy but briefly slow pods. Claude for Kubernetes manifest reviews checks the interplay of all three probe types and points it out when liveness and readiness probes are configured identically even though they should serve different purposes.

A frequently overlooked problem: applications with long startup times, for instance Java applications with extensive initialization, get prematurely flagged as unhealthy and restarted by the liveness probe before the application has even finished booting up. Claude suggests a dedicated startupProbe in such cases, giving the application enough time to start before liveness and readiness probes become active at all, instead of configuring the liveness probe itself with unrealistically high tolerance values.

# Probes with distinct responsibilities, suggested by Claude
startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  failureThreshold: 30    # allow up to 5 minutes for slow starts
  periodSeconds: 10

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  periodSeconds: 15
  failureThreshold: 3     # only restart after sustained failure

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 2     # remove from service quickly if unready

5. Reviewing NetworkPolicies and service configuration

Without explicit NetworkPolicy resources, most cluster network plugins allow every pod to communicate with every other pod, regardless of namespace boundaries. Claude for Kubernetes manifest reviews points it out when a namespace with sensitive workloads, for example a database, has no restrictive NetworkPolicy, and suggests a default deny policy that is then opened selectively for required connections.

For service definitions, Claude checks whether a service is mistakenly exposed as LoadBalancer or NodePort even though it should only be reachable within the cluster, which unnecessarily creates a public IP address and thus a potential attack surface. The recommendation is then usually to reduce the service type to ClusterIP and, if external access is needed, route it deliberately through an ingress controller with its own access control.

6. Checking RBAC roles for excessive permissions

A common pattern in grown clusters is using ClusterRole bindings with far reaching permissions where a Role restricted to a single namespace would suffice. Claude for Kubernetes manifest reviews reads RBAC manifests and identifies when a ServiceAccount receives permissions that go far beyond what the associated application actually needs, for instance write access to secrets across the entire cluster for an application that only needs to read a single secret in its own namespace.

The analysis works best when Claude receives both the RBAC definition and a short description of the application's actual function, because without this context Claude can only flag unusually broad permissions, not judge whether a specific permission is functionally justified. In practice, this combination of RBAC text and functional description delivers precise, actionable suggestions for the principle of least privilege.

7. Understanding Helm charts and Kustomize overlays with Claude

Many Kubernetes manifests in practice are not written directly but generated from Helm charts with values files or from Kustomize bases with overlays. Claude for Kubernetes manifest reviews helps understand the rendered end result by analyzing helm template or kustomize build output and explaining which values or overlay setting leads to which concrete field in the final manifest. This is especially helpful when a chart comes from a third party and the values file structure is not immediately self explanatory.

For custom Helm charts, Claude also assists in writing templates with sensible defaults, for instance by ensuring that security relevant values like the security context cannot be accidentally overridden without the values author being aware of the consequence. A proven practice Claude often suggests: anchor security critical defaults in the chart itself and only make non critical values configurable through values.

8. Limits: what Claude does not see in the cluster

Claude for Kubernetes manifest reviews works with what is visible in the YAML text, but has no direct access to the running cluster unless this is provided through a tool like kubectl combined with an appropriate integration. Whether a suggested resource limit actually matches the application's real load profile can only be verified through real metrics from a monitoring system like Prometheus, not through pure manifest analysis.

Claude also has no knowledge of cluster specific admission controller rules or pod security standards enforced by an organization beyond the standard Kubernetes mechanisms, unless these are explicitly provided in context. A manifest Claude classifies as safe can still violate a stricter organization specific policy. The sensible division of labor remains: Claude provides a well founded first assessment based on general best practices, final approval requires knowledge of the concrete cluster environment.

9. Manifest review with and without Claude compared

The following table shows typical review categories and how review effort changes with Claude.

Here too the rule applies: Claude speeds up categorization and delivers concrete, actionable suggestions, but does not replace knowledge of the actual cluster environment and organization specific policies.

10. Summary

Claude for Kubernetes manifest reviews delivers the most value on structurally recurring checks: missing resource limits, incomplete security contexts, misaligned probes, and overprivileged RBAC roles. These categories can be checked consistently against established best practices without Claude needing to know the concrete cluster environment in detail. That turns a manual, often skipped review step into a consistent, repeatable part of the deployment process.

The long term value comes from consistency: instead of every developer keeping their own, incomplete checklist in their head, Claude checks every manifest against the same criteria. Final approval still requires human knowledge of organization specific policies and the actual cluster configuration, but the first, thorough look at a new manifest can be reliably delegated.

11. FAQ: Using Claude for Kubernetes Manifest Reviews