CKS (Especialista em Segurança Kubernetes): pré-requisitos e um plano de estudo de 6 semanas

CKS — Certified Kubernetes Security Specialist — é o mais difícil dos três exames de nível profissional de Kubernetes, na minha opinião, mais restrito que o CKA e mais exigente sob pressão de tempo. Duas horas, prático, $445, com uma nova tentativa gratuita incluída. PSI Bridge, somente online, sem centros de teste. A nota de aprovação é de 67%. A CNCF não publica as taxas de aprovação oficiais, mas a taxa de primeira tentativa pesquisada pela comunidade gira em torno de 40–50%, menor que a do CKA, e isso coincide com a minha experiência observando colegas fazerem o exame.

O que a maioria das pessoas não percebe: você não pode simplesmente se inscrever. A CNCF exige um CKA ativo em sua conta no momento da inscrição. Não "você fez o CKA em algum momento." Ativo. Se o seu CKA expirou (o que agora acontece após 2 anos em vez de 3 desde a mudança de política de 1º de abril de 2024), você precisa renová-lo antes de poder se registrar para o CKS. Esta é uma barreira rígida, não uma recomendação suave, e surpreende as pessoas a cada trimestre.

Os pré-requisitos reais

Os oficiais: um CKA ativo. Só isso.

Os não oficiais:

• Familiaridade com kubectl a ponto de você não pensar na sintaxe. Se você ainda está pesquisando "kubectl create deployment" no Google, você não está pronto.
• Fundamentos de Linux — você estará acessando nós via SSH, lendo logs do systemd, editando flags do kubelet e depurando falhas de perfil seccomp / AppArmor. Se journalctl -u kubelet for desconhecido, resolva isso primeiro.
• Proficiência em vim. Não maestria em Vim. Mas editar YAML no vim em um limite de 2 horas sem perder 30 segundos em "espera, como salvo de novo" é obrigatório.
• Um modelo mental funcional de NetworkPolicy. Este é o maior obstáculo no exame. Mais sobre isso abaixo.
• Algum contato prévio com Falco, Trivy, AppArmor, seccomp, mTLS via service mesh e Pod Security Standards. Você não precisa ser um especialista em nenhum deles; você precisa reconhecê-los.

Se você está perdendo mais de dois desses pontos, dedique mais um mês a exercícios operacionais no estilo CKA antes de enfrentar o CKS. Tentar aprender operações e segurança do Kubernetes simultaneamente sob pressão de tempo é um caminho para desperdiçar a nova tentativa gratuita.

O que é realmente testado

O currículo da CNCF o divide da seguinte forma (as porcentagens mudam a cada revisão do currículo; atualizado no início de 2026):

• Configuração e hardening de cluster (~15%): CIS benchmarks, kube-bench, restrição de acesso externo, desativação de autenticação anônima, flags de hardening do kubelet.
• Hardening de sistema (~15%): hardening de kernel (seccomp, AppArmor), redução da superfície de ataque, minimização de IAM no lado da nuvem.
• Minimizar vulnerabilidades de microsserviços (~20%): Pod Security Standards (que substituíram PSPs no 1.25), tokens de ServiceAccount, OPA / Gatekeeper ou Kyverno, mTLS.
• Segurança da cadeia de suprimentos (~20%): escaneamento de imagens com Trivy, assinatura com cosign, admission controllers que bloqueiam imagens não assinadas, conceitos básicos de SBOM, minimização de imagens base.
• Monitoramento, logging, segurança de runtime (~20%): regras Falco, análise comportamental, imutabilidade, log de auditoria no nível do servidor API.
• Network policy (~10%): default-deny, isolamento de namespace, regras de egress. Listado como uma pequena porcentagem, mas na prática todas as outras categorias também tocam em NetworkPolicy.

O exame não testa como o Falco funciona internamente. Ele testa se você pode escrever uma regra Falco que dispara quando um shell é iniciado em um contêiner. O exame não testa a criptografia cosign. Ele testa se você pode configurar um admission controller para rejeitar imagens não assinadas. O trabalho é operacional, não acadêmico.

O plano de 6 semanas

Isso assume ~10 horas por semana com um CKA ativo já em mãos. Ajuste se você tiver mais ou menos tempo.

Semana 1: NetworkPolicy até você sangrar.

Configure um cluster kind localmente com Calico ou Cilium (o kindnet padrão não impõe NetworkPolicy, o que confunde as pessoas). Escreva uma política de default-deny para um namespace. Escreva uma política de allow-from-namespace. Escreva uma política de egress que permita apenas DNS. Escreva uma que permita tráfego de um rótulo de pod específico entre namespaces. Refaça tudo isso de memória até poder escrevê-los no vim sem consultar o kubernetes.io. O YAML de NetworkPolicy é a área de conteúdo de maior volume no exame e aquela em que a maioria das pessoas tropeça. Gaste mais tempo aqui do que você acha necessário.

