Segurança em Kubernetes: Práticas para Proteger seus Containers

O Kubernetes tornou-se o orquestrador de contêineres padrão de mercado para empresas que rodam sistemas distribuídos complexos. No entanto, por ser um ecossistema robusto e flexível, sua configuração padrão prioriza a facilidade de desenvolvimento em detrimento da segurança restritiva.

Sem o devido hardening, invasores podem escalar privilégios de um único contêiner para comprometer todo o cluster. Abaixo, destacamos práticas essenciais para proteger seu Kubernetes.

1. Implemente o Princípio de Menor Privilégio com RBAC

O controle de acesso baseado em funções (RBAC - Role-Based Access Control) permite restringir quais ações usuários e pods podem realizar nas APIs do Kubernetes.

Recomendações:

• Nunca use a conta padrão system:serviceaccount:default com privilégios de administrador.
• Crie ServiceAccounts dedicadas para cada aplicação e associe apenas as permissões necessárias (ex: somente leitura no namespace correspondente).

2. Restrinja o Acesso a Recursos dos Pods (Security Context)

Por padrão, contêineres Docker podem rodar como usuário root. Se um contêiner root for invocado com vulnerabilidades, o atacante ganha acesso completo ao nó físico hospedeiro.

O que configurar nos manifestos (YAML):

Configure o bloco securityContext do seu Pod para impedir execução privilegiada:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: minha-app
    image: minha-app:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

Nota: O uso de readOnlyRootFilesystem bloqueia qualquer gravação no disco local do contêiner, forçando o uso de diretórios temporários (tmpfs) ou volumes persistentes montados explicitamente para escrita, impedindo a injeção de scripts maliciosos.

3. Aplique Network Policies (Isolamento de Rede)

Por padrão, a rede interna do Kubernetes é aberta: qualquer Pod de qualquer Namespace pode conversar livremente com outros Pods do cluster.

Como proteger:

• Habilite políticas de rede (NetworkPolicies) para atuar como um firewall interno de camada 3/4.
• Isole bancos de dados e sistemas de fila, configurando-os para aceitar conexões apenas de pods marcados com a label específica do microsserviço autorizado.

4. RBAC e NetworkPolicy no namespace

A conta do pod não herda permissão de cluster. Este papel só lê pods no namespace loja:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: loja-api
  namespace: loja
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ler-pods
  namespace: loja
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: loja-api-ler-pods
  namespace: loja
subjects:
  - kind: ServiceAccount
    name: loja-api
    namespace: loja
roleRef:
  kind: Role
  name: ler-pods
  apiGroup: rbac.authorization.k8s.io

A rede fecha o banco. Só o pod com app=loja-api fala na porta 5432:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: postgres-so-api
  namespace: loja
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: loja-api
      ports:
        - protocol: TCP
          port: 5432

kubectl apply -f rbac-loja.yaml
kubectl apply -f netpol-postgres.yaml
kubectl auth can-i list pods --as=system:serviceaccount:loja:loja-api -n loja
kubectl auth can-i delete pods --as=system:serviceaccount:loja:loja-api -n loja

A primeira resposta é yes. A segunda é no. A NetworkPolicy só filtra tráfego se o CNI do cluster implementa a API. Sem isso, o YAML aplica e a rede continua aberta.

Conclusão

Garantir a segurança de clusters Kubernetes exige uma abordagem em camadas. Ao aplicar o isolamento de rede, políticas RBAC rígidas e contextos de segurança nos Pods, sua organização elimina os principais pontos cegos de infraestruturas conteinerizadas em produção.