Kubernetes Security Best Practices | Decripte Security

Kubernetes revolucionou a orquestração e gerenciamento de containers em escala, tornando-se o padrão de facto para implantação de aplicações cloud-native, mas sua arquitetura distribuída e complexidade inerente introduzem uma superfície de ataque significativamente expandida em comparação com modelos tradicionais de deployment. Um cluster Kubernetes típico envolve dezenas de componentes interconectados - API server, etcd, scheduler, controller manager, kubelet, kube-proxy - cada um com suas próprias vulnerabilidades potenciais e requisitos de hardening específicos. A natureza dinâmica do K8s, onde pods são criados e destruídos constantemente, workloads migram entre nodes, e políticas de rede precisam ser aplicadas em tempo real, torna a segurança um desafio multidimensional que requer abordagem de defesa em profundidade. Configurações inseguras padrão, como permissões excessivamente permissivas em RBAC, ausência de network policies que permitem comunicação irrestrita entre pods, containers rodando como root com capacidades privilegiadas, e secrets armazenados em plain text no etcd não criptografado, representam vetores de ataque comumente explorados em ambientes K8s mal configurados. Este artigo explora práticas fundamentais de hardening de clusters Kubernetes, abrangendo controle de acesso baseado em funções (RBAC), pod security standards, network policies para micro-segmentação, gerenciamento seguro de secrets, admission controllers para policy enforcement, runtime security monitoring com ferramentas como Falco, e compliance com benchmarks da indústria como CIS Kubernetes Benchmark, fornecendo um roadmap completo para construir e operar clusters Kubernetes seguros em ambientes de produção.

Arquitetura de Segurança K8s

Cluster Kubernetes possui múltiplos componentes críticos:

• Control Plane: API Server, etcd, scheduler, controller manager
• Nodes: kubelet, kube-proxy, container runtime
• Add-ons: DNS, dashboard, ingress controllers

RBAC (Role-Based Access Control)

RBAC é fundação da segurança K8s, controlando quem pode acessar o quê via API server.

Configuração RBAC

      # Role para ler pods em namespace específico
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: production
      name: pod-reader
      rules:
      - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "list"]
      ---
      # RoleBinding associa role a usuário
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
      name: read-pods
      namespace: production
      subjects:
      - kind: User
      name: jane
      apiGroup: rbac.authorization.k8s.io
      roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io
      

Princípios RBAC

• Least privilege: Conceder apenas permissões necessárias
• Evitar ClusterAdmin: Criar roles específicas por função
• Service accounts: Cada pod deve ter SA dedicada
• Namespace isolation: RoleBindings ao invés de ClusterRoleBindings

Pod Security

Pod Security Standards

Kubernetes 1.25+ usa Pod Security Admission ao invés de deprecated PSPs:

• Privileged: Unrestricted, para workloads confiáveis
• Baseline: Minimamente restritivo, previne escalações conhecidas
• Restricted: Heavily restricted, segue hardening best practices

Security Context

      apiVersion: v1
      kind: Pod
      metadata:
      name: secure-pod
      spec:
      securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      fsGroup: 2000
      seccompProfile:
      type: RuntimeDefault
      containers:
      - name: app
      image: myapp:latest
      securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
      drop:
      - ALL
      

Network Policies

Por padrão, pods podem comunicar livremente. Network Policies implementam segmentação:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: api-allow-from-frontend
      namespace: production
      spec:
      podSelector:
      matchLabels:
      app: api
      policyTypes:
      - Ingress
      ingress:
      - from:
      - podSelector:
      matchLabels:
      app: frontend
      ports:
      - protocol: TCP
      port: 8080
      

Secrets Management

• Nunca hardcode secrets: Usar Kubernetes Secrets ou external vaults
• etcd encryption: Habilitar encryption-at-rest para etcd
• External Secrets Operator: Integrar com Vault, AWS Secrets Manager
• Rotate secrets: Implementar rotação automática
• RBAC para secrets: Restringir quem pode ler secrets

Image Security

• Private registries: Não usar public registries em produção
• Image scanning: Trivy, Clair, Anchore para scan de vulnerabilidades
• Image signing: Cosign para verificar integridade
• Admission controllers: Validar images antes de deploy
• Distroless images: Minimizar attack surface

Admission Controllers

API Server Hardening

• Habilitar audit logging
• Usar TLS para todas comunicações
• Desabilitar anonymous auth
• Implementar API rate limiting
• Restringir acesso ao API server (network ACLs)

Runtime Security

• Falco: Runtime threat detection para K8s
• Sysdig Secure: Runtime protection e compliance
• Aqua Security: Full lifecycle container security

Compliance e Auditing

• CIS Kubernetes Benchmark: Framework de hardening
• kube-bench: Automated CIS compliance checks
• kube-hunter: Penetration testing tool para K8s
• Audit logs: Centralizar em SIEM para análise

Service Mesh Security

Service meshes (Istio, Linkerd) adicionam camada de segurança:

• mTLS automático entre pods
• Fine-grained authorization policies
• Traffic encryption in transit
• Observability e auditability