2.0 KiB
2.0 KiB
| name | description | category | impact |
|---|---|---|---|
| kubernetes-access | Defines workflows for interacting with Kubernetes clusters, depending on whether a valid kubeconfig is present. Emphasizes read-only access and strict IaC adherence. | infra | high |
Kubernetes & Helm Access
🎯 Purpose
Establishes the branching logic for cluster interaction depending on kubeconfig availability, and enforces strict Infrastructure as Code (IaC) principles to prevent configuration drift.
🚨 CRITICAL: The AI NEVER gets direct credentials. Access is strictly governed by the local kubeconfig.
🚨 Prohibitions (Thou Shalt Not)
- NEVER mutate cluster state directly without explicit permission. Do not use
kubectl apply,edit,patch,delete, orhelm install/upgrade. Live cluster changes cause IaC drift. - NEVER ask for credentials.
- NEVER guess the cluster state. Read it if you have access, or ask the user to read it if you don't.
Workflows (Access Check required!)
Before interacting with a cluster, determine if you have access by running a harmless check (e.g., kubectl config current-context or kubectl get nodes).
Scenario A: AI HAS Access (via local kubeconfig)
If the workspace has a valid kubeconfig, the AI CAN run read-only commands directly:
kubectl get <resource>,kubectl describe,kubectl logs,kubectl top- Port-forwarding: Establish port-forwards locally and use
curlto analyze internal HTTP services. - Rule: You are an observer. Find the issue via CLI, but fix the issue in the IaC source files (Helm charts, manifests), not via
kubectl patch.
Scenario B: AI Does NOT Have Access
If no kubeconfig is provided or access is denied, delegate to the user:
- Print the exact
kubectlorhelmcommand for the user. - Explain briefly what the command will do.
- Wait for the user to run it and paste the output.
For detailed debugging workflows and port-forward mechanics, read_file -> .ai/skills/kubernetes-access/REFERENCE.md.