Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame KCSA avalia. Leia de cima a baixo ou pule para uma seção.
Projetando uma estratégia de segurança nativa da nuvem holística.
Implementar controles de segurança nas 4Cs: Nuvem (fundação), Cluster, Contêiner e Código.
Por quê: Um comprometimento em uma camada externa (por exemplo, Nuvem) mina a segurança de todas as camadas internas. A segurança é tão forte quanto seu elo mais fraco.
Protegendo contra falhas de segurança de ponto único.
Implementar múltiplos controles de segurança sobrepostos em diferentes camadas (por exemplo, NetworkPolicies, RBAC, Security Contexts).
Por quê: Se um controle falhar ou for ignorado, outras camadas continuam a fornecer proteção, aumentando a dificuldade para o atacante.
Protegendo o tráfego de rede em um ambiente onde a localização da rede não é um limite confiável.
Implementar um modelo de "nunca confiar, sempre verificar". Autenticar e autorizar cada solicitação, tipicamente usando uma service mesh para mTLS.
Por quê: Assume que as ameaças podem existir tanto dentro quanto fora da rede, eliminando a confiança implícita baseada na posição da rede.
Limitando o raio de explosão de uma identidade ou componente comprometido.
Conceder a todos os sujeitos (usuários, contas de serviço, nós) apenas as permissões mínimas necessárias para desempenhar sua função.
Por quê: Reduz o dano potencial que um atacante pode causar com credenciais roubadas.
Reduzindo o custo e o impacto das vulnerabilidades de segurança.
Integrar varreduras de segurança automatizadas (SAST, SCA, varredura de imagem) e verificações de políticas nas fases iniciais do pipeline de CI/CD.
Por quê: Encontra e corrige vulnerabilidades mais cedo no ciclo de vida de desenvolvimento, quando são mais baratas de remediar.
Protegendo dados sensíveis do cluster (especialmente Secrets) se o armazenamento etcd for comprometido.
No kube-apiserver, usar `--encryption-provider-config` para habilitar a criptografia em repouso para recursos antes que sejam armazenados no etcd.
Por quê: Por padrão, os Secrets do Kubernetes são apenas codificados em base64 no etcd. Isso fornece verdadeira criptografia em disco.
Prevenindo acesso não autorizado e interceptação na comunicação do etcd.
Configurar o etcd com mTLS para comunicação tanto do cliente (`--client-cert-auth`) quanto do peer (`--peer-client-cert-auth`).
Por quê: Garante que apenas componentes autenticados (apiserver, outros membros do etcd) possam se comunicar com o etcd e que o tráfego seja criptografado.
Prevenindo acesso não autenticado ao servidor da API do Kubernetes.
Definir a flag `--anonymous-auth=false`. Usar métodos de autenticação fortes como OIDC ou certificados x509.
Por quê: Desabilita o usuário `system:anonymous`, forçando todas as solicitações a serem autenticadas e registradas contra uma identidade específica.
Requisito para rastrear todas as alterações e tentativas de acesso para segurança e conformidade.
Habilitar o registro de auditoria do servidor API com `--audit-policy-file` e enviar logs para um sistema de log externo e imutável.
Por quê: Fornece um rastro essencial e à prova de adulteração para investigação de incidentes, caça a ameaças e auditorias de conformidade.
Reduzindo a superfície de ataque dos nós de trabalho.
Definir as flags do kubelet: `--anonymous-auth=false`, `--authorization-mode=Webhook` e `--read-only-port=0`.
Por quê: Isso garante que todas as solicitações para a API do kubelet sejam autenticadas e autorizadas pelo servidor da API e desabilita a porta somente leitura insegura e não autenticada.
Prevenindo vazamento de informações dos componentes do plano de controle.
Definir a flag `--profiling=false` no kube-apiserver, kube-controller-manager e kube-scheduler em produção.
Por quê: Endpoints de profiling podem expor dados de desempenho internos e detalhes do sistema que poderiam auxiliar um atacante em reconhecimento.
Protegendo componentes do plano de controle contra acesso não autorizado à rede.
Usar regras de firewall (grupos de segurança na nuvem, iptables) para restringir o acesso às portas do servidor API (6443) e etcd (2379) apenas a fontes confiáveis.
Por quê: O controle de acesso em nível de rede é uma camada fundamental de defesa, impedindo que atacantes sequer alcancem APIs de componentes sensíveis.
Concedendo permissões a usuários ou aplicações.
Usar `Roles` com escopo de namespace em vez de `ClusterRoles`. Conceder verbos específicos (`get`, `list`) em vez de curingas (`*`).
Por quê: Segue o princípio do menor privilégio, limitando o escopo das permissões apenas ao que é necessário dentro de um namespace específico.
Um pod não precisa se comunicar com a API do Kubernetes.
Definir `automountServiceAccountToken: false` na especificação do pod ou no próprio ServiceAccount.
Por quê: Evita expor credenciais desnecessárias dentro do pod, reduzindo a superfície de ataque se o pod for comprometido.
Impondo uma postura de segurança base para todos os pods em um namespace.
Usar o controlador de admissão `PodSecurity` embutido aplicando rótulos de namespace como `pod-security.kubernetes.io/enforce: baseline`.
Por quê: Fornece uma maneira padronizada e embutida de prevenir configurações de pod arriscadas (como contêineres privilegiados) sem ferramentas de terceiros.
Reforçando a segurança individual do contêiner para prevenir escalonamento de privilégios.
Na especificação do pod, definir os campos de `securityContext`: `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`.
Por quê: Esses controles impedem a execução como root, bloqueiam mecanismos para obter novos privilégios e tornam o sistema de arquivos do contêiner imutável, reduzindo drasticamente o impacto de um comprometimento.
Implementando um modelo de rede zero-trust dentro do cluster.
Aplicar uma NetworkPolicy de negação padrão a cada namespace que seleciona todos os pods (`podSelector: {}`) e possui uma lista de regras de entrada/saída vazia.
Por quê: A rede do Kubernetes é de permissão padrão. Esta política inverte o modelo para negação padrão, forçando os desenvolvedores a permitir explicitamente o tráfego necessário.
Permitindo tráfego apenas entre camadas de aplicação específicas (por exemplo, web-para-api).
Criar NetworkPolicies que usam `podSelector` e `namespaceSelector` para definir regras granulares de entrada e saída baseadas em rótulos.
Por quê: Previne o movimento lateral por atacantes, garantindo que um pod comprometido possa se comunicar apenas com peers explicitamente autorizados.
Um usuário precisa de permissão para `kubectl exec` em contêineres para depuração.
Conceder o verbo `create` no subrecurso `pods/exec` no Role ou ClusterRole relevante.
Por quê: A ação `exec` é controlada de forma não intuitiva pelo verbo `create` porque ela cria uma nova sessão exec. Este é um ponto comum de confusão.
Um atacante obtém acesso a um contêiner e tenta comprometer o nó host.
Proibir contêineres privilegiados (`securityContext.privileged: false`), namespaces do host (`hostNetwork`, `hostPID`) e a montagem do socket Docker.
Por quê: Essas configurações efetivamente quebram o isolamento do contêiner, dando a um contêiner comprometido acesso em nível de root ao host.
Prevenindo a implantação de imagens de contêiner com vulnerabilidades conhecidas ou código malicioso.
Implementar varredura de imagens (por exemplo, Trivy) e verificação de assinatura de imagens (por exemplo, Cosign) no pipeline de CI/CD e via controle de admissão.
Por quê: Fornece uma abordagem de defesa em profundidade: a varredura detecta vulnerabilidades conhecidas, enquanto a assinatura verifica a integridade e proveniência da imagem.
Um atacante comprometeu um pod e está tentando acessar outros pods no cluster.
Implementar NetworkPolicies de negação padrão e criar regras de permissão específicas apenas para a comunicação pod-a-pod necessária.
Por quê: Restringe a "linha de visão" de um atacante a partir de um pod comprometido, contendo a violação e impedindo que ela se espalhe.
Impedindo que um pod comprometido roube credenciais IAM da nuvem do serviço de metadados da instância.
Aplicar uma NetworkPolicy de saída de negação padrão que bloqueia explicitamente o tráfego para o IP de metadados (por exemplo, `169.254.169.254/32`).
Por quê: Este é um caminho de ataque comum em ambientes de nuvem. Bloquear este caminho de saída mitiga o risco de roubo de credenciais IAM de pods.
Protegendo contra ataques de negação de serviço ou cryptojacking que esgotam os recursos do nó.
Aplicar objetos `ResourceQuota` a namespaces para limitar o uso total de recursos e objetos `LimitRange` para impor limites em pods individuais.
Por quê: Garante que nenhum locatário ou workload possa privar outros de recursos, proporcionando estabilidade e prevenindo abusos.
Um atacante tenta manter acesso de longo prazo a um cluster comprometido.
Monitorar a criação de `DaemonSets`, `CronJobs` ou pods privilegiados inesperados. Restringir permissões para criar esses recursos.
Por quê: Atacantes usam esses tipos de workload para garantir que seu código malicioso seja executado persistentemente, mesmo que um nó ou pod seja reiniciado.
Garantindo que as imagens de contêiner estejam livres de vulnerabilidades conhecidas antes da implantação.
Integrar um scanner de imagens como Trivy, Clair ou Grype no pipeline de CI/CD para escanear imagens e falhar a compilação se vulnerabilidades críticas forem encontradas.
Por quê: Automatiza a detecção de vulnerabilidades precocemente ("shift left"), impedindo que código vulnerável chegue à produção.
Garantindo que apenas imagens de contêiner confiáveis e não modificadas sejam implantadas no cluster.
Assinar imagens com uma ferramenta como Cosign no pipeline de CI. Usar um controlador de admissão validador (por exemplo, Kyverno, Gatekeeper) para verificar a assinatura no momento da implantação.
Por quê: Fornece prova criptográfica da integridade da imagem (não foi adulterada) e proveniência (veio de uma fonte confiável).
Detectando atividade maliciosa dentro de um contêiner em execução (por exemplo, shell criado, acesso a arquivos sensíveis).
Implantar uma ferramenta de segurança em tempo de execução como Falco, que usa eBPF para monitorar chamadas de sistema e alertar sobre comportamento suspeito com base em um conjunto de regras definido.
Por quê: Fornece visibilidade da atividade em tempo de execução, que a varredura estática e o controle de admissão não conseguem ver. É crucial para detectar violações ativas.
Impondo políticas de segurança personalizadas e específicas da organização (por exemplo, "todas as imagens devem vir do nosso registro corporativo").
Usar um motor de políticas como OPA Gatekeeper ou Kyverno como controlador de admissão validador para impor políticas escritas em Rego ou YAML.
Por quê: Permite a aplicação flexível, declarativa e automatizada de políticas de segurança que vão além dos controles embutidos do Kubernetes.
Criptografando e autenticando todo o tráfego de serviço para serviço dentro do cluster.
Implementar uma service mesh (por exemplo, Istio, Linkerd) para fornecer automaticamente TLS mútuo (mTLS) para todos os serviços na mesh.
Por quê: Alcança uma rede zero-trust, garantindo que todo o tráfego dentro do cluster seja criptografado e que os serviços verifiquem mutuamente a identidade uns dos outros.
Executando workloads não confiáveis ou multi-tenant que exigem isolamento mais forte do que contêineres padrão.
Usar um runtime de contêiner em sandbox como gVisor ou Kata Containers, que fornecem uma camada adicional de isolamento entre o contêiner e o kernel do host.
Por quê: Reduz a superfície de ataque do kernel do host, tornando a fuga do contêiner significativamente mais difícil.
Controle granular sobre as permissões de um contêiner no nível do kernel.
Usar perfis Seccomp para filtrar chamadas de sistema permitidas e perfis AppArmor/SELinux para impor controles de acesso obrigatórios (MAC) no acesso a arquivos e redes.
Por quê: Esses recursos de segurança nativos do Linux fornecem uma camada profunda de defesa, restringindo o que um processo de contêiner comprometido pode fazer fundamentalmente.
Reduzindo a superfície de ataque dentro de uma imagem de contêiner.
Construir imagens de aplicação usando imagens base mínimas ou "distroless" que contenham apenas a aplicação e suas dependências diretas.
Por quê: Remove shells, gerenciadores de pacotes e outras utilidades que são desnecessárias para produção e poderiam ser usadas por um atacante após um comprometimento.
Verificando se um cluster Kubernetes está configurado de acordo com as melhores práticas de segurança.
Executar regularmente o `kube-bench`, uma ferramenta automatizada que verifica o cluster em relação ao CIS Kubernetes Benchmark.
Por quê: Fornece uma maneira padronizada, abrangente e automatizada de auditar a postura de segurança do cluster e identificar configurações incorretas.
Um cluster deve processar e armazenar dados de cartão de crédito em conformidade com o PCI DSS.
Usar NetworkPolicies para segmentação de rede para isolar o Ambiente de Dados do Titular do Cartão (CDE), e habilitar a criptografia em repouso para o etcd.
Por quê: Esses controles mapeiam diretamente para os requisitos do PCI DSS para segmentação de rede (Req 1) e proteção de dados de cartão de crédito armazenados (Req 3).
Um cluster lida com Informações de Saúde Protegidas (PHI) e deve estar em conformidade com o HIPAA.
Implementar RBAC estrito, habilitar log de auditoria abrangente e garantir que os dados sejam criptografados tanto em repouso quanto em trânsito.
Por quê: Esses controles abordam as Salvaguardas Técnicas do HIPAA para controle de acesso, controles de auditoria e segurança de transmissão.
Garantindo que os logs de auditoria sejam preservados para conformidade e forense, mesmo que o cluster seja comprometido.
Configurar o servidor da API para transmitir logs de auditoria para um backend de log externo, write-once/imutável (por exemplo, um SIEM ou um bucket de armazenamento em nuvem bloqueado).
Por quê: Impede que um atacante com privilégios de cluster-admin oculte seus rastros modificando ou excluindo logs de auditoria locais.