O ACK permite reforçar a segurança de pods com controles que reduzem o risco de escapes de contêineres e escalonamento de privilégios. Esses controles incluem restrições ao modo privilegiado, execução como root, volumes hostPath e montagem de tokens de ServiceAccount.
Por que os escapes de contêineres são críticos
Escapes de contêineres permitem que invasores elevem privilégios de um contêiner para controlar o host. Dois comportamentos padrão do Kubernetes criam esse risco.
Contexto root padrão. Os processos do contêiner executam como root por padrão. O docker restringe o root com Linux capabilities, mas o conjunto padrão é amplo:
cap_chown, cap_dac_override, cap_fowner, cap_fsetid, cap_kill, cap_setgid, cap_setuid, cap_setpcap, cap_net_bind_service, cap_net_raw, cap_sys_chroot, cap_mknod, cap_audit_write, cap_setfcap
Um invasor que comprometa uma aplicação em contêiner pode usar essas capacidades para ler Secrets, ConfigMaps e outros dados sensíveis no host. Evite o modo privilegiado, pois ele concede todas as Linux capabilities do usuário root do host.
Acesso à API em todo o nó via kubelet. Os nós de trabalho do Kubernetes usam o autorizador de nó para gerenciar requisições da API do kubelet. Ele concede a cada kubelet acesso de leitura a Services, Endpoints, Nodes, Pods, Secrets, ConfigMaps, persistent volumes (PVs) e persistent volume claims (PVCs) para pods nesse nó, além de acesso de gravação ao status do nó, status do pod e Events. Também concede acesso de leitura/gravação à API CertificateSigningRequest (CSR) para bootstrap TLS, e a capacidade de criar TokenReview e SubjectAccessReview para autenticação e autorização delegadas.
Por padrão, clusters ACK ativam o controlador de admissão NodeRestriction, que limita cada kubelet a modificar apenas seu próprio nó e pods vinculados. No entanto, o NodeRestriction sozinho não impede que um invasor consulte a API do Kubernetes para descobrir informações do cluster.
Mecanismo de imposição
O ACK oferece suporte a políticas de segurança de pods baseadas no Open Policy Agent (OPA) e Gatekeeper. Elas validam requisições de criação e atualização de pods conforme suas regras e rejeitam requisições não conformes. Cada recomendação abaixo possui uma política ACK predefinida para imposição no nível de namespace.
Recomendações de segurança de pods
Aplique estes nove controles em conjunto para obter defesa em profundidade contra vetores de ataque comuns.
1. Proíba contêineres privilegiados
Contêineres privilegiados herdam todas as Linux capabilities do usuário root do host. A maioria das cargas de trabalho não precisa delas. Proíba o modo privilegiado para impedir que invasores acessem diretamente os recursos do host.
Campos restritos:
|
Campo |
Valores permitidos |
|
|
Indefinido, |
|
|
Indefinido, |
Implante a política ACKPSPPrivilegedContainer para impor essa restrição nos namespaces especificados.
2. Execute pods como um usuário não root
Os contêineres executam como root por padrão. Um invasor com acesso shell a um contêiner root tem um caminho muito mais fácil para o host. Execute contêineres como um usuário não root para limitar o impacto de um comprometimento.
Adote uma destas abordagens:
Remova o shell da imagem do contêiner.
Adicione uma instrução
USERao Dockerfile.Defina
spec.securityContext.runAsUsererunAsGroupno podSpec.
Implante a política ACKPSPAllowedUsers para restringir quais usuários e grupos podem executar contêineres nos namespaces especificados.
3. Proíba docker-in-docker e montagem de docker.sock
Criar ou executar imagens dentro de um contêiner usando docker-in-docker ou montando docker.sock concede ao processo do contêiner controle sobre o nó.
Prefira abordagens alternativas para criação de imagens:
Use uma instância do Container Registry Enterprise Edition para criar uma imagem
kaniko — cria imagens dentro do Kubernetes sem acesso ao daemon do docker
img — criação de imagens sem root e sem docker.sock
4. Restrinja volumes hostPath
Um volume hostPath monta um diretório do host em um pod. Um contêiner root com acesso de gravação pode modificar configurações do kubelet, criar links simbólicos para arquivos fora do caminho montado (como /etc/shadow), instalar chaves SSH, ler Secrets do host ou executar outras operações maliciosas. Defina as montagens hostPath como somente leitura para limitar os danos.
volumeMounts:
- name: hostPath-volume
readOnly: true
mountPath: /host-pathImplante a política ACKPSPHostFilesystem para restringir quais diretórios do host podem ser montados nos namespaces especificados.
5. Defina solicitações e limites de recursos
Um pod sem solicitações ou limites de recursos pode esgotar a CPU e a memória do nó, travar o kubelet ou evictar outros pods. Defina solicitações e limites para reduzir a contenção de recursos.
Especifique solicitações e limites de CPU e memória no podSpec. Aplique uma cota de recursos ao namespace para exigir que todos os contêineres declarem solicitações e limites. Use um LimitRange para definir padrões e limites por contêiner.
Implante a política ACKContainerLimits para impor limites de recursos nos namespaces especificados.
6. Proíba o escalonamento de privilégios
O escalonamento de privilégios permite que um processo obtenha permissões elevadas em tempo de execução — por exemplo, ao executar um binário SUID ou SGID como sudo. Desative esse recurso para impedir que processos não root recuperem acesso no nível de root.
Campo restrito:
|
Campo |
Valores permitidos |
|
|
|
securityContext:
allowPrivilegeEscalation: falseImplante a política ACKPSPAllowPrivilegeEscalationContainer para impor essa configuração nos namespaces especificados.
7. Desative a montagem automática de tokens de ServiceAccount
Para pods que não precisam de acesso à API do Kubernetes, desative a montagem automática de tokens de ServiceAccount para evitar a exposição do token caso o pod seja comprometido.
Desative a montagem de tokens para um pod específico:
apiVersion: v1
kind: Pod
metadata:
name: pod-no-automount
spec:
automountServiceAccountToken: falseDesative a montagem de tokens para todos os pods que usam uma ServiceAccount específica:
apiVersion: v1
kind: ServiceAccount
metadata:
name: sa-no-automount
automountServiceAccountToken: falseDesativar a montagem de tokens não impede que o pod alcance a API do Kubernetes — um pod ainda pode estabelecer conexões de rede com o servidor de API. Para bloquear totalmente o acesso à API, restrinja a exposição do endpoint do servidor de API do cluster ACK e configure políticas de rede.
Implante a política ACKBlockAutomountToken para impor automountServiceAccountToken: false nos pods de aplicação dos namespaces especificados.
8. Desative a descoberta de serviços
Para pods que não precisam de outros serviços do cluster, desative os links de serviço e altere a política de DNS para limitar o que um invasor pode enumerar se o pod for comprometido.
apiVersion: v1
kind: Pod
metadata:
name: pod-no-service-info
spec:
dnsPolicy: Default # The value Default does not indicate the default setting of a DNS policy.
enableServiceLinks: falsePor padrão, a política de DNS de um pod é ClusterFirst, que roteia consultas pelo serviço CoreDNS interno do cluster. Definir dnsPolicy: Default roteia o DNS pelo resolvedor do nó. Definir enableServiceLinks: false impede que Services no namespace sejam injetados como variáveis de ambiente.
Essas configurações não bloqueiam o acesso direto ao CoreDNS. Um invasor ainda pode enumerar serviços do cluster executando dig SRV *.*.svc.cluster.local @$CLUSTER_DNS_IP. Use políticas de rede para restringir totalmente a descoberta de serviços.
9. Use um sistema de arquivos raiz somente leitura
Um sistema de arquivos raiz somente leitura impede que invasores sobrescrevam binários de aplicação ou arquivos de configuração. Se a aplicação precisar gravar em disco, use um volume tmpfs ou um volume persistente montado.
Campo restrito:
|
Campo |
Valores permitidos |
|
|
|
securityContext:
readOnlyRootFilesystem: trueImplante a política ACKPSPReadOnlyRootFilesystem para impor um sistema de arquivos raiz somente leitura para pods nos namespaces especificados.
Próximos passos
Revise todas as políticas de segurança ACK predefinidas.
Use políticas de rede para restringir o tráfego entre pods e entre pods e o servidor de API.