aquasecurity/kube-hunterCaça por fraquezas de segurança em clusters Kubernetes
O kube-hunter não está mais em desenvolvimento ativo. Se você está interessado em escanear clusters Kubernetes em busca de vulnerabilidades conhecidas, recomendamos usar o Trivy. Especificamente, a varredura de configuração incorreta e a varredura de vulnerabilidades KBOM do Trivy para Kubernetes. Saiba mais nos Documentos do Trivy.
O kube-hunter caça por pontos fracos de segurança em clusters Kubernetes. A ferramenta foi desenvolvida para aumentar a conscientização e visibilidade sobre problemas de segurança em ambientes Kubernetes. Você NÃO deve executar o kube-hunter em um cluster Kubernetes que não seja seu!
Execute o kube-hunter: O kube-hunter está disponível como um contêiner (aquasec/kube-hunter), e também oferecemos um site em kube-hunter.aquasec.com onde você pode se registrar online para receber um token que permite visualizar e compartilhar os resultados online. Você também pode executar o código Python você mesmo, conforme descrito abaixo.
Explore vulnerabilidades: A base de conhecimento do kube-hunter inclui artigos sobre vulnerabilidades e problemas detectáveis. Quando o kube-hunter relata um problema, ele mostra seu VID (ID de Vulnerabilidade) para que você possa consultá-lo na KB em https://aquasecurity.github.io/kube-hunter/
Se você está interessado na integração do kube-hunter com a Matriz ATT&CK do Kubernetes, Continue Lendo
Vídeo de demonstração do kube-hunter
O kube-hunter agora suporta o novo formato da matriz ATT&CK do Kubernetes. Enquanto as vulnerabilidades do kube-hunter são uma coleção de técnicas criativas projetadas para imitar um invasor no cluster (ou fora dele), O ATT&CK do Mitre define categorias padronizadas mais gerais de técnicas para fazer isso.
Você pode pensar nas vulnerabilidades do kube-hunter como pequenos passos para um invasor, que seguem a trilha de uma técnica mais geral que ele buscaria. A maioria dos caçadores e vulnerabilidades do kube-hunter podem se enquadrar nessas técnicas, por isso passamos a seguir o padrão da Matriz.
Algumas vulnerabilidades do kube-hunter que não pudemos mapear para uma técnica do Mitre são prefixadas com a palavra-chave General
Existem três maneiras diferentes de executar o kube-hunter, cada uma oferecendo uma abordagem diferente para detectar pontos fracos no seu cluster:
Execute o kube-hunter em qualquer máquina (incluindo seu notebook), selecione a varredura Remota e forneça o endereço IP ou nome de domínio do seu cluster Kubernetes. Isso lhe dará uma visão do atacante sobre sua configuração Kubernetes.
Você pode executar o kube-hunter diretamente em uma máquina no cluster e selecionar a opção de sondar todas as interfaces de rede locais.
Você também pode executar o kube-hunter em um pod dentro do cluster. Isso indica o quão exposto seu cluster estaria se um de seus pods de aplicação fosse comprometido (através de uma vulnerabilidade de software, por exemplo). (sinalizador --pod)
Primeiro verifique estes pré-requisitos.
Por padrão, o kube-hunter abrirá uma sessão interativa, na qual você poderá selecionar uma das seguintes opções de varredura. Você também pode especificar a opção de varredura manualmente pela linha de comando. Estas são suas opções:
Para especificar máquinas remotas para caça, selecione a opção 1 ou use a opção --remote. Exemplo:
kube-hunter --remote algum.node.com
Para especificar a varredura de interface, você pode usar a opção --interface (isso irá escanear todas as interfaces de rede da máquina). Exemplo:
kube-hunter --interface
Para especificar um CIDR específico para escanear, use a opção --cidr. Exemplo:
kube-hunter --cidr 192.168.0.0/24
Defina o sinalizador --k8s-auto-discover-nodes para consultar o Kubernetes por todos os nós no cluster e, em seguida, tentar escanear todos eles. Por padrão, usará a configuração no cluster para conectar à API do Kubernetes. Se você quiser usar um arquivo kubeconfig explícito, defina --kubeconfig /local/do/arquivo/kubeconfig.
Observe também que isso é sempre feito ao usar o modo --pod.
Para imitar um invasor em seus estágios iniciais, o kube-hunter não requer autenticação para a caça.
Personificar - Você pode fornecer ao kube-hunter um token de conta de serviço específico para usar durante a caça, passando manualmente o token JWT Bearer do segredo da conta de serviço com o sinalizador --service-account-token.
Exemplo:
$ kube-hunter --active --service-account-token eyJhbGciOiJSUzI1Ni...
Ao executar com o sinalizador --pod, o kube-hunter usa o token da conta de serviço montado dentro do pod para autenticar nos serviços que encontrar durante a caça.
--service-account-token tem prioridade ao executar como um podA caça ativa é uma opção na qual o kube-hunter irá explorar vulnerabilidades que encontrar, para buscar mais vulnerabilidades. A principal diferença entre a caça normal e a ativa é que uma caça normal nunca altera o estado do cluster, enquanto a caça ativa pode potencialmente realizar operações de mudança de estado no cluster, o que pode ser prejudicial.
Por padrão, o kube-hunter não faz caça ativa. Para caçar ativamente um cluster, use o sinalizador --active. Exemplo:
kube-hunter --remote algum.dominio.com --active
Você pode ver a lista de testes com a opção --list. Exemplo:
kube-hunter --list
Para ver também os testes de caça ativa, além dos passivos:
kube-hunter --list --active
Para ver apenas um mapeamento da rede dos seus nós, execute com a opção --mapping. Exemplo:
kube-hunter --cidr 192.168.0.0/24 --mapping
Isso exibirá todos os nós Kubernetes que o kube-hunter encontrou.
Para controlar o registro de logs, você pode especificar um nível de log, usando a opção --log. Exemplo:
kube-hunter --active --log WARNING
Os níveis de log disponíveis são:
Por padrão, o relatório será enviado para stdout, mas você pode especificar métodos diferentes usando a opção --dispatch. Exemplo:
kube-hunter --report json --dispatch http
Os métodos de envio disponíveis são:
Ao executar como um Pod em um ambiente Azure ou AWS, o kube-hunter buscará sub-redes no Serviço de Metadados de Instância. Naturalmente, isso torna o processo de descoberta mais demorado.
Para limitar rigidamente a varredura de sub-redes a um CIDR /24, use a opção --quick.
A caça personalizada permite que usuários avançados tenham controle sobre quais caçadores são registrados no início de uma caça. Se você sabe o que está fazendo, isso pode ajudar se quiser ajustar o processo de caça e descoberta do kube-hunter para suas necessidades.
Exemplo:
kube-hunter --custom <NomeDoCaçador1> <NomeDoCaçador2>
Ativar a caça personalizada remove todos os caçadores do processo de caça, exceto os caçadores fornecidos na lista de permissões.
O sinalizador --custom lê uma lista de nomes de classes de caçadores. Para visualizar todos os nomes de classes do kube-hunter, você pode combinar o sinalizador --raw-hunter-names com o sinalizador --list.
Exemplo:
kube-hunter --active --list --raw-hunter-names
Aviso: Devido ao design arquitetônico do kube-hunter, os seguintes "Caçadores/Classes Principais" sempre serão registrados (mesmo ao usar caça personalizada):
Existem três métodos para implantar o kube-hunter:
Você pode executar o kube-hunter diretamente na sua máquina.
Você precisará ter instalado:
Instalar:
pip install kube-hunter
Executar:
kube-hunter
Clone o repositório:
git clone https://github.com/aquasecurity/kube-hunter.git
Instale as dependências do módulo. (Você pode preferir fazer isso dentro de um Ambiente Virtual).
cd ./kube-hunter
pip install -r requirements.txt
Executar:
python3 kube_hunter
Se você quiser usar pyinstaller/py2exe, primeiro execute o script install_imports.py.
A Aqua Security mantém uma versão containerizada do kube-hunter em aquasec/kube-hunter:aqua. Este contêiner inclui este código-fonte, além de um plugin de relatório adicional (código fechado) para enviar resultados para um relatório que pode ser visualizado em kube-hunter.aquasec.com. Observe que executar o contêiner aquasec/kube-hunter e enviar dados de relatórios estão sujeitos a termos e condições adicionais.
O Dockerfile neste repositório permite que você construa uma versão containerizada sem o plugin de relatório.
Se você executar o contêiner kube-hunter com a rede do host, ele poderá sondar todas as interfaces no host:
docker run -it --rm --network host aquasec/kube-hunter
Nota para Docker for Mac/Windows: Esteja ciente de que o "host" para Docker for Mac ou Windows é a VM onde o Docker executa os contêineres. Portanto, especificar --network host permite que o kube-hunter acesse as interfaces de rede dessa VM, em vez das da sua máquina.
Por padrão, o kube-hunter é executado em modo interativo. Você também pode especificar a opção de varredura com os parâmetros descritos acima, por exemplo:
docker run --rm aquasec/kube-hunter --cidr 192.168.0.0/24
Esta opção permite descobrir o que executar um contêiner malicioso pode fazer/descobrir no seu cluster. Isso fornece uma perspectiva sobre o que um invasor poderia fazer se conseguisse comprometer um pod, talvez através de uma vulnerabilidade de software. Isso pode revelar significativamente mais vulnerabilidades.
O arquivo de exemplo job.yaml define um Job que executará o kube-hunter em um pod, usando as configurações de acesso padrão do pod Kubernetes. (Você pode modificar esta definição, por exemplo, para executar como um usuário não root ou em um namespace diferente.)
kubectl create -f ./job.yamlkubectl describe job kube-hunterkubectl logs <nome do pod>Para ler as diretrizes de contribuição, Clique aqui
Este repositório está disponível sob a Apache License 2.0.