Admissão, capabilities e identidade efetiva

Três decisões antes do processo

Autenticação identifica quem apresenta um pedido à API. Autorização verifica se essa identidade pode executar a operação sobre o recurso no âmbito indicado. Admissão avalia o objeto depois dessas etapas e pode rejeitar uma configuração mesmo quando existe permissão para criar Pods. kubectl auth can-i ajuda a investigar autorização, mas não valida todas as políticas de admissão nem o funcionamento do processo.

Lê o texto da rejeição e os eventos do controlador: um Forbidden pode resultar de autorização ou de uma política, conforme a mensagem. Não atribuas cluster-admin só porque o pedido terminou com esse código.

Nível, modo e versão da política

Pod Security Admission usa níveis privileged, baseline e restricted. Os modos têm consequências diferentes: enforce rejeita Pods incompatíveis; warn permite o pedido com aviso; audit permite-o e acrescenta uma anotação ao evento de auditoria.

Um namespace pode combinar modos com níveis distintos. O rótulo de versão fixa as regras de um minor, em vez de seguir latest implicitamente. O modo enforce atua nos Pods resultantes, não no próprio objeto Deployment.

Assim, um Deployment aceite pode ter ReplicaSets com FailedCreate por violação da política. Warn e audit também analisam templates de workloads. Inspeciona o namespace, a versão e o PodSpec efetivamente produzido antes de concluir que a aplicação chegou a arrancar.

Capabilities ao nível do container

As capabilities Linux dividem poderes do processo em operações específicas. Configura capabilities no securityContext de cada container; não as substituas por uma Role Kubernetes. A política Restricted para Pods Linux exige drop: ["ALL"] e só permite adicionar NET_BIND_SERVICE.

Isso é um máximo permitido pela política, não uma razão para adicionar essa capability a todas as aplicações. Se a aplicação pode ouvir numa porta alta, usa essa alternativa e ajusta targetPort. Se o contrato exige uma porta privilegiada e o ambiente requer essa capability, adiciona apenas a necessária. runAsNonRoot, allowPrivilegeEscalation: false e seccomp tratam outros controlos; não demonstram, isoladamente, que todas as capabilities foram removidas.

Filesystem, identidade e seccomp são controlos distintos

readOnlyRootFilesystem protege o filesystem raiz da imagem; não torna automaticamente todos os volumes read-only. Uma aplicação que escreve ficheiros temporários pode precisar de um volume gravável apenas em /tmp. As permissões e a propriedade desse volume têm de permitir o acesso pelo UID/GID efetivo. runAsNonRoot exige uma execução sem root; não concede acesso a diretórios.

Um perfil seccomp RuntimeDefault usa a política do runtime, enquanto Localhost refere um perfil disponível no nó. Unconfined não é um perfil aceite por Restricted. Se a API aceita o Pod mas o processo falha numa chamada ou num ficheiro, examina logs, identidade e controlos efetivos; ampliar RBAC não muda as permissões Linux desse processo.

Identidade de quem publica e de quem executa

A identidade que cria o Deployment não é automaticamente a ServiceAccount usada pela aplicação. O PodSpec escolhe serviceAccountName e os tokens disponibilizados ao Pod pertencem a essa identidade. Um utilizador conseguir ler Secrets não prova que a aplicação o consiga fazer.

Compara o namespace, o nome da ServiceAccount, o recurso, o verbo e eventuais subresources. Se o processo não precisa da API, avalia desativar a montagem automática do token. Isso não impede que o kubelet materialize um Secret referenciado por um volume do Pod; consumir um volume e executar uma chamada à API são caminhos diferentes. Protege os valores sensíveis nos logs e exemplos de diagnóstico.

Aceitar a correção na fase certa

O excerto mostra um contexto para um container Linux sem necessidade de capabilities adicionais. Não é um Pod completo nem garante conformidade com todos os controlos Restricted. Aplica o raciocínio a cada container, incluindo init e sidecars.

Depois de corrigir uma rejeição, confirma a criação dos Pods, o arranque, a prontidão e a função que motivou a mudança. Se o problema era uma escrita em /tmp, verifica essa escrita com o UID pretendido sem tornar toda a imagem gravável. Se era um pedido à API, verifica apenas a operação necessária pela ServiceAccount correta.

A correção deve conservar os outros limites e produzir evidência específica da função recuperada.

Armadilhas comuns

Confundir ServiceAccount com UID Linux; tratar warn como bloqueio; verificar apenas o container principal; desativar controlos sem identificar a fase da falha.