Younaman

**Nome do software vulnerável e versões afetadas** Versões do External Secrets Operator anteriores à 0.10.2 **Descrição** O External Secrets Operator é um operador do Kubernetes que integra sistemas externos de gerenciamento de segredos. Ele possui uma implantação chamada default-external-secrets-cert-controller, que está vinculada a um ClusterRole com o mesmo nome. Este ClusterRole possui os verbos “get/list” para recursos de segredos e o verbo “path/update” para recursos de validação de configurações de webhook. Isso pode ser usado para abusar do token SA da implantação a fim de recuperar ou obter todos os segredos em todo o cluster, capturar e registrar todos os dados de solicitações que tentam atualizar segredos, ou fazer com que um webhook recuse todas as solicitações de criação e atualização de Pods. **Recomendações** Para versões anteriores à 0.10.2, atualize para a versão 0.10.2 para corrigir essa vulnerabilidade. Como solução alternativa temporária, considere restringir o acesso à implantação `default-external-secrets-cert-controller` e ao ClusterRole associado para minimizar o risco de exploração. Evite usar os verbos `get/list` dos recursos secrets e o verbo `path/update` dos recursos validatingwebhookconfigurations no ClusterRole afetado até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Versões do Hwameistor anteriores à 0.14.6 **Descrição** O Hwameistor é um sistema de armazenamento local de alta disponibilidade para cargas de trabalho stateful nativas da nuvem. Este ClusterRole possui permissões excessivas, permitindo que um usuário mal-intencionado que tenha acesso ao nó de trabalho com a implantação do Hwameistor abuse dessas permissões e execute quaisquer ações em todo o cluster, resultando em uma escalada de privilégios no nível do cluster. **Recomendações** Para versões anteriores à 0.14.6, atualize para a versão 0.14.6 ou posterior. Para usuários que não possam atualizar, atualize e limite o ClusterRole usando security-role como uma solução alternativa temporária.

**Nome do software vulnerável e versões afetadas** Kanister (versões afetadas não especificadas) **Descrição** O Kanister é uma ferramenta de gerenciamento de fluxos de trabalho para proteção de dados. O Kanister possui uma implantação chamada `default-kanister-operator`, que está vinculada a um ClusterRole chamado `edit` por meio de um ClusterRoleBinding. O ClusterRole “edit” é um dos ClusterRoles criados por padrão pelo Kubernetes e possui os verbos create/patch/update dos recursos daemonset, o verbo create dos recursos serviceaccount/token e o verbo impersonate dos recursos serviceaccounts. Um usuário mal-intencionado pode aproveitar o acesso ao nó de trabalho que possui esse componente para realizar uma escalada de privilégios no nível do cluster. Isso pode ser feito abusando dos verbos create/patch/update dos recursos daemonset para criar ou modificar um conjunto de Pods a fim de montar uma conta de serviço com privilégios elevados, ou usando o verbo create dos recursos serviceaccount/token para gerar novos tokens de conta de serviço e operar com funções de alto privilégio. Além disso, o verbo impersonate dos recursos serviceaccounts pode ser usado para se passar por contas de serviço com privilégios elevados, obtendo assim acesso a funções como administradores de cluster. **Recomendações** Para mitigar esse problema, defina o sinalizador `rbac.create` como `false` no gráfico Helm do Kanister, que controla se as regras RBAC para a conta de serviço do Kanister serão criadas. Isso exigirá que o usuário crie as regras RBAC por conta própria e limite as ligações de função para a conta de serviço do Kanister, por exemplo, o escopo

**Nome do software vulnerável e versões afetadas** Versões do Kubean anteriores à 0.18.0 **Descrição** O problema diz respeito a uma cadeia de ferramentas de gerenciamento do ciclo de vida do cluster, na qual o ClusterRole possui permissões excessivas, permitindo que um usuário mal-intencionado abuse dessas permissões e execute qualquer ação em todo o cluster, resultando em uma escalada de privilégios no nível do cluster. Isso pode ocorrer se o usuário mal-intencionado obtiver acesso ao nó de trabalho com a implantação do Kubean. **Recomendações** Para versões anteriores à 0.18.0, atualize para a versão 0.18.0 ou posterior para resolver o problema. No momento, não há informações sobre outras soluções alternativas para este problema.

**Name of the Vulnerable Software and Affected Versions** Clusternet versions prior to 0.15.2 **Description** Clusternet is a general-purpose system for controlling Kubernetes clusters across different environments. An issue in Clusternet can be leveraged to lead to a cluster-level privilege escalation. The Clusternet has a deployment called `cluster-hub` inside the `clusternet-system` Kubernetes namespace, which runs on worker nodes randomly. The deployment has a service account called `clusternet-hub`, which has a cluster role called `clusternet:hub` via cluster role binding. The `clusternet:hub` cluster role has `"*"` verbs of `"*.*"` resources. Thus, if a malicious user can access the worker node which runs the Clusternet, they can leverage the service account to do malicious actions to critical system resources. For example, the malicious user can leverage the service account to get ALL secrets in the entire cluster, resulting in cluster-level privilege escalation. **Recommendations** To resolve the issue, update to version 0.15.2 or later. As a temporary workaround, consider restricting access to the `clusternet-hub` service account to minimize the risk of exploitation. Restrict access to the `cluster-hub` deployment and the `clusternet-system` Kubernetes namespace to prevent malicious users from leveraging the service account. Avoid using the `clusternet:hub` cluster role until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** OpenFeature Operator versions prior to 0.2.32 **Description** The issue allows an attacker to escalate the privileges of any service account in the cluster, assuming the pre-existence of a vulnerability that enables arbitrary code execution. This could lead to modification of cluster state, resulting in Denial of Service (DoS), or reading sensitive data, including secrets. The lax permissions configured on `open-feature-operator-controller-manager` are leveraged to achieve this escalation. **Recommendations** For versions prior to 0.2.32, update to version 0.2.32 to mitigate the issue by restricting the resources the `open-feature-operator-controller-manager` can modify. As a temporary workaround, consider restricting the permissions of the `open-feature-operator-controller-manager` to minimize the risk of exploitation.