Security audit
Security checks for vulnerabilities and agentic risk
The skill says it is read-only network diagnosis, but its shipped dispatcher can run broad cloud administration actions and expose Kubernetes secrets.
Review before installing. Do not run this with production or write-capable Huawei/Kubernetes credentials unless the publisher first restricts the dispatcher to the documented read-only network actions, removes Secret data access and administrative actions, pins dependencies, and fixes certificate/TLS handling. If it has already been used with real credentials, consider rotating exposed credentials and checking agent logs for secret output.
scripts/huawei_cloud/dispatcher.py:1469Read-only diagnostic entry point exposes destructive cloud administration actions
scripts/huawei_cloud/cce.py:3313Kubernetes Secret payloads can be enumerated and returned through the dispatcher
scripts/huawei_cloud/cce.py:3374CCE client private keys use predictable temporary files while TLS verification is disabled
scripts/huawei_get_node_security_groups.py:139Huawei account passwords and access keys are accepted through command-line arguments
references/verification-method.md:16Runtime dependency installation is unpinned and references missing validation scripts
The scale_workload function obtains kubeconfig and directly patches deployment replica counts, which changes live cluster state. In a diagnosis skill, this creates a high-risk path for unintended or unauthorized modifications that can cause outages, cost increases, or disruption of production workloads.
The huawei_expand_nodepool wrapper exposes node pool resizing, an infrastructure mutation with cost and availability implications. Bundling this into a diagnosis-oriented skill enables privilege overreach and could let an agent make expensive or disruptive cluster capacity changes under the guise of troubleshooting.
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.
---
name: network-failure-diagnoser
description: Use this skill for CCE Kubernetes network failures such as Service unreachable, DNS/CoreDNS errors, Ingress 502/504, NetworkPolicy blocks, ELB backend health issues, EIP/NAT/VPC/security-group problems, and end-to-end Markdown diagnosis reports.
---
The declared description presents a narrowly scoped CCE network diagnosis skill. However, this code chunk is the entrypoint for a generic Huawei Cloud dispatcher, not a network-diagnosis-specific implementation. It imports and exposes aliases for numerous functions across CCE, ECS, VPC, ELB, EIP, EVS, IAM, AOM, and Kubernetes, including listing resources, fetching metrics, cluster inspection, kubeconfig retrieval, and mutation/deletion operations. Although some exposed functions align with network diagnosis (ELB, VPC, subnets, security groups, Kubernetes services/ingresses), the actual primary behavior of this chunk is to route arbitrary registered actions in a much wider management/observability toolkit. That is a material scope mismatch and includes undeclared capabilities, especially operational and destructive actions.
The supplied code chunk is only an init.py file with a docstring: 'Huawei Cloud service modules.' It does not contain executable logic for network failure diagnosis, Huawei Cloud SDK calls, analysis routines, trigger handling, or any access to cloud networking resources. Because the declared description presents a specific operational troubleshooting skill while the actual code shown is merely a placeholder/module header, the description does not accurately represent the behavior of this code chunk.
The declared description says this skill diagnoses CCE network failures such as connectivity, Service/Ingress, ELB, VPC/Subnet, DNS, network policies, and security groups. However, the supplied code does not implement those network diagnostic checks. Instead, it is focused on Huawei Cloud AOM observability and alarm operations: listing Prometheus instances, fetching metrics, listing alerts/events, analyzing alarms, and managing alarm/action rules. Some CCE-related event names include load balancer or CNI failures, but that is incidental to alarming and not equivalent to network troubleshooting. The presence of multiple mutating functions for creating, updating, enabling/disabling, and deleting alarm artifacts is a significant undeclared capability and materially different primary purpose.
The declared description focuses on network troubleshooting in Huawei Cloud CCE: connectivity, Service/Ingress, ELB, VPC/Subnet, DNS, network policies, and security groups. The supplied code does not inspect or diagnose those network resources. Instead, it uses Kubernetes/Huawei Cloud access to analyze workload rollout issues, determine whether rollback is suitable based on rollout-related causes (e.g., CrashLoop, probe failure, image pull blocked), preview or execute a Deployment rollback, wait for recovery, and generate a remediation report. This is a materially different primary purpose and includes an undeclared state-changing capability: modifying a Deployment to roll back to a previous revision. Therefore the description does not accurately represent the code behavior.
This is a strong description-behavior mismatch. The declared purpose is network troubleshooting for CCE networking components and cloud networking configuration. The supplied code is instead an autoscaling diagnostic module (autoscaling_diagnosis.py) whose primary purpose is to assess HPA and Cluster Autoscaler paths. While it incidentally flags subnet IP exhaustion, IAM/API connectivity, and scheduling constraints, those checks are in service of autoscaling diagnosis, not general network diagnosis. It does not inspect Service/Ingress behavior, ELB configuration, DNS resolution, network policies, or security group rules as its main function. Therefore the skill description does not accurately represent the actual code behavior.
The declared description frames this as a network diagnosis skill focused on CCE connectivity, Service/Ingress failures, ELB/VPC/subnet, DNS, network policies, and security groups. However, the supplied code chunk implements a much broader CCE operations toolkit, including highly privileged lifecycle and mutation capabilities unrelated to diagnosis: deleting clusters/nodes/workloads, scaling workloads and node pools, changing CPU/memory resources, and fetching kubeconfig credentials. While some read-only functions such as listing services, ingresses, pods, nodes, and events could support troubleshooting, the module’s actual behavior materially exceeds the declared purpose and includes undeclared administrative and destructive capabilities. Therefore this is a clear description-behavior mismatch.
This is a clear mismatch. While one visible function lists Ingress resources, most of the supplied code is not focused on network failure diagnosis. Instead, it exposes general-purpose cluster introspection and administrative capabilities, including access to sensitive resources (Secrets, pod logs), disruptive operational actions (node drain, cluster hibernate/awake), and infrastructure modification (bind/unbind cluster EIP). The declared description emphasizes diagnostic analysis of network connectivity, ELB/VPC/subnet/DNS/security-group/network-policy issues, but the code chunk shown does not implement those specific diagnostics. Its actual scope is substantially broader and materially different from the declared purpose.
The declared description says this skill is for diagnosing CCE network failures and analyzing connectivity-related issues such as Service/Ingress, ELB, DNS, VPC/subnet, security groups, and network policies. However, the supplied code does not implement diagnostic workflows for those areas. Instead, it performs operational management of CCE addons through the Huawei Cloud SDK: listing addon instances, showing addon details, creating/installing addons, updating addons, deleting/uninstalling addons, and patching configuration for a bursting addon (virtual-kubelet). While one function touches network-related parameters like subnet IDs and VPC-derived values, it is configuring an addon, not diagnosing network faults. This is a material purpose mismatch, with undeclared write capabilities against cluster addon resources.
The declared description says this skill diagnoses CCE network failures such as Service/Ingress connectivity, ELB, VPC/Subnet, DNS, network policies, and security groups. However, the supplied code is centered on logging operations: discovering LogConfig CRs, creating/deleting LogConfig resources, querying Huawei LTS logs with pagination, matching app log streams, querying audit logs, and analyzing application log anomalies. It does not contain logic for inspecting network topology, Service/Ingress resources, ELB configuration, VPC/Subnet settings, DNS resolution, security group rules, or network policies. This is a material purpose mismatch: the actual code is a log analysis and log configuration management component, not a network failure diagnosis skill.
The declared description promises a network diagnosis skill centered on connectivity problems, Service/Ingress failures, ELB configuration, VPC/subnet analysis, DNS failures, and security controls. The supplied code instead is an auto-inspection/monitoring workflow for CCE cluster health. Its primary logic is: query AOM alarms, inspect pod CPU usage, inspect ELB runtime metrics, detect CrashLoopBackOff and replica mismatch, then optionally collect memory, deployment, node, and event data and generate root-cause/recovery suggestions focused mainly on CPU/resource and workload health. While ELB metrics are partially relevant to network-facing symptoms, the code lacks the claimed network-specific checks for DNS, VPC/subnet, security groups, and network policies, and it adds substantial undeclared workload/resource diagnosis functionality. Therefore the description does not accurately represent the actual code behavior.
The description focuses on network troubleshooting for CCE: connectivity, Service/Ingress reachability, ELB, VPC/subnet, DNS, network policies, and security groups. The supplied code does something materially different: it inventories Kubernetes resources and evaluates availability risks and resilience patterns. Its checks target single replicas, node/AZ concentration, hard affinity, lack of topology spread, missing PodDisruptionBudgets, missing readiness/liveness probes, control-plane HA visibility, and resource request/limit imbalances. While Service and Ingress objects are referenced, they are only used to infer gateway-like workloads for availability analysis, not to troubleshoot network paths or failures. There is no logic for inspecting ELB configuration, VPC/subnet state, DNS resolution, network policy enforcement, or security group rules. Therefore the declared description does not accurately represent the code's actual primary purpose and capabilities.
The declared description says this skill is for CCE network failure diagnosis. However, the code is clearly a capacity planning and elasticity analysis tool. It gathers cluster, node, node pool, deployment, HPA, and node metric data; computes trend statistics for CPU/memory/disk; predicts bottlenecks; simulates node recommendations; generates HPA previews; and writes summary/report/history artifacts. There is no logic for diagnosing network connectivity, Service/Ingress failures, ELB configuration, VPC/Subnet issues, DNS resolution, security groups, or network policies. This is a material primary-purpose mismatch, not just an implementation detail.
The declared description says this skill is for network failure diagnosis in CCE, including Service/Ingress, ELB, DNS, security groups, and network policies. The supplied code does not implement those diagnostic functions. Instead, it is an operational provisioning and validation tool for CCE-to-CCI bursting. It gathers cluster network context only as a prerequisite for setup, then creates VPCEP endpoints, installs/configures the virtual-kubelet addon, deploys a test workload, and verifies bursting state. This is a materially different primary purpose and includes undeclared write actions against cloud and Kubernetes resources.
The declared description emphasizes diagnostic analysis of CCE networking failures (Service/Ingress/ELB/DNS/VPC/security group/network policy troubleshooting). However, the supplied code does not implement diagnostic checks for those areas. Instead, it performs administrative cluster lifecycle and access-management actions, including creating and deleting clusters, pausing/resuming clusters, retrieving kubeconfig, and exposing the API via EIP binding. It also enumerates clusters and nodes. While there is a small networking-related helper to resolve a Neutron subnet ID and some cluster network configuration during creation, these are provisioning details, not failure diagnosis. This is a substantial purpose and capability mismatch, including sensitive undeclared capabilities such as destructive operations and credential/config retrieval.
The declared description promises a network troubleshooting skill focused on diagnosing CCE connectivity problems, Service/Ingress failures, ELB configuration issues, VPC/subnet problems, DNS failures, and policy/security rule checks. The actual code is primarily a monitoring aggregator: it fetches pod and node utilization metrics, ELB/NAT/EIP monitoring data, marks values above 80% as anomalies, and returns summaries. While ELB-related metrics and some network-adjacent resources are included, the implementation lacks the core diagnostic behaviors claimed in the description: no DNS tests, no security group or network policy inspection, no VPC/subnet validation logic, and no concrete connectivity diagnosis for Services/Ingress. This is a material purpose mismatch, not just an implementation-detail difference.
The declared description says this skill diagnoses CCE network failures such as Service/Ingress reachability, ELB, VPC/subnet, DNS, network policies, and security groups. The supplied code does none of that. It analyzes CPU/memory/disk utilization, pod request sizing, low-utilization nodes, nodepool autoscaling, and HPA configuration for cost optimization. Its imports, function names, queries, thresholds, recommendations, and generated report are all centered on optimization and elasticity, not networking. This is a material primary-purpose mismatch, not a minor implementation detail.
There is a material description-to-code mismatch. The declared description presents this as a network failure diagnosis skill, focused on connectivity, Service/Ingress, ELB, VPC/Subnet, DNS, network policy, and security groups. The code indeed contains those network-diagnosis capabilities. But it also contains major additional functionality not disclosed in the description: node diagnosis, workload diagnosis with pod/resource/change-correlation analysis, scaling deployments, verifying workload recovery, and node pool expansion via resize operations. Those are not merely implementation details; they are distinct capabilities, including mutating infrastructure state. Also, the description mentions checking network policies, but no explicit network policy inspection logic appears in this chunk. Because the code's behavior extends meaningfully beyond the declared diagnostic purpose—especially into operational changes—the description does not accurately represent the full behavior.
The declared description presents a broad CCE network diagnosis skill focused on troubleshooting network connectivity and configuration problems such as Service/Ingress failures, ELB, VPC/subnet, DNS, security groups, and network policies. However, the supplied code does not implement those diagnostic checks. Its primary purpose is to retrieve Kubernetes events from Huawei Cloud LTS by finding an event-enabled CCE LogConfig and querying/parsing event logs. While Kubernetes events may be useful as supporting data during troubleshooting, this code is a log/event retrieval utility, not a network diagnosis tool. That is a materially different primary behavior, so this should be flagged as a mismatch.
The declared description focuses on CCE network diagnosis: connectivity issues, Service/Ingress failures, ELB/VPC/subnet analysis, DNS failures, and network/security policy checks. None of those behaviors appear in the supplied code. Instead, the file is explicitly for 'CCE HorizontalPodAutoscaler helpers' and contains functions to validate credentials, obtain cluster certs, configure a Kubernetes client, build HPA manifests, generate YAML, list existing HPAs, and create or replace HPA resources after confirmation. This is a materially different primary purpose and includes undeclared modification capability against cluster autoscaling resources. Therefore the description does not accurately represent the code chunk.
There is a strong description-behavior mismatch. The declared purpose is narrowly about CCE network failure diagnosis, especially connectivity, Service/Ingress, ELB config, VPC/subnet, DNS, and security controls. The actual code is a general-purpose CCE cluster inspection module covering many non-network domains: events, alarms, node health, node vulnerabilities, resource usage, pod health, and report generation/orchestration. While one part of the code does inspect ELB/EIP-related metrics and Service LoadBalancers, that is only a subset of the implementation. More importantly, several prominently declared network-diagnosis capabilities are absent from the code shown: there is no DNS resolution checking logic, no VPC/subnet inspection, no security group or network policy analysis, and no clear Ingress-specific diagnosis. Thus the primary purpose is materially different and key declared capabilities are missing.
The declared description promises a network diagnosis skill focused on CCE connectivity, Service/Ingress failure analysis, ELB/VPC/Subnet checks, DNS diagnosis, and security-group/network-policy validation. However, this code chunk is a general-purpose Kubernetes resource retrieval module. While services, ingresses, pods, and events could support troubleshooting, the code does not contain logic specific to diagnosing network faults, DNS resolution, ELB configuration, VPC/subnet setup, security groups, or network policies. Instead, it broadly lists many cluster objects, including sensitive Secrets and ConfigMaps, which is an undeclared capability. Therefore the description does not accurately represent the actual behavior.
The supplied code does not implement network failure diagnosis features such as checking Service/Ingress reachability, ELB configuration, VPC/subnet issues, DNS resolution failures, network policies, or security group rules. Instead, it retrieves cluster, pod, and node metadata and queries AOM/Prometheus for resource utilization metrics (CPU, memory, disk), returning rankings and time-series data. While such metrics could support broader troubleshooting, the primary behavior is performance monitoring, which is materially different from the declared network diagnosis purpose.
Detected: suspicious.exposed_secret_literal, suspicious.insecure_tls_verification