Security audit

kubernetes-expert

Security checks for vulnerabilities and agentic risk

Overview

This Kubernetes skill is documentation-only, but it includes examples that could grant or encourage overly broad cluster access to secrets and workloads.

Review this skill carefully before using it to generate production Kubernetes manifests. Treat the examples as drafts only: replace cluster-wide RBAC with namespace-scoped least-privilege roles, avoid listing secrets unless explicitly authorized, enable Redis authentication, pin Helm dependencies, and ensure monitoring endpoints are only exposed inside trusted observability environments.

A.I.G

Vulnerability Patterns

Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions

Findings (4)

T05 · Unauthorized Access and Privilege Escalation

Error

Location: SKILL.md:59
Finding: Cluster-Wide Secret Access Granted to a Namespaced Web Application
Content: View full analysis
Remediation: View remediation

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: SKILL.md:154
Finding: Troubleshooting Guidance Encourages Cluster-Wide Secret Enumeration
Content: View full analysis
``` ### Technical Analysis The troubleshooting section recommends enumerating Secrets across all namespaces without first limiting the operation to the affected workload or establishing a legitimate need for cluster-wide access. Although `kubectl describe secret` normally does not print decoded Secret values, `kubectl get secrets --all-namespaces` reveals sensitive inventory metadata, including Secret names, namespaces, types, and creation information. This metadata can identify service-account credentials, TLS material, registry credentials, database credentials, and other high-value targets. The command also assumes the operator or agent has cluster-wide Secret-listing privileges. Presenting this as routine troubleshooting can normalize excessive privileges and cause an automated agent to access sensitive resources beyond the minimum scope necessary. ### Attack Path 1. An operator or automated agent follows the generic troubleshooting instructions using a privileged kubeconfig. 2. The command inventories Secrets across all namespaces. 3. An attacker with access to the terminal output, logs, or agent transcript obtains the Secret inventory. 4. The attacker identifies high-value namespaces and credential types. 5. The metadata is used to guide subsequent credential-access attempts, namespace compromise, or lateral movement. ### Impact Assessment The command can disclose cluster-wide sensitive-resource metadata and expand the scope of routine diagnostic activity beyond the affected namespace. It does not directly print Secret values, but it facilitates reconnaissance and may expose operational details through ...[truncated 47 chars]
Remediation: View remediation
``` - Begin diagnostics with non-sensitive resources such as pod status, events, and workload configuration. - Check authorization before accessing sensitive resources: ```bash kubectl auth can-i list secrets --namespace ``` - Access only a specifically identified Secret when necessary, and avoid retrieving or decoding Secret data unless required for an approved incident response procedure. - Warn users that command output and agent transcripts may be retained in logs. - Document an escalation process for cases that genuinely require cross-namespace investigation. ]]>

T09 · Insecure Skill Coding Practices

Warning

Location: references/examples.md:414
Finding: Redis Authentication Disabled in Helm Configuration
Content: View full analysis
Remediation: View remediation

T08 · Insecure Dependencies

Note

Location: references/examples.md:354
Finding: Helm Dependencies Use Non-Deterministic Wildcard Versions
Content: View full analysis
Remediation: View remediation

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 93% confidence
Finding: The troubleshooting section includes kubectl get secrets --all-namespaces and kubectl describe secret <secret-name>, which can encourage broad secret enumeration and inspection without any warning about exposing sensitive values or metadata. In a Kubernetes-focused skill, these commands are contextually plausible for diagnostics, but presenting them without guardrails normalizes access to highly sensitive resources and may lead users or downstream agents to retrieve credentials unnecessarily.
Content: No source excerpt is available for this finding.

Missing User Warnings

Low

Category: Not specified by scanner
Confidence: 84% confidence
Finding: This markdown file includes examples that enable Prometheus scraping and later defines ServiceMonitor/Grafana resources, but the surrounding documentation does not warn that these configurations expose application metrics and operational data. For a markdown skill/reference file, user-facing descriptions should disclose behaviors that may affect privacy or system visibility.
Content: No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.