huawei-cloud-ucs-cluster-onboarding-manager

• Outcome: Review
• Latest audit: Aug 3, 2026 · 9:20 AM UTC
• Version: 1.0.0

Overview

This skill is a legitimate Huawei Cloud UCS management guide, but it handles powerful cluster credentials and destructive cloud operations with some unsafe or under-scoped examples that users should review carefully.

Install only if you need an agent to help administer Huawei Cloud UCS resources. Use least-privilege IAM instead of the full Resource "*" policy where possible, prefer temporary credentials, protect any hcloud config files with strict permissions, and do not paste kubeconfig contents directly into commands, chats, logs, shell history, or CI output. Require explicit confirmation before any register, update, join/leave, delete, kubeconfig generation, or federation-kubeconfig retrieval operation.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (23)

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill includes commands to create/download cluster and federation kubeconfigs, which are effectively bearer credentials for Kubernetes access, but this section does not place an explicit inline warning immediately adjacent to those examples about treating the output as sensitive secret material. In an agent context, that increases the chance the credential contents are displayed, logged, stored in transcripts, or written to insecure locations.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The guide explicitly shows storing long-lived access keys and secret keys in ~/.hcloud/config.json without warning that this is plaintext credential storage on disk. If the workstation is compromised, backed up insecurely, or the file permissions are too broad, these cloud credentials can be stolen and used to access or manage UCS resources.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The environment-variable example instructs users to export AK/SK/token values but omits any warning that environment variables may be exposed through shell history, process inspection, CI logs, crash dumps, or inherited subprocess environments. In a cluster onboarding and fleet-management context, these credentials could grant broad control over cloud and Kubernetes-related resources if leaked.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The document explicitly grants permissions to create or retrieve kubeconfig and federation kubeconfig, which are sensitive cluster access credentials, but it does not warn that these files can enable administrative access if exposed. In the context of a cluster onboarding and fleet-management skill, normalizing credential retrieval without handling guidance increases the chance of unsafe storage, sharing, or display of highly privileged access material.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The self-managed cluster registration example embeds the full kubeconfig content directly on the command line via `--metadata.annotations.kubeconfig=<kubeconfig-content>`. Kubeconfigs commonly contain bearer tokens, client certificates, or endpoint details, and placing them inline increases the chance of exposure through shell history, process listings, logs, transcripts, or copy/paste into shared channels. In the context of a cluster onboarding skill, this is operationally plausible and therefore more dangerous because users may follow it exactly with real admin credentials.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The workflow for removing a cluster from a fleet group provides a destructive operational command without any explicit confirmation or user-warning step. In this skill’s context, fleet membership controls policy/governance scope, so an operator or downstream agent could unintentionally detach a cluster from centralized governance, causing policy drift or compliance gaps.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The reorganization example shows deletion of a fleet group immediately after creating a new one, but omits the earlier deletion cautions and confirmation guidance. This makes a destructive action easier to invoke out of context, increasing the chance that users or agents delete a group without checking attached policies, cluster membership, or organizational consequences.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The document describes commands that return kubeconfig content but does not warn that kubeconfig files are bearer-style access credentials that can grant cluster access if copied, logged, or stored insecurely. In a cluster onboarding skill, this omission is security-relevant because users may paste outputs into terminals, chat logs, CI logs, or shared files without recognizing the sensitivity.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The document includes deletion commands for fleet groups and clusters as part of verification/cleanup without an explicit warning that these actions remove registered resources and may disrupt management workflows if run against non-test IDs. In an operational cluster-management skill, users may copy commands directly, so missing safety language increases the chance of accidental destructive actions.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill instructs users to retrieve kubeconfig content but does not warn that kubeconfig is a sensitive credential that can grant cluster access and should not be logged, pasted into chats, or stored insecurely. Because this skill manages cluster onboarding and access, exposing kubeconfig materially increases the risk of unauthorized cluster administration.

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=turbo --spec.manageType=discrete --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 finding duplicates the same unsafe pattern on the same line: embedding kubeconfig YAML directly into a command argument. Because kubeconfig often contains client certs, tokens, or endpoint details, exposing it in arguments can immediately compromise cluster access.

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=turbo --spec.manageType=discrete --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 finding duplicates the same unsafe pattern on the same line: embedding kubeconfig YAML directly into a command argument. Because kubeconfig often contains client certs, tokens, or endpoint details, exposing it in arguments can immediately compromise cluster access.

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: 84% confidence
• Finding: The same section instructs users to pass self-managed cluster kubeconfig via `--metadata.annotations.kubeconfig`, which normalizes handling a sensitive credential as an inline parameter. Even though the document later says kubeconfig is sensitive, this specific guidance encourages an unsafe transmission method likely to leak into logs and process metadata.

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: 84% confidence
• Finding: The same section instructs users to pass self-managed cluster kubeconfig via `--metadata.annotations.kubeconfig`, which normalizes handling a sensitive credential as an inline parameter. Even though the document later says kubeconfig is sensitive, this specific guidance encourages an unsafe transmission method likely to leak into logs and process metadata.

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

## Workflow

• Confidence: 83% confidence
• Finding: This same context repeats that self-managed registration requires passing kubeconfig via `--metadata.annotations.kubeconfig`, reinforcing an unsafe secret-handling pattern. Repetition in best-practice/workflow sections makes misuse more likely in real deployments and agent executions.

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

## Workflow

• Confidence: 83% confidence
• Finding: This same context repeats that self-managed registration requires passing kubeconfig via `--metadata.annotations.kubeconfig`, reinforcing an unsafe secret-handling pattern. Repetition in best-practice/workflow sections makes misuse more likely in real deployments and agent executions.

