A potential risk of ack-secret-manager makes a worker node get the token of any Service Account

[sparkEchooo]

Summary

  The ack-secret-manager gave excessive authority when defining Service Account named "ack-secret-manager". Besides, this Service Account is mounted in a pod named "ack-secret-manager-5c9f957b57-f448m", witch makes it possible for attackers to raise rights to administrators.  

Detailed Analysis

• The clusterrole named "ack-secret-manager" defines the "create, get" verbs of "secrets". And this clusterrole is bound to the Service Account named "ack-secret-manager".

 Attacking Strategy

  If a malicious user controls a specific worker node which has the Pod mentioned above , or steals the Service Account token mentioned above. He/She can raise permissions to administrator level and control the whole cluster. For example,

• With the "create" and "get" verb of "secrets", attacker can elevate privileges by creating the secret for any Service Account, and then, get the secret.

Mitigation Discussion

• Developer could use the rolebinding instead of the clusterrolebinding to restrict permissions to namespace.
• Developer could delete the "create" verb of "podControllers and secrets".

 A few questions

• Is it a real issue in ack-secret-manager?
• If it's a real issue, can ack-secret-manager mitigate the risks following my suggestions discussed in the "mitigation discussion"?
• If it's a real issue, does ack-secret-manager plan to fix this issue?

[DahuK]

@sparkEchooo sorry for the late response! The issue is typically encountered when users aim to leverage external secret management credentials within a pod. Based on the architectural design and working mechanism of this project, we have to maintain minimal RBAC permissions for secrets to enable injection and synchronization of Kubernetes secret values. Here are some considerations and potential risks to evaluate before utilizing this plugin:

Host Security: The foundation of Kubernetes security architecture lies in host security. please enusre that you have hardened your host's security before proceeding further.

Secrets Management: you can choose to use secrets-store-csi-driver-provider-alibaba-cloud which does not need create/update k8s secrets within cluster, but you know that the secret values could still be accessible on the host file system. Vulnerabilities in the application, such as directory traversal attacks, can become more serious.

Direct API Usage: For added safety, we recommend directly interfacing with the external Secrets Manager API when possible. Ensure that the API permissions are narrowly scoped and restricted to the dimensions of the pod.

[sparkEchooo]

Thanks for your reply!

If it is a real issue in ack-secret-manager, similar to the issue I reported and confirmed by the kubewarden (https://nvd.nist.gov/vuln/detail/CVE-2023-22645), can you give us a CVE Number or public thanks for awarding our efforts?

[DahuK]

Please understand the function and usage of this project first, we are totally different from kubewarden, in kubewarden the secrets is a non-required privilege that helps for cache. At the same time, we understand that secrets is a high-risk privilege, but the usefulness of this project is to synchronize the credentials stored in the external secrets manager in the form of k8s secrets, similar to the mechanism of extern-secrets, and secrets is also a necessary minimization privilege of the project, users have the right to use this plugin to synchronize ciphertext stored in the KMS Secret Manager in a relatively secure environment, in order to prevent the hardcoded propagation of sensitive information throughout the supply chain.

I think you understand my reply above, and we don't consider this is a CVE. I will close this Issue, and if there are any other vulnerabilities reported in the future, please follow the SECURITY POLICY, thanks!

[sparkEchooo]

I apologize for submitting the security report in the form of a public issue. Normally, I resort to submitting an issue only when I cannot find a security policy and am unable to contact the developers. It appears that I may have overlooked something this time. My apologies once again.

[sparkEchooo]

If the ack-secret-manager must have the relevant permissions for the secrets resource, it might be helpful to inform users about this in the documentation, such as: "We strongly recommend inspecting the RBAC configuration for Manifests or for Helm to understand what access the service account has and to which resources. For example, by default the service account has access to all Secret resources in the cluster."

Thanks for your patience!