chen-keinan/mesh-kridikVerificador automatizado de segurança para clusters Kubernetes com malha de serviço Istio, aplicando melhores práticas por meio de políticas OPA e gerando relatórios de remediação para configurações incorretas.
Melhore a segurança do seu service mesh Kubernetes !!
mesh-kridik é um verificador de segurança de código aberto que realiza várias verificações de segurança em um cluster Kubernetes com service mesh Istio e gera um relatório de segurança.
As verificações de segurança são a implementação completa das melhores práticas de segurança do Istio
As verificações de segurança são realizadas em um cluster Kubernetes com service mesh Istio e são alavancadas pelo OPA (Open Policy Agent) para aplicar regras de segurança. O relatório de auditoria gerado inclui: a causa raiz do problema de segurança e a remediação proposta para o problema.
git clone https://github.com/chen-keinan/mesh-kridik
cd mesh-kridik
make build
Execute o Mesh-Kridik sem flags para executar todos os testes
./mesh-kridik
Execute o mesh-kridik com flags para executar testes sob demanda
Uso: mesh-kridik [--version] [--help] <comando> [<args>]
Comandos disponíveis:
-r , --report : executa verificações de segurança e gera relatório de remediação
-i , --include: executa apenas uma verificação de segurança específica, exemplo -i=1.1
-e , --exclude: ignora uma verificação de segurança específica, exemplo -e=1.1,2.0
Execute testes e gere relatório de testes com falha e suas remediações
./mesh-kridik -r
O Kube-kridik expõe um hook para plugins do usuário Exemplo :
go build -buildmode=plugin -o=~/<pasta_do_plugin>/<plugin>.so ~/<pasta_do_plugin>/<plugin>.go
cp ~/<pasta_do_plugin>/<plugin>.so ~/.kube-kridik/plugins/compile/<plugin>.so
O Kube-kridik suporta estas especificações e pode ser facilmente estendido:
essas especificações podem ser facilmente estendidas alterando os arquivos de especificação na pasta ~/.mesh-kridik/security/mesh/istio
| Nome | Descrição | Impacto |
|---|---|---|
| Mutual TLS | Os proxies Mutual TLS do Istio são configurados no modo permissivo por padrão | os proxies aceitarão tanto tráfego mutual TLS quanto texto simples |
| Padrões de Política de Autorização mais Seguros do Istio | Use padrões ALLOW-com-correspondência-positiva ou DENY-com-correspondência-negativa | Esses padrões de política de autorização são mais seguros porque o pior resultado em caso de incompatibilidade de política é uma rejeição 403 inesperada, em vez de uma burla da política de autorização. |
| normalização de caminho na política de autorização | O ponto de aplicação das políticas de autorização é o proxy Envoy, em vez do ponto de acesso ao recurso usual no aplicativo backend | Uma incompatibilidade pode levar a uma rejeição inesperada ou a uma burla da política |
| Orientação TLS para tráfego de saída | Uso de DestinationRule no ServiceEntry para tráfego de saída | Não usar orientação TLS para tráfego de saída para um serviço externo fará com que seja enviado como texto simples |
| Detecção de protocolo | declarar explicitamente o protocolo do serviço | falha na detecção pode resultar em comportamento inesperado do tráfego |
| Suporte CNI | captura transparente de tráfego do Istio | nem todo tráfego de rede será capturado |
| hosts excessivamente amplos | evitar configurações de hosts excessivamente amplas no Gateway | pode causar exposição potencial de domínios inesperados |
| Restringir privilégios de criação de Gateway | restringir a criação de recursos Gateway a administradores de cluster confiáveis | pode causar criação de gateway por usuários não confiáveis |
| Configurar um limite para conexões downstream | Atualize global_downstream_max_connections no config map de acordo com o número de conexões simultâneas necessárias para instâncias individuais do gateway na sua implantação. Quando o limite for atingido, o Envoy começará a rejeitar conexões TCP | a ausência de limite no número de conexões downstream pode ser explorada por um ator malicioso |
| Configurar tokens de conta de serviço de terceiros | Recomenda-se configurar tokens de terceiros porque as propriedades do token de primeira parte são menos seguras | as propriedades do token de primeira parte são menos seguras e podem causar violação de autenticação |
| Plano de Controle | O Istiod expõe algumas portas de texto simples não autenticadas por conveniência por padrão | expõe a porta 15010 do serviço XDS e a porta de depuração 8080 em texto simples não autenticado |
| Plano de Dados | O proxy expõe várias portas | Os aplicativos em execução no mesmo pod que o proxy têm acesso; não há limite de confiança entre o sidecar e o aplicativo |
| Entender as limitações de captura de tráfego | Proteger o tráfego de saída definindo meshConfig.outboundTrafficPolicy.mode | o acesso a serviços externos não será controlado |