Credential Access

High

• Category: Privilege Escalation

Content

- Network ACL or security group rules prevent inbound connections from UCS

**Solution**: Ensure the cluster API server is accessible:
- Use a publicly reachable API server endpoint in the kubeconfig
- Configure firewall rules to allow UCS management plane access
- For private clusters, set up VPN or direct network connectivity between UCS and the cluster

• Confidence: 76% confidence
• Finding: Advising users to use a publicly reachable API server endpoint for kubeconfig materially weakens cluster exposure if presented as a default troubleshooting step. In the context of a cluster-management skill, encouraging public control-plane reachability can expand attack surface and increase the chance of unauthorized access attempts, especially if users interpret it as the preferred fix rather than a last resort.

Credential Access

High

• Category: Privilege Escalation

Content

- ❌ Using `--name=my-cluster` instead of `--metadata.name=my-cluster`
- ❌ Using `--cluster_type=CCE` instead of `--spec.category=self --spec.type=turbo`
- ❌ Using `--cluster_id=<cce-id>` instead of `--metadata.uid=<cce-id>`
- ❌ Using `--kubeconfig_file=<content>` instead of `--metadata.annotations.kubeconfig=<content>`
- ❌ Using `--spec.category=CCE` (uppercase) instead of `--spec.category=self` (verified correct value)
- ❌ Using `--spec.provider=huawei_cloud` (with underscore) instead of `--spec.provider=huaweicloud` (no underscore)
- ❌ Using `--spec.type=CCE` (uppercase) instead of `--spec.type=turbo` (lowercase)

• Confidence: 86% confidence
• Finding: This duplicate finding points to the same unsafe pattern: placing kubeconfig content inline in CLI arguments. In a cluster onboarding skill, that creates a realistic secret-exposure path because users are likely to copy-paste examples into shared terminals, scripts, or CI systems.

Credential Access

High

• Category: Privilege Escalation

Content

- ❌ Using `--name=my-cluster` instead of `--metadata.name=my-cluster`
- ❌ Using `--cluster_type=CCE` instead of `--spec.category=self --spec.type=turbo`
- ❌ Using `--cluster_id=<cce-id>` instead of `--metadata.uid=<cce-id>`
- ❌ Using `--kubeconfig_file=<content>` instead of `--metadata.annotations.kubeconfig=<content>`
- ❌ Using `--spec.category=CCE` (uppercase) instead of `--spec.category=self` (verified correct value)
- ❌ Using `--spec.provider=huawei_cloud` (with underscore) instead of `--spec.provider=huaweicloud` (no underscore)
- ❌ Using `--spec.type=CCE` (uppercase) instead of `--spec.type=turbo` (lowercase)

• Confidence: 86% confidence
• Finding: This duplicate finding points to the same unsafe pattern: placing kubeconfig content inline in CLI arguments. In a cluster onboarding skill, that creates a realistic secret-exposure path because users are likely to copy-paste examples into shared terminals, scripts, or CI systems.

Credential Access

High

• Category: Privilege Escalation

Content

"ucs:clusterGroup:update",
        "ucs:clusterAccess:get",
        "ucs:quota:get",
        "ucs:kubeconfig:create",
        "ucs:federationKubeconfig:get",
        "ucs:clusterConf:create"
      ],

• Confidence: 89% confidence
• Finding: Including `ucs:kubeconfig:create` in the full management policy enables generation of cluster access credentials, which could be abused to obtain direct access to managed clusters if assigned too broadly. Because the policy uses `Resource: ["*"]` and is presented as a reusable management policy, the skill context makes this more dangerous by encouraging broad credential-issuance capability across clusters.

Credential Access

High

• Category: Privilege Escalation

Content

"ucs:clusterAccess:get",
        "ucs:quota:get",
        "ucs:kubeconfig:create",
        "ucs:federationKubeconfig:get",
        "ucs:clusterConf:create"
      ],
      "Resource": ["*"]

• Confidence: 88% confidence
• Finding: Including `ucs:federationKubeconfig:get` allows retrieval of federation-level kubeconfig, which may provide broad access across multiple clusters or fleet-managed environments. In a UCS fleet/federation management skill, that access is especially sensitive because compromise of federation credentials can expand impact beyond a single cluster.

Credential Access

High

• Category: Privilege Escalation

Content

**Self-Managed Cluster Requirements**:
- The kubeconfig must be valid YAML in standard Kubernetes format
- The cluster API server must be reachable from UCS management plane
- Ensure the kubeconfig user has sufficient RBAC permissions
- Recommended: use a dedicated service account with cluster-admin or admin privileges

### 3. Delete (Deregister) a Cluster

• Confidence: 89% confidence
• Finding: The guidance recommends using a kubeconfig with cluster-admin or admin privileges for self-managed cluster onboarding. Encouraging highly privileged credentials increases blast radius if the kubeconfig is leaked, reused improperly, or retained longer than needed, especially in a fleet-management context where cluster access is central.

Credential Access

High

• Category: Privilege Escalation

Content

- `--duration` (required): Kubeconfig validity duration in seconds
- `--cli-region` (required): Region ID

**Response**: Returns a federation kubeconfig YAML that provides unified access to all clusters in the fleet group.

**Use Cases**:
- Multi-cluster workload distribution

• Confidence: 93% confidence
• Finding: The document states that the response returns federation kubeconfig YAML providing unified access to all clusters in the fleet group, but it lacks an adjacent security warning. Because this credential can enable broad multi-cluster access, accidental disclosure through logs, files, or collaboration tools could expose an entire fleet rather than a single cluster.

VirusTotal

VirusTotal findings are pending for this skill version.

Static analysis

No suspicious patterns detected.