From 32b14fab56c86e9dcb8883ee067397b207b6668f Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 14 Apr 2025 22:06:58 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus --- .../README.md | 111 ++++++++++++++---- .../kubernetes-network-attacks.md | 48 ++++++-- 2 files changed, 125 insertions(+), 34 deletions(-) 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 bdfaf7f8d..16563f747 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 @@ -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://: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://: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/' bin @@ -246,13 +246,13 @@ mount -o rw,remount /hostlogs/ ``` #### Bypassing hostPath readOnly protection -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=` 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 @@ -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 `/` 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 @@ -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. diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md b/src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md index 1783fafb2..0c4682c9a 100644 --- 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