kubectl

Kubectl

Purpose

Use this skill for tightly scoped Kubernetes validation when the engagement includes approved cluster access.

Phase Fit

• Primary: Discovery and Reconnaissance, Vulnerability Analysis
• Secondary: Validation and Controlled Impact Demonstration, Retest and Closure

Use When

• Need to confirm cluster resources, namespaces, or RBAC scope.
• Need to validate what an approved identity can view or administer.
• Need a low-impact retest after Kubernetes hardening.

Avoid When

• Cluster scope or kubeconfig authorization is unclear.
• Commands would change workloads or state without explicit approval.

Inputs

• Approved cluster context
• Namespace and RBAC scope
• Read-only versus mutating boundaries

Procedure

1. Confirm the active cluster and namespace context.
2. Start with resource and RBAC inspection.
3. Keep queries tightly aligned to the current hypothesis.
4. Prefer read-only validation over workload changes.
5. Preserve the exact context and namespace for retest.

Command Syntax

Replace sample contexts and namespaces with approved in-scope values.

# Show current context
kubectl config current-context

# List all pods across all namespaces
kubectl get pods --all-namespaces

# List secrets in a namespace
kubectl get secrets -n default

# Read secret content (base64 encoded)
kubectl get secret <secret-name> -n default -o jsonpath='{.data}'

# Check what permissions the current service account has
kubectl auth can-i --list -n default

# Check permissions for a specific service account
kubectl auth can-i --list --as=system:serviceaccount:default:default

# Exec into a running pod
kubectl exec -it <pod-name> -n default -- /bin/sh

# Get pod manifest (look for sensitive env vars)
kubectl get pod <pod-name> -n default -o yaml

# List cluster role bindings
kubectl get clusterrolebindings -o wide

Evidence to Capture

• Effective Kubernetes identity and RBAC scope
• Workload or secret exposure that materially affects risk
• Exact cluster context and namespace used

Safety Boundaries

• Default to read-only validation.
• Do not modify workloads, secrets, or RBAC without explicit written approval.