Kubernetes Skills
SuspiciousAudited by ClawScan on May 10, 2026.
Overview
This is a coherent Kubernetes multi-cluster helper, but it can use cluster credentials to read secrets and make production-impacting changes across clusters without clear guardrails.
Install only if you intend to let the agent help administer Kubernetes clusters. Prefer read-only kubeconfigs first, keep production/admin contexts separate, require confirmation for any change, and review the exact target context and namespace before scaling, deploying, reconciling, or copying secrets.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A mistaken or overly broad agent action could change production workloads, cluster capacity, or secrets in the wrong cluster.
The skill documents tools that can scale clusters, deploy Helm charts to production, and apply manifests to another cluster. These are purpose-aligned for Kubernetes administration, but they are high-impact mutations without clearly stated approval, dry-run, rollback, or scope limits.
capi_machinedeployment_scale_tool(... replicas=5) ... install_helm_chart(... context="production-cluster") ... apply_manifest(secret_manifest, namespace="app", context="target-cluster")
Use least-privilege/read-only contexts by default, require explicit user confirmation before apply/scale/install/reconcile actions, and add context/namespace allowlists plus dry-run and rollback guidance.
The agent may be able to authenticate to clusters, use admin contexts, retrieve cluster access credentials, or expose credentials if outputs are mishandled.
The skill relies on Kubernetes identity material and can retrieve workload cluster kubeconfigs. That access is expected for this purpose, but it is high-impact credential authority and is not clearly bounded or declared in the metadata.
A kubeconfig context combines: ... **User**: Authentication credentials ... kubeconfig = capi_cluster_kubeconfig_tool(...) ... # (save to file, add to contexts)
Declare the kubeconfig/cluster credential requirement, use short-lived least-privilege service accounts, avoid admin contexts unless explicitly requested, and redact or avoid displaying kubeconfigs and tokens.
A bad manifest, chart, or secret could be rolled out to multiple clusters instead of being contained to one environment.
The documented patterns intentionally repeat changes across multiple production regions and synchronize secrets between clusters. This is coherent with multi-cluster management, but mistakes can propagate broadly.
for region in ["us-east", "us-west", "eu-west"]: install_helm_chart(... context=f"production-{region}") ... Cross-Cluster Secret Sync ... apply_manifest(secret_yaml, namespace="app", context="target-cluster")Stage changes one cluster at a time, verify health between steps, require explicit per-cluster confirmation for production, and keep audit logs for cross-cluster operations.