Security audit
Security checks for vulnerabilities and agentic risk
This Kubernetes security helper needs review because its audit can miss dangerous administrator access while presenting itself as comprehensive.
Use this as a starting checklist, not proof that a cluster is secure. Before relying on it, correct the binding queries and remove the blanket exclusion of system-prefixed subjects. Select the intended cluster and namespaces, use read-only access for audits, and authorize secret access or configuration changes separately.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Audit RBAC configuration for security issues.
Args:
context: Optional kubeconfig context
Returns:
Dictionary with audit findings
ClusterRoles define permissions, but ClusterRoleBindings identify which subjects receive those permissions; retrieving ClusterRoles cannot establish who has cluster-admin access. In a security-auditing skill, this mismatch can cause excessive privileges to go undetected and create false assurance, although the query itself does not grant access.
The role-binding examples retrieve roles and clusterroles rather than rolebindings and clusterrolebindings, so an audit following these instructions cannot determine which users, groups, or service accounts receive the permissions. This is particularly consequential in a security-auditing skill that prioritizes cluster-admin bindings: excessive privileges could remain undetected while the audit appears complete.
The activation rules include generic terms such as "security", "permissions", "policy", and "who can", which also occur in ordinary requests unrelated to Kubernetes. Although the skill's title and description establish its domain, these explicit matching rules do not require Kubernetes context or exclude unrelated uses.
No suspicious patterns detected.