kube-medic
v1.0.3Kubernetes Cluster Triage & Diagnostics — instant AI-powered incident triage via kubectl
⭐ 2· 952·8 current·9 all-time
byTodd Kuehnl@tkuehnl
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The skill's name/description (kubernetes triage via kubectl) matches the included script and SKILL.md: the tool runs kubectl queries for nodes, pods, events, logs, deployments and correlates results. However the registry metadata at the top lists "Required binaries: none" while the SKILL.md and scripts clearly depend on kubectl and jq. This inconsistency is small but important: the skill will not work (and will try to access your cluster) unless kubectl/jq are present and kubectl is configured.
Instruction Scope
The runtime instructions tell the agent to run the packaged shell script which executes many kubectl read operations (get, describe, logs, top, events) and returns structured JSON. That behavior is expected for diagnostics, but it means the agent will fetch pod logs and other cluster state which may contain sensitive data (PII, secrets, tokens in logs). The SKILL.md/SECURITY.md acknowledge this, but the instructions do not enforce automatic redaction — they rely on the user to scope RBAC or namespaces. Also the script accepts a --confirm-write string which will be executed after validation; we could not fully review the write-validation code because the provided script is truncated, so there remains uncertainty about whether the write gate is implemented correctly in every edge case.
Install Mechanism
This is an instruction-only skill with an included shell script; there is no install spec that downloads remote code. That keeps disk/write risk low. The script itself is included in the bundle (scripts/kube-medic.sh) so you can review it locally before running.
Credentials
The skill requests no environment variables or external credentials in registry metadata, which is appropriate. It does, however, rely on the user's existing kubectl configuration (kubeconfig) to access clusters — which implicitly grants access to cluster credentials. This is expected for a kubectl-based tool but is high-scope: the skill will use whatever kubectl context the agent is running under. No extra unrelated secrets are requested, which is good.
Persistence & Privilege
The skill is not marked always:true and is user-invocable only. It does support write operations gated behind --confirm-write and an allowlist, which is an appropriate model. Because we could not inspect the full confirm-write validation logic in the truncated script, you should verify the allowlist parsing and that there is no injection path before granting write-level RBAC to this skill.
What to consider before installing
What to consider before installing:
- Functional fit: kube-medic legitimately needs kubectl and jq and access to your kubeconfig/context. The registry metadata incorrectly states "no required binaries"; expect to have kubectl and jq installed and configured.
- Sensitive data: the skill fetches pod logs and cluster events and passes them to the LLM for analysis. Logs can contain PII, secrets, or internal URLs. Restrict pods/log permission with RBAC, use the --namespace flag to scope queries, and avoid running the skill against production until you are comfortable.
- RBAC practice: start with a read-only ClusterRole (the SECURITY.md provides one). Only bind the write ClusterRole if you trust the write allowlist and the implementation. Prefer testing in a disposable cluster (kind/minikube) first.
- Review the code: because the runtime is a shell script included in the skill, review scripts/kube-medic.sh in full with attention to the confirm-write parsing/validation. The provided materials claim a strict allowlist and no shell-eval of user input, but the script was truncated in the supplied files so this could not be fully confirmed.
- Validation steps: (1) Inspect the remaining script content, especially the confirm-write branch and any command-building logic. (2) Run the tool in a non-production test cluster with minimal permissions. (3) Verify that outputs never echo kubeconfig paths or token values in your tests.
If you want, provide the rest of scripts/kube-medic.sh (the truncated portion) or ask me to look specifically at the confirm-write code path and I will re-evaluate; that could raise confidence to high or allow a benign verdict.Like a lobster shell, security has layers — review code before you run it.
latestvk97aff92ak381apye42100m00581j0d9
License
MIT-0
Free to use, modify, and redistribute. No attribution required.