Back to skill

Security audit

Ucs Cluster Onboarding Manager

Security checks for vulnerabilities and agentic risk

Overview

This skill is not clearly malicious, but it should be reviewed because it handles powerful Huawei Cloud/Kubernetes credentials and destructive cluster-management actions.

Install only for deliberate Huawei Cloud UCS administration. Use a least-privilege IAM user, avoid the full Resource * management policy unless temporarily needed, never paste AK/SK or kubeconfig contents into chat or shell history, save kubeconfigs only to protected files, and manually confirm all delete or deregistration targets before running commands.

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Findings (22)

Context-Inappropriate Capability

Medium
Confidence
85% confidence
Finding
This scenario goes beyond obtaining federation access and demonstrates broad enumeration across every context, including listing pods cluster-wide and iterating all clusters to list nodes. In an access-management skill, such examples normalize high-visibility reconnaissance activity that could be misused once a federation kubeconfig is obtained.

Vague Triggers

Medium
Confidence
86% confidence
Finding
The trigger list includes broad phrases such as "cluster group," "fleet grouping," "managed clusters," and "cluster lifecycle" that are not uniquely tied to Huawei UCS. This can cause unintended invocation in unrelated cluster-management contexts, increasing the chance that the skill is selected for the wrong task and prompts users for sensitive cloud identifiers or access artifacts inappropriately.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The document provides a broad management policy that includes destructive actions and sensitive access capabilities such as cluster deletion, group deletion, kubeconfig generation, and federation kubeconfig retrieval, but it does not clearly warn users about the security consequences of assigning those permissions. In a cluster-onboarding skill, these permissions can enable takeover of Kubernetes environments or destructive lifecycle changes if granted too broadly or to the wrong principal.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The workflow instructs users to pass full kubeconfig content directly on the command line without an explicit warning that this transmits cluster credentials to UCS and may expose secrets in shell history, process listings, logs, or terminal recordings. Because kubeconfig often contains bearer tokens or client certificates, mishandling it can lead to credential theft and compromise of the registered cluster.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The reorganization scenario includes a direct `DeleteClusterGroup` command immediately after creating a replacement group, but it does not repeat a local warning, dependency check, or explicit user confirmation step adjacent to the destructive action. In an operational skill for cluster fleet management, users may copy commands from scenario blocks out of context, which increases the risk of accidental deletion of governance structures and unintended loss of fleet-level policy associations.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The guide instructs users to create and download cluster and federation kubeconfigs but does not warn that these files are bearer-equivalent credentials that can grant direct cluster access. In a cluster-management skill, omission of handling guidance increases the chance users will print, log, store, or share kubeconfigs insecurely, leading to credential exposure.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The verification workflow explicitly instructs operators to retrieve cluster access details and generate kubeconfig content, but it does not warn that these outputs are sensitive credentials that can grant cluster access. In a skill intended for onboarding and lifecycle management, this increases the chance that users paste kubeconfig into chats, logs, terminals with history, or shared tickets, resulting in credential exposure.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The document includes deletion commands for fleet groups and deregistering clusters as routine verification steps without a clear warning that these are destructive operations affecting real UCS resources. In this context, an operator may run them against production identifiers or misunderstand cleanup scope, causing unintended service management disruption or loss of configuration state.

Credential Access

High
Category
Privilege Escalation
Content
- Create, delete, update, and query fleet groups for cluster organization
- Add/remove clusters from fleet groups (join/leave)
- Retry cluster activation
- Obtain cluster access information and kubeconfig credentials
- Download federation kubeconfig for multi-cluster access
- Check UCS resource quotas
Confidence
82% confidence
Finding
The skill explicitly advertises obtaining cluster access information and kubeconfig credentials, which are highly sensitive administrative artifacts. In a conversational agent context, promoting retrieval without strong controls can lead to accidental disclosure in chat transcripts, logs, or to the wrong user if identity and authorization checks are weak.

Credential Access

High
Category
Privilege Escalation
Content
- Add/remove clusters from fleet groups (join/leave)
- Retry cluster activation
- Obtain cluster access information and kubeconfig credentials
- Download federation kubeconfig for multi-cluster access
- Check UCS resource quotas

