Kubernetes

shellfirm provides two groups of Kubernetes checks: kubernetes (standard) for the most dangerous operations and kubernetes-strict for broader coverage of cluster modifications. Both groups support the kubectl command and the common k alias.

Standard Kubernetes checks (kubernetes)

Delete namespace

Deleting a namespace is one of the most destructive Kubernetes operations -- it removes every resource within it, including deployments, services, config maps, and persistent volume claims.

# Triggers
kubectl delete ns production
kubectl delete namespace staging
k delete ns my-app

# Does NOT trigger (dry-run)
kubectl delete ns staging --dry-run=client

Blast radius example:

The blast radius runs kubectl get all -n <namespace> --no-headers to count actual resources.

Delete all resources

Deleting all resources of a type wipes everything in the namespace.

# Triggers
kubectl delete pods --all
kubectl delete deployments --all -n production
k delete services --all

# Does NOT trigger
kubectl delete pods --all --dry-run=client
kubectl delete pod mypod  # specific pod, not --all

Apply with force

Force-applying deletes and recreates resources, causing downtime.

# Triggers
kubectl apply -f deployment.yaml --force
k apply --force -f pod.yaml

# Does NOT trigger
kubectl apply -f deployment.yaml
kubectl apply -f deployment.yaml --force --dry-run=client
kubectl apply --force-conflicts -f deployment.yaml

Drain node

Draining a node evicts all pods and marks the node unschedulable.

# Triggers
kubectl drain node01
kubectl drain node01 --ignore-daemonsets --delete-emptydir-data
k drain node01

Cordon node

Cordoning prevents new pods from being scheduled on the node.

# Triggers
kubectl cordon node01
k cordon node01

# Does NOT trigger
kubectl uncordon node01

Replace with force

Force-replacing deletes and recreates resources, causing downtime.

# Triggers
kubectl replace -f deployment.yaml --force

# Does NOT trigger
kubectl replace -f deployment.yaml
kubectl replace -f deployment.yaml --force --dry-run=client

Helm checks

Strict Kubernetes checks (kubernetes-strict)

These checks cover broader modification operations. All support the --dry-run filter.

Delete resource

# Triggers
kubectl delete pod my-pod
kubectl delete deployment my-app
k delete svc my-service

# Does NOT trigger
kubectl delete pod my-pod --dry-run=client

Update resource

# Triggers
kubectl set image deployment/my-app app=my-image:v2
k set env deployment/my-app ENV=production

Scale resource

# Triggers
kubectl scale deployment my-app --replicas=0
k scale statefulset db --replicas=3

Rollout management

# Triggers
kubectl rollout restart deployment/my-app
kubectl rollout undo deployment/my-app
k rollout pause deployment/my-app
k rollout resume deployment/my-app

Context-aware escalation

Kubernetes checks are especially powerful when combined with context-aware protection. shellfirm detects the current Kubernetes context via kubectl config current-context and escalates the challenge if it matches a production pattern.

Default production k8s patterns:

• prod
• production
• prd
• live

For example, if your current context is prod-us-east-1:

The challenge was escalated from your default (e.g., Math) to Yes because the k8s context contains "prod".

Configuring production patterns

# In ~/.config/shellfirm/settings.yaml
context:
  production_k8s_patterns:
    - prod
    - production
    - prd
    - live
    - my-company-prod

Dry-run as a safe escape

All Kubernetes checks support the --dry-run filter. This means you can preview any operation without triggering shellfirm:

# These all pass through without challenge
kubectl delete ns staging --dry-run=client
kubectl delete deployment my-app --dry-run=server
kubectl scale deployment my-app --replicas=0 --dry-run=client

This encourages the practice of dry-running destructive operations before executing them.