Três Arquivos de Credenciais AWS em um Container: Como Diferenciá-los

Um container quase nunca tem exatamente uma credencial. Ele as acumula: algo montado pelo chart, algo embutido na imagem por uma etapa do Dockerfile, algo que um desenvolvedor copiou para fazer uma integração funcionar numa sexta-feira. De dentro do pod, todas parecem igualmente plausíveis, e o caminho não diz nada sobre qual conta uma chave abre.

É por isso que o id da conta importa. Um id de chave de acesso AWS é uma string opaca, mas a conta a que ela pertence é o que decide se um achado é um incidente ou um dado sem importância. Aqui a nota de auditoria nomeia a conta de produção, 402198773541, e cada arquivo de credenciais registra sua própria conta na linha acima da chave. O trabalho é comparar, não decodificar.

O Secret montado em /var/run/secrets/aws/credentials é o chamariz justamente por ser o artefato de aparência mais legítima no container. É a conta de sandbox. O ConfigMap em /etc/config/app.properties também carrega uma chave, o que já é um achado à parte, já que um ConfigMap é armazenado sem criptografia e pode ser lido por qualquer pessoa com acesso de listagem no namespace, mas essa conta foi desativada em abril. A que bate é /home/appuser/.aws/credentials.

O segundo achado é o que passa despercebido. Verifique /app/deploy/values.yaml e note que o diretório pessoal não está na lista de volumes, então esse arquivo nunca foi montado. Ele viaja dentro da imagem, o que significa que toda réplica o carrega, ele sobrevive a uma rotação de segredo, e qualquer pessoa que consiga baixar a imagem o obtém sem sequer tocar no cluster.

• Enviar a primeira chave que encontrar. O Secret montado é o arquivo de aparência mais oficial e a resposta errada. Leia os três antes de decidir.
• Supor que o Secret montado é o de produção. Onde uma credencial é montada não diz nada sobre qual conta ela abre.
• Ignorar o ConfigMap por não ser chamado de segredo. É exatamente por isso que uma chave dentro de um vale a pena reportar.
• Enviar o id da conta em vez do id da chave. O id da conta identifica o ambiente; a resposta é a string AKIA....
• Caçar a chave de acesso secreta. Ela está redigida, e você não precisa dela. O id da chave já basta para atribuir a atividade.

Nada aqui precisou de um exploit, e esse é o ponto: o container recebeu três conjuntos de credenciais e apenas um deles deveria sequer estar ali.

• Pare de distribuir chaves estáticas para workloads. Use IAM Roles for Service Accounts para que o pod receba credenciais de curta duração vinculadas à sua identidade, sem arquivo algum para vazar.
• Nunca coloque material de credenciais em um ConfigMap. Ele fica sem criptografia em repouso e pode ser lido por qualquer pessoa com acesso de listagem no namespace.
• Faça o build falhar quando houver credenciais embutidas em uma imagem. Uma chave na camada da imagem sobrevive a toda rotação de segredo e vaza junto com a imagem.
• Marque as chaves com seu ambiente e alerte sobre chaves de produção usadas a partir de workloads inesperados, que foi o que pegou esta aqui.
• Exclua credenciais desativadas em vez de deixá-las no lugar. A conta de CI foi desligada em abril e sua chave ainda estava lá na configuração.