**Typical Use Cases**:
Confidence
82% confidence
Finding
Advertising federation kubeconfig download for multi-cluster access expands the blast radius because a single credential may enable access across multiple clusters. In a skill context, this is more dangerous than ordinary read-only metadata because mishandled output could grant broad administrative control.

Credential Access

High
Category
Privilege Escalation
Content
hcloud UCS RegisterCluster --apiVersion=v1 --kind=Cluster --metadata.name=prod-backend-cluster --spec.category=self --spec.provider=huaweicloud --spec.type=cce --spec.manageType=grouped --spec.country=CN --spec.city=110000 --metadata.uid=<cce-cluster-id> --spec.projectID=<project-id> --spec.region=cn-north-4 --spec.clusterGroupID=<group-id> --cli-region=cn-north-4

# Register a self-managed/attached cluster
hcloud UCS RegisterCluster --apiVersion=v1 --kind=Cluster --metadata.name=datacenter-k8s --spec.category=onpremise --spec.provider=self_managed --spec.type=Kubernetes --spec.manageType=discrete --spec.country=CN --spec.city=110000 --metadata.annotations.kubeconfig=<kubeconfig-yaml-content> --cli-region=cn-north-4

# Retry cluster activation (if registration stuck)
hcloud UCS RetryClusterActivation --clusterid=<ucs-cluster-id> --cli-region=cn-north-4
Confidence
96% confidence
Finding
This duplicate finding highlights the same core issue: the registration example normalizes injecting kubeconfig YAML into command arguments. That practice materially increases the chance of credential leakage during normal administration workflows.

Credential Access

High
Category
Privilege Escalation
Content
hcloud UCS RegisterCluster --apiVersion=v1 --kind=Cluster --metadata.name=prod-backend-cluster --spec.category=self --spec.provider=huaweicloud --spec.type=cce --spec.manageType=grouped --spec.country=CN --spec.city=110000 --metadata.uid=<cce-cluster-id> --spec.projectID=<project-id> --spec.region=cn-north-4 --spec.clusterGroupID=<group-id> --cli-region=cn-north-4

# Register a self-managed/attached cluster
hcloud UCS RegisterCluster --apiVersion=v1 --kind=Cluster --metadata.name=datacenter-k8s --spec.category=onpremise --spec.provider=self_managed --spec.type=Kubernetes --spec.manageType=discrete --spec.country=CN --spec.city=110000 --metadata.annotations.kubeconfig=<kubeconfig-yaml-content> --cli-region=cn-north-4

# Retry cluster activation (if registration stuck)
hcloud UCS RetryClusterActivation --clusterid=<ucs-cluster-id> --cli-region=cn-north-4
Confidence
96% confidence
Finding
This duplicate finding highlights the same core issue: the registration example normalizes injecting kubeconfig YAML into command arguments. That practice materially increases the chance of credential leakage during normal administration workflows.

Credential Access

High
Category
Privilege Escalation
Content
| `--metadata.uid`                 | CCE only | CCE cluster ID                     | Must reference existing CCE cluster          |
| `--spec.projectID`               | CCE only | Project ID                         | Valid Huawei Cloud project ID                |
| `--spec.region`                  | CCE only | CCE cluster region                 | Must match CCE cluster region                |
| `--metadata.annotations.kubeconfig` | Self-managed only | Kubeconfig content | Valid Kubernetes kubeconfig YAML           |
| `--spec.clusterGroupID`          | No       | Assign to fleet at registration    | Valid fleet group ID                         |
| `--metadata.labels.*`            | No       | Custom labels                      | Key-value pairs                              |
Confidence
95% confidence
Finding
The table entry makes the unsafe handling pattern appear canonical, increasing the likelihood operators will follow it verbatim. Since kubeconfig grants cluster access, leakage here has direct administrative security consequences.

Credential Access

