Seguranca em Kubernetes e Containers: Guia Completo de Hardening

Modelo de Ameacas em Kubernetes

Kubernetes revolucionou como deployamos aplicacoes, mas tambem introduziu nova superfície de ataque. Antes de implementar controles, e essencial entender o modelo de ameacas especifico de ambientes containerizados.

Camadas de seguranca (Defense in Depth)

Seguranca em Kubernetes deve ser implementada em multiplas camadas:

1. Build time: Imagens seguras, scanning, assinaturas
2. Deploy time: Admission control, policies
3. Runtime: Monitoramento, deteccao de anomalias
4. Infrastructure: Host hardening, network segregation

Seguranca de Imagens de Container

A seguranca comeca bem antes do deploy - na construcao da imagem.

Melhores práticas de Dockerfile

# Use base image minima e especifica (nao :latest)
FROM cgr.dev/chainguard/python:latest-dev AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Multi-stage build - imagem final minima
FROM cgr.dev/chainguard/python:latest
WORKDIR /app
COPY --from=builder /app .
COPY . .

# Usuario nao-root
USER nonroot:nonroot

# Nao precisa de shell para maioria das apps
ENTRYPOINT ["python", "app.py"]

Checklist de imagem segura

• [ ] Base image minima (distroless, alpine, chainguard)
• [ ] Tag especifica (nunca :latest em producao)
• [ ] Multi-stage build para reduzir tamanho
• [ ] Usuario nao-root (USER nonroot)
• [ ] Sem shell se possivel
• [ ] Sem ferramentas de debug em producao
• [ ] COPY especifico (nao COPY . .)
• [ ] Dependencias pinadas com hashes

Image scanning no CI/CD

Integre scanning automatico no pipeline para bloquear imagens vulneraveis:

# Exemplo: GitHub Actions com Trivy
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: '${{ env.IMAGE }}'
    format: 'sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'  # Falha o build se encontrar critical/high

Assinatura e verificacao de imagens

Use Sigstore/Cosign para assinar e verificar imagens:

# Assinar imagem
cosign sign --key cosign.key myregistry.io/myapp:v1.2.3

# Verificar antes de deploy (admission controller)
cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3

Hardening do Cluster Kubernetes

API Server

• Autenticacao: Desabilite autenticacao anonima (--anonymous-auth=false)
• Autorizacao: Use RBAC, nunca AlwaysAllow
• Audit logging: Habilite para rastrear todas as chamadas
• TLS: Certificados validos para todas as comunicacoes
• Acesso: Nao exponha API server publicamente

etcd

• Encryption at rest: Criptografe secrets no etcd
• TLS: Comunicacao criptografada com API server
• Acesso: Isole etcd da rede de pods
• Backup: Backups criptografados regulares

# EncryptionConfiguration para secrets
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-key>
      - identity: {}

Kubelet

• Autenticacao: Webhook ou certificados (nunca anonimo)
• Read-only port: Desabilite (--read-only-port=0)
• Protect kernel defaults: --protect-kernel-defaults=true

RBAC e Controle de Acesso

RBAC (Role-Based Access Control) e fundamental para seguranca em K8s. O principio: minimo privilegio.

Estrutura do RBAC

• Role/ClusterRole: Define permissoes (verbs em resources)
• RoleBinding/ClusterRoleBinding: Liga roles a usuarios/serviceaccounts
• ServiceAccount: Identidade para pods

# Role restritivo para aplicacao
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: myapp
  name: myapp-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["myapp-config"]  # Apenas configmap especifico
  verbs: ["get"]
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["myapp-secret"]
  verbs: ["get"]
---
# ServiceAccount dedicada
apiVersion: v1
kind: ServiceAccount
metadata:
  name: myapp-sa
  namespace: myapp
automountServiceAccountToken: false  # Desabilitar se nao precisar

Audit de RBAC

Use ferramentas para identificar permissoes excessivas:

# kubectl-who-can: quem pode fazer o que
kubectl who-can create pods --all-namespaces
kubectl who-can get secrets -n production

# rbac-tool: visualizar e auditar
rbac-tool lookup --kind ServiceAccount
rbac-tool viz --outformat dot | dot -Tpng > rbac.png

Network Policies

Por padrao, todos os pods podem comunicar com todos. Network Policies implementam segmentacao:

# Default deny all - ponto de partida
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Permitir apenas trafego necessario
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Estratégia de implementação

1. Comece em modo observacao (log, nao block)
2. Mapeie fluxos de comunicacao reais
3. Implemente default-deny por namespace
4. Adicione allowlists especificas
5. Monitore e ajuste continuamente

Runtime Security

Pod Security Standards (PSS)

Pod Security Standards substituiu PodSecurityPolicy (removido no K8s 1.25). Tres niveis:

• Privileged: Sem restricoes (apenas para system pods)
• Baseline: Previne escalacao conhecida (minimo para producao)
• Restricted: Hardening maximo (recomendado)

# Aplicar PSS no namespace
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

SecurityContext no Pod

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myapp:v1
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
      resources:
        limits:
          memory: "256Mi"
          cpu: "500m"
        requests:
          memory: "128Mi"
          cpu: "100m"

Runtime detection com Falco

Falco detecta comportamentos anomalos em runtime usando regras baseadas em syscalls:

• Shell spawned in container
• File written to sensitive directory
• Unexpected network connection
• Container drift (arquivo criado que nao estava na imagem)
• Privilege escalation attempt

Gestao de Secrets

Kubernetes Secrets sao base64 encoded, não criptografados por padrão. Melhores práticas:

Encryption at rest

Habilite criptografia de secrets no etcd (EncryptionConfiguration mostrado anteriormente).

External secret stores

Use secret managers externos com operadores:

# External Secrets Operator - sincroniza do AWS Secrets Manager
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-secret
  data:
    - secretKey: password
      remoteRef:
        key: production/database
        property: password

Melhores práticas de secrets

• Monte como volume, nao env var (evita logging acidental)
• RBAC restritivo para acesso a secrets
• Rotacao automatica com external stores
• Audit logging de acesso a secrets
• Nunca commite secrets em git (use sealed-secrets se necessario)

Ferramentas Essenciais de Seguranca K8s

Perguntas Frequentes

Conclusao

Seguranca em Kubernetes requer abordagem em camadas - nao existe bala de prata. Da construcao de imagens ao runtime, cada etapa oferece oportunidades de hardening e pontos de falha potenciais.

Comece pelo basico: imagens minimas, RBAC restritivo, Network Policies com default-deny, Pod Security Standards restricted. Estas medidas eliminam a maioria dos vetores de ataque comuns. Depois, adicione camadas como runtime security (Falco), policy enforcement (OPA), e secret management externo (Vault).

Automatize verificacoes de seguranca no pipeline CI/CD - scanning de imagens, compliance checks, assinatura. Seguranca que depende de processo manual nao escala e falha silenciosamente.

Por fim, trate seguranca K8s como processo continuo. O ecossistema evolui rapidamente, novas vulnerabilidades surgem, best practices mudam. Atualize clusters regularmente, acompanhe CVEs de componentes, e revise configuracoes periodicamente.

Inteligencia Brasil

Consultoria especializada em DevSecOps, Cloud Security e Seguranca de Containers.