Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame CKS avalia. Leia de cima a baixo ou pule para uma seção.
Avaliar a configuração do cluster em relação às melhores práticas de segurança padrão da indústria.
Use `kube-bench` para executar verificações do CIS Kubernetes Benchmark em nós do plano de controle e worker.
Por quê: `kube-bench` é a ferramenta padrão para esta tarefa específica, automatizando verificações contra diretrizes abrangentes do CIS.
Impor autenticação forte para todas as requisições ao API server.
Defina as flags do `kube-apiserver`: `--anonymous-auth=false` para rejeitar requisições não autenticadas, e `--client-ca-file` para impor a validação de certificado de cliente (mTLS).
Por quê: Estas flags são controles fundamentais para eliminar o acesso anônimo e impor comunicação autenticada e criptografada com o API server.
Proteger o armazenamento de estado etcd do cluster contra acesso não autorizado e roubo de dados.
Configure o etcd com mTLS para toda a comunicação cliente e peer (`--cert-file`, `--key-file`, `--peer-cert-file`). Habilite a criptografia de segredos em repouso via a flag `--encryption-provider-config` do API server.
Por quê: O etcd contém todos os segredos do cluster. Criptografar dados em trânsito (mTLS) e em repouso é crítico para proteger informações sensíveis, mesmo que os nós etcd sejam comprometidos.
Rotacionar chaves de criptografia em repouso do etcd com zero tempo de inatividade.
1. Adicione a nova chave como a primeira entrada no arquivo `EncryptionConfiguration`. 2. Reinicie todos os API servers. 3. Force a recriptografia de todos os segredos (`kubectl get secrets -A -o json | kubectl replace -f -`). 4. Após a verificação, remova a chave antiga da configuração e reinicie os API servers novamente.
Por quê: Alterar a configuração afeta apenas novas gravações. Dados existentes devem ser reescritos para serem criptografados com a nova chave. Remover a chave antiga prematuramente irá impedi-lo de acessar seus dados.
Implementar um modelo de rede de confiança zero dentro de um namespace.
Aplique uma `NetworkPolicy` com um `podSelector: {}` vazio e `policyTypes: [Ingress, Egress]` mas sem regras de `ingress` ou `egress`. Isso seleciona todos os Pods e nega todo o tráfego.
Por quê: Esta política estabelece uma linha de base de "negar tudo", forçando regras explícitas de "permitir" para toda a comunicação necessária, o que é a base da rede de confiança zero.
NetworkPolicies de Egress estão bloqueando a resolução de DNS para Pods.
Adicione uma regra de egress específica para permitir tráfego para o serviço DNS do cluster. Permita egress para a porta 53 em ambos os protocolos UDP e TCP. Selecione os Pods kube-dns via `namespaceSelector` e `podSelector` se possível.
Por quê: NetworkPolicies são granulares. Uma regra de egress geral para um bloco IP pode não cobrir o protocolo específico (UDP) necessário para DNS, levando a falhas de resolução.
Proteger o acesso externo a serviços expostos via um Ingress.
Configure o recurso Ingress adicionando uma seção `tls` que referencia um Secret do Kubernetes do tipo `kubernetes.io/tls`. O Secret deve conter o certificado TLS e a chave privada.
Por quê: Isso centraliza a terminação TLS no controlador Ingress, criptografando o tráfego de clientes para o limite do cluster e simplificando o gerenciamento de certificados para os serviços de backend.
Conceder a usuários ou aplicações apenas as permissões mínimas necessárias.
Use `Roles` e `RoleBindings` com escopo de namespace sempre que possível. Evite `cluster-admin` e curingas (`"*"`) em `verbs` ou `resources`. Conceda permissões específicas como `["get", "list"]` em `["pods"]`.
Por quê: Isso minimiza o raio de impacto caso uma conta ou token seja comprometido, prevenindo movimento lateral e escalada de privilégios.
Reduzir a superfície de ataque para Pods que não precisam interagir com o Kubernetes API.
Desabilite a montagem automática de tokens de conta de serviço definindo `automountServiceAccountToken: false` no ServiceAccount ou na especificação do Pod.
Por quê: Se um Pod for comprometido, um invasor não pode usar um token montado para acessar o API server, prevenindo ataques em nível de cluster originados do Pod comprometido.
Verificar se um usuário ou conta de serviço específico tem permissão para realizar uma ação.
Use `kubectl auth can-i <verb> <resource> --as=<user>` ou `kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa-name>`.
Por quê: Este comando permite a personificação para verificar com precisão as permissões efetivas sem a necessidade de analisar manualmente todos os Roles e Bindings.
Manter a segurança do cluster rotacionando regularmente os certificados do plano de controle e do kubelet.
Para clusters kubeadm, use `kubeadm certs renew all`. Para outros, siga o procedimento de rotação manual ou automatizado documentado. Habilite a rotação de certificados cliente/servidor do kubelet via sua configuração.
Por quê: A rotação regular limita o período de tempo em que um invasor pode usar um certificado comprometido. É uma prática crítica de higiene de segurança.
Um nó worker é suspeito de estar comprometido e deve ser imediatamente isolado.
Primeiro, use `kubectl cordon <nome-do-nó>` para evitar que novos Pods sejam agendados. Em seguida, use `kubectl drain <nome-do-nó> --ignore-daemonsets --delete-emptydir-data` para remover com segurança as cargas de trabalho em execução.
Por quê: Cordoning e draining é o procedimento padrão e não destrutivo para remover um nó de serviço, permitindo que as cargas de trabalho sejam reagendadas em outro lugar, preservando o nó comprometido para análise forense.
Restringir as chamadas de sistema que um container pode fazer ao kernel do host.
No `securityContext` do Pod ou Container, defina `seccompProfile.type` como `RuntimeDefault` para uma linha de base segura, ou `Localhost` com um caminho para um perfil JSON customizado para um controle mais rigoroso.
Por quê: Seccomp reduz a superfície de ataque do kernel de dentro de um container, prevenindo explorações contra vulnerabilidades do kernel ao bloquear syscalls não utilizados ou perigosos.
Confinar processos de container restringindo o acesso a arquivos, capacidades de rede e outros recursos.
Aplique um perfil AppArmor a um container via a anotação: `container.apparmor.security.beta.kubernetes.io/<nome_do_container>: localhost/<nome_do_perfil>`. O perfil deve ser pré-carregado no nó.
Por quê: AppArmor fornece Controle de Acesso Mandatório (MAC), adicionando uma camada crucial de defesa em profundidade para conter uma aplicação comprometida e impedir que ela acesse recursos não autorizados.
Um container precisa de uma operação privilegiada específica (ex: bind para porta 80) sem rodar como root.
No `securityContext.capabilities`, `drop: ["ALL"]` e depois `add: ["NET_BIND_SERVICE"]`.
Por quê: Isso segue o princípio do menor privilégio, concedendo apenas a capacidade Linux específica necessária, evitando as permissões amplas de execução como root.
Impedir que um container obtenha acesso total ao sistema host.
Defina `securityContext.privileged: false` (que é o padrão). Use Pod Security Standards ou OPA/Kyverno para impor isso em todo o cluster.
Por quê: Um container privilegiado possui quase todas as capacidades do host e acesso a dispositivos, desabilitando efetivamente o isolamento do container. É um vetor primário para escape de container.
Impor configurações de segurança de linha de base ou rigorosas para Pods em nível de namespace.
Aplique labels ao namespace, por exemplo, `pod-security.kubernetes.io/enforce: restricted`. Os modos são `enforce`, `audit` e `warn`.
Por quê: Os Padrões de Segurança de Pod (PSS) fornecem uma política de segurança multinível integrada que substitui o PodSecurityPolicy obsoleto, tornando fácil impor as melhores práticas de segurança.
Endurecer um Pod aplicando múltiplos controles de segurança simultaneamente.
Configure um `securityContext` que combine `runAsNonRoot: true`, `allowPrivilegeEscalation: false` e `readOnlyRootFilesystem: true`.
Por quê: Essa abordagem de defesa em profundidade combina múltiplas proteções: prevenção da execução como root, bloqueio de vetores de escalada de privilégios (como setuid) e tornando o sistema de arquivos do container imutável.
Executar cargas de trabalho não confiáveis ou multi-tenant com isolamento mais forte do que containers padrão.
Defina um recurso `RuntimeClass` apontando para um manipulador de tempo de execução isolado (ex: gVisor, Kata Containers). Atribua Pods a ele usando `spec.runtimeClassName`.
Por quê: Tempos de execução isolados usam um kernel em espaço de usuário ou VMs leves para interceptar syscalls, fornecendo uma camada extra de isolamento entre o container e o kernel do host.
Impor políticas de segurança complexas e personalizadas que não são cobertas pelos controles padrão do Kubernetes.
Implante o OPA Gatekeeper. Defina políticas usando `ConstraintTemplate` (a lógica Rego) e aplique-as com recursos `Constraint`.
Por quê: O Gatekeeper atua como um webhook de admissão de validação, permitindo impor regras arbitrárias, como exigir labels específicas, proibir caminhos de host ou impor limites de recursos.
Fornecer segredos para Pods da maneira mais segura.
Monte segredos como arquivos em um volume. Para uma segurança ainda maior, use um driver CSI de armazenamento de segredos para montar segredos de um vault externo (ex: HashiCorp Vault, AWS Secrets Manager) diretamente no Pod.
Por quê: Montar como arquivos é mais seguro do que variáveis de ambiente (que podem ser logadas ou expostas). Um driver CSI evita armazenar o segredo no etcd.
Criptografar e autenticar todo o tráfego de rede Pod-a-Pod automaticamente.
Implante uma service mesh como Istio ou Linkerd. A mesh injeta um proxy sidecar em cada Pod para lidar com a criptografia mTLS, autenticação e aplicação de políticas.
Por quê: Uma service mesh fornece rede transparente de confiança zero sem exigir alterações no código da aplicação, protegendo toda a comunicação interna do serviço.
Prevenir a implantação de imagens de container com vulnerabilidades conhecidas (CVEs).
Integre um scanner como Trivy ou Grype ao pipeline de CI/CD. Falhe a construção se as vulnerabilidades excederem um limite de severidade definido (ex: ALTA ou CRÍTICA).
Por quê: Esta abordagem "shift-left" detecta vulnerabilidades precocemente, antes que atinjam a produção, reduzindo drasticamente a superfície de ataque das aplicações em execução.
Garantir que apenas imagens de container confiáveis e não modificadas sejam implantadas no cluster.
Assine imagens com `cosign` durante o processo de construção de CI. Use um motor de políticas (Kyverno, OPA Gatekeeper) como um controlador de admissão para verificar a assinatura contra uma chave pública antes de permitir que um Pod seja criado.
Por quê: A assinatura criptográfica fornece fortes garantias de integridade da imagem (não foi adulterada) e autenticidade (veio de uma fonte confiável).
Minimizar a superfície de ataque dentro de uma imagem de container.
Use imagens base mínimas (ex: distroless, Alpine). Use um Dockerfile multi-estágio para descartar ferramentas de construção. Defina um usuário não-root com a instrução `USER`. Use `.dockerignore` para excluir arquivos sensíveis.
Por quê: Uma imagem mínima contém menos pacotes e ferramentas, oferecendo menos vulnerabilidades potenciais e tornando mais difícil para um invasor pivotar se o container for comprometido.
Impor uma política de que todas as imagens implantadas devem ser originadas do registro privado da organização.
Use um controlador de admissão (como OPA Gatekeeper ou Kyverno) para criar uma política que valide o campo `image` de todas as especificações de container contra uma lista de permissão de nomes de host de registro.
Por quê: Isso impede que desenvolvedores puxem imagens não confiáveis ou não escaneadas de repositórios públicos como o Docker Hub, garantindo que todo o código tenha passado por verificações de segurança internas.
Manter um inventário de todos os componentes de software e dependências dentro de uma imagem de container.
Integre uma ferramenta como `Syft` no pipeline de CI/CD para gerar uma Lista de Materiais de Software (SBOM) em um formato padrão como SPDX ou CycloneDX.
Por quê: Uma SBOM é essencial para a segurança da cadeia de suprimentos, permitindo a rápida identificação de todos os ativos afetados quando uma nova vulnerabilidade é descoberta em uma dependência.
Identificar configurações de segurança incorretas em manifestos YAML do Kubernetes antes que sejam aplicados.
No pipeline de CI, use uma ferramenta como `trivy config` ou `kubesec` para escanear arquivos de manifesto do Kubernetes em busca de configurações arriscadas, como execução como root, permissão de escalada de privilégios ou montagem de caminhos de host sensíveis.
Por quê: Esta verificação proativa detecta problemas de segurança na infraestrutura como código antes que criem vulnerabilidades no cluster em execução.
Detectar e alertar sobre atividades suspeitas dentro de containers em execução ou em nós do cluster.
Implante Falco como um DaemonSet. Falco usa eBPF ou um módulo de kernel para monitorar chamadas de sistema e alerta sobre comportamento anômalo com base em seu conjunto de regras (ex: shell em container, conexões de rede inesperadas).
Por quê: Falco fornece visibilidade em tempo real do comportamento em tempo de execução, permitindo a detecção de ameaças como escapes de container, cryptomining ou exfiltração de dados que a varredura estática não consegue ver.
Uma regra padrão do Falco está gerando muitos falsos positivos.
Crie um arquivo de regras Falco personalizado para sobrescrever a regra padrão. Adicione exceções à `condition` da regra para excluir comportamentos conhecidos como bons, como processos específicos ou imagens de container (ex: `and not container.image.repository contains "debug"`).
Por quê: Ajustar regras é crítico para operacionalizar a segurança em tempo de execução. Reduzir o ruído garante que as equipes de segurança possam se concentrar em alertas acionáveis e de alta prioridade.
Registrar um log cronológico e imutável de todas as ações realizadas contra o Kubernetes API.
Habilite o log de auditoria no `kube-apiserver` fornecendo as flags `--audit-policy-file` e `--audit-log-path`. Configure a política para definir o que é logado e em qual nível.
Por quê: Logs de auditoria são essenciais para análise de segurança, investigação de incidentes e conformidade. Eles fornecem um registro definitivo de quem fez o quê, e quando.
Auditar o acesso a recursos sensíveis como Secrets sem registrar o conteúdo do segredo em si.
Configure a regra da política de auditoria para Secrets para usar `level: Metadata`. Isso registra o usuário, timestamp, recurso e verbo, mas omite os corpos da requisição e da resposta.
Por quê: Isso fornece responsabilidade sobre quem está acessando segredos sem criar um novo risco de segurança ao escrever dados sensíveis nos logs de auditoria.
Agregar logs de todos os componentes e aplicações do cluster para análise centralizada.
Implante um agente de coleta de logs (ex: Fluentd, Vector) como um DaemonSet para coletar logs dos nós e encaminhá-los para um SIEM centralizado ou sistema de gerenciamento de logs (ex: Elasticsearch, Splunk).
Por quê: O log centralizado é crucial para correlacionar eventos em todo o cluster durante uma investigação de incidente e para manter registros de longo prazo para conformidade.
Encaminhar alertas de segurança do Falco para um sistema externo para notificação e resposta.
Implante `Falcosidekick` junto com Falco. Configure-o para receber alertas do Falco e encaminhá-los para saídas como Slack, PagerDuty ou um SIEM.
Por quê: Falcosidekick fornece um mecanismo flexível e robusto para integrar os alertas em tempo real do Falco em fluxos de trabalho operacionais e de segurança existentes.
Detectar se um container em execução foi modificado, o que poderia indicar um comprometimento.
Imponha containers imutáveis com `readOnlyRootFilesystem: true`. Use uma ferramenta de segurança em tempo de execução como Falco para monitorar e alertar sobre quaisquer gravações de arquivo em locais inesperados.
Por quê: Em um modelo imutável, os containers nunca são alterados em tempo de execução; eles são substituídos. Qualquer desvio desse padrão é um forte indicador de uma potencial violação de segurança.