High
Category
Privilege Escalation
Content
| `--metadata.uid`                 | CCE only | CCE cluster ID                     | Must reference existing CCE cluster          |
| `--spec.projectID`               | CCE only | Project ID                         | Valid Huawei Cloud project ID                |
| `--spec.region`                  | CCE only | CCE cluster region                 | Must match CCE cluster region                |
| `--metadata.annotations.kubeconfig` | Self-managed only | Kubeconfig content | Valid Kubernetes kubeconfig YAML           |
| `--spec.clusterGroupID`          | No       | Assign to fleet at registration    | Valid fleet group ID                         |
| `--metadata.labels.*`            | No       | Custom labels                      | Key-value pairs                              |
Confidence
95% confidence
Finding
The table entry makes the unsafe handling pattern appear canonical, increasing the likelihood operators will follow it verbatim. Since kubeconfig grants cluster access, leakage here has direct administrative security consequences.

Credential Access

High
Category
Privilege Escalation
Content
| `--metadata.uid`                 | CCE only | CCE cluster ID                     | Must reference existing CCE cluster          |
| `--spec.projectID`               | CCE only | Project ID                         | Valid Huawei Cloud project ID                |
| `--spec.region`                  | CCE only | CCE cluster region                 | Must match CCE cluster region                |
| `--metadata.annotations.kubeconfig` | Self-managed only | Kubeconfig content | Valid Kubernetes kubeconfig YAML           |
| `--spec.clusterGroupID`          | No       | Assign to fleet at registration    | Valid fleet group ID                         |
| `--metadata.labels.*`            | No       | Custom labels                      | Key-value pairs                              |
Confidence
95% confidence
Finding
The table entry makes the unsafe handling pattern appear canonical, increasing the likelihood operators will follow it verbatim. Since kubeconfig grants cluster access, leakage here has direct administrative security consequences.

Credential Access

High
Category
Privilege Escalation
Content
| -------------------------------- | -------- | ------------------------ | -------------------------------------------- |
| `--clusterid`                    | Yes      | UCS cluster ID           | Must be registered cluster                   |
| `--clustergroupid`               | Yes (DownloadFederationKubeconfig) | Fleet group ID | Valid fleet group ID            |
| `--duration`                     | Yes (DownloadFederationKubeconfig) | Token duration in seconds | Integer                   |

### Quota Parameters
Confidence
88% confidence
Finding
The documented federation kubeconfig parameters enable creation of a privileged, time-bound multi-cluster access artifact without documenting mandatory secure delivery restrictions. In an agent setting, generating such credentials is sensitive and can be dangerous if the artifact is displayed inline or retained in conversation history.

Credential Access

High
Category
Privilege Escalation
Content
2. **Fleet Grouping**: Organize clusters by environment (production/staging/development) or business domain for unified governance
3. **Kubeconfig Security**: Store kubeconfig files securely; never expose them in public repositories or CI logs
4. **Deregistration Caution**: Removing a cluster from UCS disables all policy governance and federation access for that cluster
5. **Self-Managed Registration**: Ensure the self-managed cluster kubeconfig is valid and the cluster API server is reachable; pass it via `--metadata.annotations.kubeconfig`
6. **Quota Monitoring**: Check quotas before registering new clusters to avoid hitting limits
7. **Federation Kubeconfig Duration**: Choose appropriate `--duration` for federation kubeconfig tokens based on usage patterns
Confidence
91% confidence
Finding
Although framed as operational advice, this line still instructs users to pass self-managed cluster kubeconfig via `--metadata.annotations.kubeconfig`, reinforcing the unsafe inline-secret pattern. The surrounding best-practice language does not mitigate the fact that the example encourages credential exposure through CLI arguments.

Credential Access

High
Category
Privilege Escalation
Content
2. **Fleet Grouping**: Organize clusters by environment (production/staging/development) or business domain for unified governance
3. **Kubeconfig Security**: Store kubeconfig files securely; never expose them in public repositories or CI logs
4. **Deregistration Caution**: Removing a cluster from UCS disables all policy governance and federation access for that cluster
5. **Self-Managed Registration**: Ensure the self-managed cluster kubeconfig is valid and the cluster API server is reachable; pass it via `--metadata.annotations.kubeconfig`
6. **Quota Monitoring**: Check quotas before registering new clusters to avoid hitting limits
7. **Federation Kubeconfig Duration**: Choose appropriate `--duration` for federation kubeconfig tokens based on usage patterns
Confidence
91% confidence
Finding
Although framed as operational advice, this line still instructs users to pass self-managed cluster kubeconfig via `--metadata.annotations.kubeconfig`, reinforcing the unsafe inline-secret pattern. The surrounding best-practice language does not mitigate the fact that the example encourages credential exposure through CLI arguments.

