Como hackear o Kubernetes para encontrar senhas armazenadas em recursos Secret

• O objetivo deste conteúdo é reforçar a importância da segurança no Kubernetes
• Locais onde os Secrets são armazenados
  • Quando o usuário declara um recurso com o comando kubectl, o Kubernetes cria o arquivo de manifesto que define esse recurso e o armazena no etcd
  • Quando o usuário declara um recurso Secret, esse Secret também é armazenado no etcd
  • Quando o usuário cria um pod que lê o Secret como volume ou variável de ambiente, o Secret fica armazenado nesse pod
  • Se o etcd onde o Secret é armazenado e o pod que usa esse Secret forem hackeados, é possível descobrir a senha armazenada no Secret
• Preparação prévia
  • Criar o cluster com kubeadm
  • Para o laboratório, criar previamente três recursos: Secret credit-card, pod app1 e pod app2
• Hackeando o etcd
  • etcd: armazenamento de dados chave-valor que guarda o estado do cluster Kubernetes. Todas as informações declaradas no Kubernetes são armazenadas aqui. Também é possível ver os Secrets consultando o etcd
  • 1.1 Encontrando a senha com etcdctl
    • Consultar o manifesto do kube-apiserver para obter a certificate authority, a chave pública e a chave privada do servidor etcd
    • Encontrar a senha com o comando etcdctl, usado para manipular o etcd com mais facilidade
  • 1.2 Obter diretamente acessando o banco de dados do etcd
    • Encontrar o processo em que o etcd está rodando e vasculhar todos os dados desse processo para encontrar a senha
      • ps aux | grep etcd - obter o PID do etcd
      • ll /proc/<pid>/fd - aparece um arquivo de link com o nome db
      • cat /proc/<pid>fd/<db> | grep -A10 -B10 credit-card - encontrar a senha criada previamente com esse comando
• Hackeando o pod
  • Obter com kubectl exec
    • Se houver permissões adequadas para consultar o Kubernetes, é possível obter a senha com o comando kubectl
  • Obter acessando diretamente o contêiner
    • Se for possível usar livremente comandos Docker no worker node, dá para extrair a senha
    • No worker node em que o pod app1 foi agendado, é possível localizar o contêiner e extrair a lista de variáveis de ambiente registradas nele
      • crictl pods - encontrar o Pod ID do app1
      • crictl ps - encontrar o contêiner correspondente ao Pod ID
      • crictl inspect <container id> | grep -A16 env - consultar os detalhes desse contêiner e extrair as variáveis de ambiente
  • Obter com uma ServiceAccount que tenha permissão de acesso ao Secret
    • Se a ServiceAccount do pod tiver permissão de acesso ao Secret, é possível encontrar a senha chamando a API de dentro do pod
• Como impedir os ataques descritos acima
  • Seguir o princípio do menor privilégio e não criar service accounts com permissões desnecessárias
  • Evitar expor credenciais de usuários e se preparar para ameaças como engenharia social
  • Criptografar o etcd com o recurso EncryptionConfiguration