derailed/popeye👀 Um sanitizador de recursos de clusters Kubernetes
Popeye é um utilitário que escaneia clusters Kubernetes ao vivo e relata potenciais problemas com recursos e configurações implantados. À medida que o panorama do Kubernetes cresce, está se tornando um desafio para um humano acompanhar a infinidade de manifestos e políticas que orquestram um cluster. O Popeye escaneia seu cluster com base no que está implantado e não no que está no disco. Ao fazer linting do seu cluster, ele detecta configurações incorretas, recursos obsoletos e ajuda você a garantir que as melhores práticas estejam em vigor, evitando futuras dores de cabeça. Ele visa reduzir a sobrecarga cognitiva que se enfrenta ao operar um cluster Kubernetes no mundo real. Além disso, se seu cluster emprega um metric-server, ele relata potenciais alocações excessivas ou insuficientes de recursos e tenta avisar se seu cluster ficar sem capacidade.
Popeye é uma ferramenta somente leitura, ela não altera nenhum dos seus recursos Kubernetes de forma alguma!
Você pode gerar o relatório de varredura em HTML.
Popeye publica métricas do Prometheus. Fornecemos um painel Popeye de amostra para você começar neste repositório.
O Popeye está disponível nas plataformas Linux, OSX e Windows.
Binários para Linux, Windows e Mac estão disponíveis como tarballs na página de release.
Para OSX/Unit usando Homebrew/LinuxBrew ```shell brew install derailed/popeye/popeye
Usando go install
go install github.com/derailed/popeye@latest
Construindo a partir do código-fonte O Popeye foi construído usando go 1.21+. Para construir o Popeye a partir do código-fonte, você deve:
Clone o repositório
Adicione o seguinte comando no seu arquivo go.mod
replace (
github.com/derailed/popeye => MY_POPEYE_CLONED_GIT_REPO
)
Construa e execute o executável
go run main.go
Receita rápida para os impacientes: ```shell
git clone https://github.com/derailed/popeye cd popeye
make build
popeye
Popeye usa modo de terminal com 256 cores. Em sistema `Nix, certifique-se de que TERM está configurado adequadamente.
export TERM=xterm-256color
Você pode usar Popeye totalmente aberto ou usando um arquivo de configuração spinach yaml para ajustar seus linters. Detalhes sobre o arquivo de configuração do Popeye estão abaixo.```shell
popeye version
popeye
fred namespacepopeye -n fred
popeye -A
popeye -f spinach.yaml
popeye --context olive
popeye -n ns1 -s pod,svc --logs none
popeye -n ns1 --logs /tmp/fred.log -v4
popeye help
---
## Linters
Popeye verifica seu cluster em busca de melhores práticas e possíveis problemas.
Atualmente, Popeye verifica apenas um conjunto específico de recursos Kubernetes selecionados.
Mais virão em breve!
Esperamos que os amigos do Kubernetes contribuam para tornar o Popeye ainda melhor.
O objetivo dos linters é detectar configurações incorretas, ou seja, coisas como incompatibilidade de portas, recursos mortos ou não utilizados, utilização de métricas, probes, imagens de contêineres, regras RBAC, recursos "nus" (naked), etc...
Popeye não é apenas mais uma ferramenta de análise estática. Ele executa e inspeciona recursos Kubernetes em clusters ativos e faz lint dos recursos como eles estão no ambiente real!
Aqui está uma lista de alguns linters disponíveis:
| | Resource | Linters | Aliases |
|----|-------------------------|-------------------------------------------------------------------------|------------|
| 🛀 | Node | | no |
| | | Condições: não pronto, sem memória/disco, rede, pids, etc | |
| | | Tolerâncias de pods referenciando taints do nó | |
| | | Métricas de utilização de CPU/MEM, aciona se ultrapassar os limites (padrão 80% CPU/MEM) | |
| 🛀 | Namespace | | ns |
| | | Inativo | |
| | | Namespaces mortos | |
| 🛀 | Pod | | po |
| | | Status do pod | |
| | | Status dos contêineres | |
| | | Presença de ServiceAccount | |
| | | CPU/MEM em contêineres acima de um limite definido (padrão 80% CPU/MEM) | |
| | | Imagem de contêiner sem tags | |
| | | Imagem de contêiner usando tag `latest` | |
| | | Presença de request/limits de recursos | |
| | | Presença de probes liveness/readiness | |
| | | Portas nomeadas e suas referências | |
| 🛀 | Service | | svc |
| | | Presença de endpoints | |
| | | Labels de pods correspondentes | |
| | | Portas nomeadas e suas referências | |
| 🛀 | ServiceAccount | | sa |
| | | Não utilizados, detecta SAs potencialmente não utilizados | |
| 🛀 | Secrets | | sec |
| | | Não utilizados, detecta segredos ou chaves associadas potencialmente não utilizadas | |
| 🛀 | ConfigMap | | cm |
| | | Não utilizados, detecta ConfigMaps ou chaves associadas potencialmente não utilizados | |
| 🛀 | Deployment | | dp, deploy |
| | | Não utilizados, validação de template de pod, utilização de recursos | |
| 🛀 | StatefulSet | | sts |
| | | Não utilizados, validação de template de pod, utilização de recursos | |
| 🛀 | DaemonSet | | ds |
| | | Não utilizados, validação de template de pod, utilização de recursos | |
| 🛀 | PersistentVolume | | pv |
| | | Não utilizados, verifica volume vinculado ou erro de volume | |
| 🛀 | PersistentVolumeClaim | | pvc |
| | | Não utilizados, verifica vinculado ou erro de montagem de volume | |
| 🛀 | HorizontalPodAutoscaler | | hpa |
| | | Não utilizados, Utilização, Verificações de burst máximo | |
| 🛀 | PodDisruptionBudget | | |
| | | Não utilizados, Verifica configuração minAvailable | pdb |
| 🛀 | ClusterRole | | |
| | | Não utilizado | cr |
| 🛀 | ClusterRoleBinding | | |
| | | Não utilizado | crb |
| 🛀 | Role | | |
| | | Não utilizado | ro |
| 🛀 | RoleBinding | | |
| | | Não utilizado | rb |
| 🛀 | Ingress | | |
| | | Válido | ing |
| 🛀 | NetworkPolicy | | |
| | | Válida, Obsoleta, Protegida | np |
| 🛀 | PodSecurityPolicy | | |
| | | Válido | psp |
| 🛀 | Cronjob | | |
| | | Válido, Suspenso, Execuções | cj |
| 🛀 | Job | | |
| | | Verificações de pod | job |
| 🛀 | GatewayClass | | |
| | | Válido, Não utilizado | gwc |
| 🛀 | Gateway | | |
| | | Válido, Não utilizado | gw |
| 🛀 | HTTPRoute | | |
| | | Válido, Não utilizado | gwr |
Você também pode ver a [lista completa de códigos](https://github.com/derailed/popeye/blob/HEAD/docs/codes.md)
---
## Salvando verificações
Para salvar o relatório do Popeye em um arquivo, passe a flag `--save` no comando.
Por padrão, ele criará um diretório tmp e armazenará seu relatório de verificação lá.
O caminho do diretório tmp será exibido no STDOUT.
Se precisar especificar o diretório de saída para o relatório, você pode usar a variável de ambiente `POPEYE_REPORT_DIR`. O caminho final será <POPEYE_REPORT_DIR>/<cluster>/<context>.
Por padrão, o nome do arquivo de saída segue o seguinte formato: `lint_<cluster-name>_<time-UnixNano>.<output-extension>` (por exemplo: "lint-mycluster-1594019782530851873.html").
Se você também quiser especificar o nome do arquivo de saída para o relatório, pode passar a flag `--output-file` com o nome do arquivo desejado como parâmetro.
Exemplo para salvar o relatório no diretório de trabalho:```shell
POPEYE_REPORT_DIR=$(pwd) popeye --save
Exemplo para salvar relatório no diretório de trabalho em formato HTML com o nome "report.html" :```shell POPEYE_REPORT_DIR=$(pwd) popeye --save --out html --output-file report.html
### Salvar no S3 Object Store
Alternativamente, você pode enviar os relatórios gerados para um armazenamento de objetos AWS S3 ou Minio fornecendo a flag `--s3-bucket`.
Para os parâmetros, você precisa fornecer o nome do bucket S3 onde deseja armazenar o relatório.
Para salvar o relatório em um subdiretório do bucket, forneça o parâmetro do bucket como `bucket/path/to/report`.
Exemplo para salvar relatório no S3:```shell
# AWS S3
# NOTE: You must provide env vars for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
# This will create bucket my-popeye if not present and upload a popeye json report to /fred/scan.json
popeye --s3-bucket s3://my-popeye/fred --s3-region us-west-2 --out json --save --output-file scan.json
# Minio Object Store
# NOTE: You must provide env vars for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY and a minio server URI
# This will create bucket my-popeye if not present and upload a popeye json report to /fred/scan.json
popeye --s3-bucket minio://my-popeye/fred --s3-region us-east --s3-endpoint localhost:9000 --out json --save --output-file scan.json
Você também pode executar o Popeye em um contêiner executando-o diretamente do repositório oficial do Docker no Quay.
O comando padrão ao executar o contêiner docker é popeye, para você personalizar a varredura usando as flags de CLI suportadas.
Para acessar seus clusters, mapeie o diretório local do kubeconfig para dentro do contêiner com -v :```shell
docker run --rm -it -v $HOME/.kube:/root/.kube quay.io/derailed/popeye --context foo -n bar
Executar o comando docker acima com `--rm` significa que o contêiner é excluído quando o Popeye é encerrado.
Quando você usa `--save`, ele escreve em /tmp no contêiner e depois exclui o contêiner quando o popeye é encerrado, o que significa que você perde a saída ;(
Para contornar isso, mapeie /tmp para o /tmp do contêiner.
> NOTA: Você pode substituir o local padrão do diretório de saída definindo a variável de ambiente `POPEYE_REPORT_DIR`.```shell
docker run --rm -it \
-v $HOME/.kube:/root/.kube \
-e POPEYE_REPORT_DIR=/tmp/popeye \
-v /tmp:/tmp \
quay.io/derailed/popeye --context foo -n bar --save --output-file my_report.txt
# Docker has exited, and the container has been deleted, but the file
# is in your /tmp directory because you mapped it into the container
cat /tmp/popeye/my_report.txt
<snip>
O Popeye pode gerar relatórios de linter em vários formatos. Você pode usar a opção -o e escolher seu veneno.
O Popeye pode publicar métricas do Prometheus diretamente de uma varredura. Você precisará ter acesso a um pushgateway do Prometheus e credenciais.
NOTA! Estes estão sujeitos a alterações com base no feedback e uso dos usuários!!
Para publicar métricas, argumentos adicionais da CLI devem estar presentes.```shell
popeye --push-gtwy-url http://localhost:9091
popeye -o html --save --push-gtwy-url http://localhost:9091
### Métricas do PopProm
As seguintes métricas do Popeye prometheus são publicadas:
* `popeye_severity_total` [gauge] rastreia várias contagens com base na severidade.
* `popeye_code_total` [gauge] rastreia contagens por códigos de linter do Popeye.
* `popeye_linter_tally_total` [gauge] rastreia contagens por linters.
* `popeye_report_errors_total` [gauge] rastreia totais de erros de varredura.
* `popeye_cluster_score` [gauge] rastreia pontuações do relatório de varredura.
### PopGraf
Um dashboard de exemplo do [Grafana](https://grafana.com) pode ser encontrado neste repositório para começar.
> NOTA! Trabalho em andamento, sinta-se à vontade para contribuir se você tiver habilidades em UX/grafana/promql.
---
## SpinachYAML
Um arquivo de configuração spinach YAML pode ser especificado via a opção `-f` para configurar ainda mais os linters. Este arquivo pode especificar o limite de utilização do contêiner e configurações específicas do linter, bem como recursos e códigos que serão excluídos do linter.
> NOTA! Este arquivo mudará à medida que o Popeye amadurecer!
Na chave `excludes` você pode configurar para ignorar certos recursos ou códigos de linter. Os linters do Popeye são nomeados após os nomes dos recursos do k8s. Por exemplo, o linter PodDisruptionBudget é nomeado `poddisruptionbudgets` e varre `policy/v1/poddisruptionbudgets`
> NOTA! O linter usa a forma plural do recurso `kind` e tudo é escrito em minúsculas.
Um nome totalmente qualificado de recurso, também conhecido como `FQN`, é usado no arquivo spinach para identificar um nome de recurso, ou seja, `namespace/resource_name`. Por exemplo, o FQN de um pod chamado `fred-1234` no namespace `blee` será `blee/fred-1234`. Isso permite diferenciar `fred/p1` e `blee/p1`. Para recursos de cluster, o FQN é equivalente ao nome. As regras de exclusão podem ser uma correspondência direta de string ou uma expressão regular. Neste último caso, a expressão regular deve ser especificada através do prefixo `rx:`.
> NOTA! Tenha cuidado com sua regex, pois mais recursos do que o esperado podem ser excluídos do relatório com uma regra de regex *solta*. Quando seus recursos de cluster mudam, isso pode levar a varreduras sub-ótimas. Portanto, recomendamos executar o Popeye `wide open` de vez em quando para garantir que você detectará quaisquer novos problemas que possam ter surgido em seus clusters…
Aqui está um exemplo de arquivo spinach como está nesta versão. Há um arquivo spinach mais completo baseado em eks e aks neste repositório em `spinach`. (A propósito: para novos participantes do projeto, pode ser uma ótima maneira de contribuir adicionando PRs de arquivos spinach específicos de cluster...)```yaml
# spinach.yaml
# A Popeye sample configuration file
popeye:
# Checks resources against reported metrics usage.
# If over/under these thresholds a linter warning will be issued.
# Your cluster must run a metrics-server for these to take place!
allocations:
cpu:
underPercUtilization: 200 # Checks if cpu is under allocated by more than 200% at current load.
overPercUtilization: 50 # Checks if cpu is over allocated by more than 50% at current load.
memory:
underPercUtilization: 200 # Checks if mem is under allocated by more than 200% at current load.
overPercUtilization: 50 # Checks if mem is over allocated by more than 50% usage at current load.
# Excludes excludes certain resources from Popeye scans
excludes:
# [NEW!] Global exclude resources and codes globally of any linters.
global:
fqns: [rx:^kube-] # => excludes all resources in kube-system, kube-public, etc..
# [NEW!] Exclude resources for all linters matching these labels
labels:
app: [bozo, bono] #=> exclude any resources with labels matching either app=bozo or app=bono
# [NEW!] Exclude resources for all linters matching these annotations
annotations:
fred: [blee, duh] # => exclude any resources with annotations matching either fred=blee or fred=duh
# [NEW!] Exclude scan codes globally via straight codes or regex!
codes: ["300", "206", "rx:^41"] # => exclude issue codes 300, 206, 410, 415 (Note: regex match!)
# [NEW!] Configure individual resource linters
linters:
# Configure the namespaces linter for v1/namespaces
namespaces:
# [NEW!] Exclude these codes for all namespace resources straight up or via regex.
codes: ["100", "rx:^22"] # => exclude codes 100, 220, 225, ...
# [NEW!] Excludes specific namespaces from the scan
instances:
- fqns: [kube-public, kube-system] # => skip ns kube-pulbic and kube-system
- fqns: [blee-ns]
codes: [106] # => skip code 106 for namespace blee-ns
# Skip secrets in namespace bozo.
secrets:
instances:
- fqns: [rx:^bozo]
# Configure the pods linter for v1/pods.
pods:
instances:
# [NEW!] exclude all pods matching these labels.
- labels:
app: [fred,blee] # Exclude codes 102, 105 for any pods with labels app=fred or app=blee
codes: [102, 105]
resources:
# Configure node resources.
node:
# Limits set a cpu/mem threshold in % ie if cpu|mem > limit a lint warning is triggered.
limits:
# CPU checks if current CPU utilization on a node is greater than 90%.
cpu: 90
# Memory checks if current Memory utilization on a node is greater than 80%.
memory: 80
# Configure pod resources
pod:
# Restarts check the restarts count and triggers a lint warning if above threshold.
restarts: 3
# Check container resource utilization in percent.
# Issues a lint warning if about these threshold.
limits:
cpu: 80
memory: 75
# [New!] overrides code severity
overrides:
# Code specifies a custom severity level ie critical=3, warn=2, info=1
- code: 206
severity: 1
# Configure a list of allowed registries to pull images from.
# Any resources not using the following registries will be flagged!
registries:
- quay.io
- docker.io
Popeye está containerizado e pode ser executado diretamente nos seus clusters Kubernetes como um job único ou CronJob.
Aqui está um exemplo de configuração, por favor modifique conforme suas necessidades/desejos. Os manifestos para isso estão no diretório k8s neste repositório.```shell kubectl apply -f k8s/popeye
- [pentest_function_based_onDomain_for_burpsuite](#pentest_function_based_ondomain_for_burpsuite)
* [instalação](#installation)
+ [java](#java)
+ [burpsuite配置](#burpsuite%E9%85%8D%E7%BD%AE)
+ [修改txt](#%E4%BF%AE%E6%94%B9txt)```yaml
---
apiVersion: v1
kind: Namespace
metadata:
name: popeye
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: popeye
namespace: popeye
spec:
schedule: "* */1 * * *" # Fire off Popeye once an hour
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
serviceAccountName: popeye
restartPolicy: Never
containers:
- name: popeye
image: derailed/popeye:vX.Y.Z
imagePullPolicy: IfNotPresent
args:
- -o
- yaml
- --force-exit-zero
resources:
limits:
cpu: 500m
memory: 100Mi
A opção --force-exit-zero deve ser definida. Caso contrário, os pods terminarão em estado de erro.
NOTA! O Popeye sai com um código de erro diferente de zero se algum erro de lint for detectado.
Para que o Popeye possa fazer seu trabalho, o usuário conectado deve ter força RBAC suficiente para obter/listar os recursos mencionados acima.
Exemplos de Regras RBAC do Popeye (observe que elas estão sujeitas a alterações.)
NOTA! Por favor, revise e ajuste de acordo com as políticas do seu cluster.```yaml
apiVersion: v1 kind: ServiceAccount metadata: name: popeye namespace: popeye
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: popeye rules:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: popeye subjects:
---
## Morfologia do Relatório
O relatório de lint exibe cada grupo de recursos verificado e seus possíveis problemas.
O relatório é codificado por cores/emoji em termos de níveis de severidade do linter:
| Nível | Ícone | Jurássico | Cor | Descrição |
|-------|-------|-----------|------------|---------------------|
| Ok | ✅ | OK | Verde | Feliz! |
| Info | 🔊 | I | VerdeAzul | Informação |
| Warn | 😱 | W | Amarelo | Possível Problema |
| Error | 💥 | E | Vermelho | Ação necessária |
A seção de cabeçalho para cada recurso Kubernetes verificado fornece uma contagem resumida
para cada uma das categorias acima.
A seção de Resumo fornece um **Popeye Score** com base na passagem do linter no cluster fornecido.
---
## Problemas Conhecidos
Esta versão inicial é frágil. Popeye provavelmente vai explodir quando…
* Você está executando versões antigas do Kubernetes. Popeye funciona melhor com Kubernetes 1.25.X.
* Você não tem poder RBAC suficiente para gerenciar seu cluster (veja a seção RBAC)
---
## Aviso Legal
Este é um trabalho em andamento! Se houver interesse suficiente na comunidade
Kubernetes, melhoraremos de acordo com suas recomendações/contribuições.
Além disso, se você gostar deste esforço, por favor, nos avise também!
---
## Parabéns, Garotas/Garotos!
Popeye se baseia em muitos projetos e bibliotecas de código aberto. Nossa *sincera*
gratidão a todos os contribuidores de OSS que trabalham noites e fins de semana
para tornar este projeto realidade!
### Informações de Contato
1. **Email**: [email protected]
2. **Twitter**: [@kitesurfer](https://twitter.com/kitesurfer?lang=en)
---
<img src="https://raw.githubusercontent.com/derailed/popeye/master/assets/imhotep_logo.png" width="32" height="auto"/> © 2025 Imhotep Software LLC.
Todos os materiais licenciados sob [Apache v2.0](http://www.apache.org/licenses/LICENSE-2.0)
| Formato | Descrição | Padrão | Créditos |
|---|
| standard | Saída completa com ícones e colorida | sim | |
| jurassic | Sem ícones nem cores, como em 1979 | ||
| yaml | Como YAML | ||
| html | Como HTML | ||
| json | Como JSON | ||
| junit | Para os melancólicos do Java | ||
| prometheus | Despeja relatório como métricas do Prometheus | dardanel | |
| score | Retorna um único valor de pontuação do linter do cluster (0-100) | kabute |