Semana 2: Pod Security Standards, ServiceAccounts, aperto de RBAC.

Aplique perfis restritos, baseline e privilegiados a namespaces. Configure ServiceAccounts com automountServiceAccountToken: false. Construa RBAC que siga o princípio do menor privilégio para um deployment que precisa ler ConfigMaps em seu próprio namespace e nada mais. Pratique o diagnóstico de "este pod não pode fazer X por causa do RBAC" até que o fluxo kubectl auth can-i seja automático.

Semana 3: Cadeia de suprimentos — Trivy, cosign, admission control.

Escaneie uma imagem com Trivy e interprete a saída de CVEs. Assine uma imagem com cosign. Configure um ImagePolicyWebhook ou uma política Kyverno que rejeite imagens não assinadas pela sua chave. Configure um registro OCI localmente se quiser praticar a fundo. O exame provavelmente lhe dará o Trivy instalado; você deve saber suas flags principais de memória (--severity HIGH,CRITICAL, --ignore-unfixed).

Semana 4: Runtime — Falco, AppArmor, seccomp.

Instale o Falco em um cluster kind. Leia as regras padrão. Escreva uma regra personalizada. Aplique um perfil AppArmor a um pod (o exame geralmente fornece um perfil já no nó e pede para você configurá-lo via anotação — o que significa conhecer a sintaxe container.apparmor.security.beta.kubernetes.io/<container>: localhost/<profile>). Aplique um perfil seccomp via securityContext.seccompProfile. Ambos têm sintaxe legada baseada em anotações e sintaxe atual baseada em campos; o exame tende a testar a sintaxe atual, mas você deve reconhecer ambas.

Semana 5: Hardening de cluster e host.

Execute o kube-bench, interprete as falhas, corrija as fáceis (autenticação anônima, log de auditoria, flags do kubelet). Configure a política de auditoria no servidor API. Restrinja o acesso ao etcd. Desative portas desnecessárias do kubelet. Este é principalmente um trabalho de Linux em nível de nó e é onde engenheiros sem forte experiência em sysadmin tendem a desacelerar.

Semana 6: Killer Shell, simulações completas e descanso.

Use ambas as sessões Killer Shell incluídas nesta semana. Elas são intencionalmente mais difíceis do que o exame real; espere pontuar pior do que você esperaria. Use as lacunas para estudar. Faça o exame real nos últimos 2-3 dias da semana 6, enquanto a memória muscular estiver fresca. Não adie mais — a cada semana que você atrasa, você perde o reflexo.

Durma na noite anterior. Não vire a noite estudando. Não mude seus aliases do kubectl no dia do exame.

Os obstáculos que pegam as pessoas

NetworkPolicy sob pressão de tempo. Já mencionado e vale a pena repetir. A estrutura YAML é implacável — indentação errada mata a política silenciosamente e o pod ainda roteia. Pratique no vim até poder escrever um default-deny + selective allow de memória muscular.

Esquecer que o NetworkPolicy precisa de um CNI que o imponha. kindnet não impõe. flannel (padrão em algumas configurações) não impõe. Calico, Cilium, Weave impõem. Certifique-se de que seu cluster de prática esteja executando um CNI que imponha as regras ou você aprenderá as lições erradas.

Confundir PSP e Pod Security Standards. PSPs foram removidos no 1.25 (há anos, mas material de treinamento antigo ainda os referencia). O mecanismo atual é o Pod Security Admission com os perfis restrito, baseline e privilegiado aplicados via rótulos de namespace. Não estude PSPs.

Configuração de etcd encryption-at-rest. Testado frequentemente. Especificamente: editar EncryptionConfiguration, reiniciar o servidor API com a flag correta e verificar com etcdctl get se o valor está criptografado. Pratique isso.

A armadilha da aba do navegador. Você tem permissão para kubernetes.io, falco.org, app-armor.net e alguns outros. Você não pode depender de pesquisá-los sob pressão de tempo. Memorize a estrutura. Use a aba para copiar e colar trechos específicos, não para aprender a sintaxe.

Você deveria fazer este exame?

Faça o CKS se seu trabalho é ou será segurança de plataforma, engenharia de segurança em uma empresa Kubernetes ou trabalho de conformidade em setores regulados. Ignore-o se você é um engenheiro de plataforma generalista — o CKA cobre o que a maioria dos cargos generalistas precisa, e o CKS é um exagero que expira em 2 anos.

Se você for em frente, navegue pelo banco de questões CKS no CertLabPro ou inicie um exame cronometrado. A cobertura conceitual nos bancos de questões complementa as repetições operacionais que você precisa fazer em clusters reais. Ambos são necessários; nenhum sozinho é suficiente.