Credential Access

High
Category
Privilege Escalation
Content
4. **Deregistration Caution**: Removing a cluster from UCS disables all policy governance and federation access for that cluster
5. **Self-Managed Registration**: Ensure the self-managed cluster kubeconfig is valid and the cluster API server is reachable; pass it via `--metadata.annotations.kubeconfig`
6. **Quota Monitoring**: Check quotas before registering new clusters to avoid hitting limits
7. **Federation Kubeconfig Duration**: Choose appropriate `--duration` for federation kubeconfig tokens based on usage patterns

## Reference Documents
Confidence
90% confidence
Finding
This duplicate reflects the same risk: the skill discusses operational use of sensitive kubeconfig artifacts but lacks explicit constraints on how they are surfaced to the user. In an LLM-agent environment, that can translate into accidental secret disclosure in transcripts or tools output.

Credential Access

High
Category
Privilege Escalation
Content
4. **Deregistration Caution**: Removing a cluster from UCS disables all policy governance and federation access for that cluster
5. **Self-Managed Registration**: Ensure the self-managed cluster kubeconfig is valid and the cluster API server is reachable; pass it via `--metadata.annotations.kubeconfig`
6. **Quota Monitoring**: Check quotas before registering new clusters to avoid hitting limits
7. **Federation Kubeconfig Duration**: Choose appropriate `--duration` for federation kubeconfig tokens based on usage patterns

## Reference Documents
Confidence
90% confidence
Finding
This duplicate reflects the same risk: the skill discusses operational use of sensitive kubeconfig artifacts but lacks explicit constraints on how they are surfaced to the user. In an LLM-agent environment, that can translate into accidental secret disclosure in transcripts or tools output.

Credential Access

High
Category
Privilege Escalation
Content
| Quota exceeded              | 403 Quota limit                 | Check quotas with `ShowQuota --domainid=<account-id>` |
| Fleet group already exists  | 409 Conflict                    | Use `ShowClusterGroup` to check first        |
| Deregistration impact       | Policies stop working           | Consider disabling policies before deregistration |
| Federation kubeconfig expired | Multi-cluster access fails    | Re-download with `DownloadFederationKubeconfig --clustergroupid=<id> --duration=N` |
| Wrong parameter names       | Command fails or unrecognized   | Use `--clusterid` (not --cluster_id), `--clustergroupid` (not --group_id) |
| Using --name on ShowClusterList | Parameter not recognized    | Use `--category`, `--clustergroupid`, `--enablestatus` filters instead |
| Missing domainid on ShowQuota | Missing required parameter    | Provide `--domainid=<account-id>` |
Confidence
87% confidence
Finding
This duplicate finding points to the same operational pattern: repeated federation kubeconfig issuance without explicit guardrails. Because federation credentials can span multiple clusters, accidental exposure has a larger-than-normal impact.

Credential Access

High
Category
Privilege Escalation
Content
| Quota exceeded              | 403 Quota limit                 | Check quotas with `ShowQuota --domainid=<account-id>` |
| Fleet group already exists  | 409 Conflict                    | Use `ShowClusterGroup` to check first        |
| Deregistration impact       | Policies stop working           | Consider disabling policies before deregistration |
| Federation kubeconfig expired | Multi-cluster access fails    | Re-download with `DownloadFederationKubeconfig --clustergroupid=<id> --duration=N` |
| Wrong parameter names       | Command fails or unrecognized   | Use `--clusterid` (not --cluster_id), `--clustergroupid` (not --group_id) |
| Using --name on ShowClusterList | Parameter not recognized    | Use `--category`, `--clustergroupid`, `--enablestatus` filters instead |
| Missing domainid on ShowQuota | Missing required parameter    | Provide `--domainid=<account-id>` |
Confidence
87% confidence
Finding
This duplicate finding points to the same operational pattern: repeated federation kubeconfig issuance without explicit guardrails. Because federation credentials can span multiple clusters, accidental exposure has a larger-than-normal impact.

Static analysis

No suspicious patterns detected.