T09 · Insecure Skill Coding Practices
Error
- Location
references/task-compliance-audit.md:142- Finding
Cluster kubeconfig credentials are stored in an insecure predictable file
- Content
View full analysis
--cli-region=cn-north-4 > cluster-kubeconfig.yaml # 3. Fix violations using kubectl kubectl --kubeconfig=cluster-kubeconfig.yaml apply -f # 4. Re-trigger enforcement hcloud UCS DisableClusterPolicy --clusterid= --cli-region=cn-north-4 ``` ### Technical Analysis The remediation workflow writes a generated Kubernetes kubeconfig to the fixed filename `cluster-kubeconfig.yaml` in the current working directory. A kubeconfig may contain bearer tokens, client certificates, private keys, or other reusable authentication material. The workflow does not: - Create the file in a private temporary directory. - Set restrictive permissions such as mode `0600`. - Check whether the predictable filename already exists. - Register cleanup logic for successful or interrupted execution. - Delete the credential file after `kubectl` completes. - Prevent the file from being created inside a source repository or another shared directory. The file's effective permissions therefore depend on the ambient process umask. It may also be captured by backups, workspace archiving, diagnostic collection, or an accidental version-control commit. ### Attack Path 1. A user or agent starts the documented compliance-remediation workflow. 2. `CreateClusterKubeconfig` writes cluster access credentials to `cluster-kubeconfig.yaml`. 3. The file remains in the working directory after remediation finishes or is interrupted. 4. Another local user or process reads the file, or the file is copied into a backup, artifact, or source-control commit. 5. The exposed credentials are used with `kubectl` or the Kubernetes API ...[truncated 880 chars]- Remediation
View remediation
\ --cli-region=cn-north-4 > "$kubeconfig_file" || exit 1 chmod 600 "$kubeconfig_file" kubectl --kubeconfig="$kubeconfig_file" apply -f ``` Additional hardening should include: 1. Prefer short-lived, narrowly scoped cluster credentials. 2. Never generate kubeconfig files inside a repository or shared workspace. 3. Verify that the target cluster is the one approved by the user before obtaining credentials. 4. Avoid printing kubeconfig contents to logs or conversation output. 5. Document immediate credential revocation or rotation procedures if the file is exposed. 6. Add kubeconfig filenames and temporary credential patterns to relevant ignore and secret-scanning rules as defense in depth. ]]>