Trois fichiers d'identifiants AWS dans un conteneur : comment les distinguer

Un conteneur n'a presque jamais un seul identifiant. Il en accumule : quelque chose monté par le chart, quelque chose intégré à l'image par une étape du Dockerfile, quelque chose qu'un développeur a copié pour faire fonctionner une intégration un vendredi. Depuis l'intérieur du pod, ils paraissent tous aussi plausibles les uns que les autres, et le chemin ne dit rien sur le compte que la clé ouvre.

C'est pourquoi l'identifiant de compte importe. Un identifiant de clé d'accès AWS est une chaîne opaque, mais le compte auquel elle appartient est ce qui détermine si une découverte est un incident ou n'est rien du tout. Ici, la note d'audit nomme le compte de production, 402198773541, et chaque fichier d'identifiants indique son propre compte sur la ligne au-dessus de la clé. Le travail consiste à faire correspondre, pas à décoder.

Le Secret monté à /var/run/secrets/aws/credentials est le leurre précisément parce qu'il s'agit de l'artefact le plus légitime en apparence dans le conteneur. Il s'agit du bac à sable. La ConfigMap à /etc/config/app.properties porte elle aussi une clé, ce qui constitue en soi une découverte puisqu'une ConfigMap est stockée sans chiffrement et lisible par toute personne disposant d'un accès en liste sur le namespace, mais ce compte a été mis hors service en avril. La correspondance est /home/appuser/.aws/credentials.

La seconde découverte est celle qu'on rate le plus souvent. En vérifiant /app/deploy/values.yaml, on constate que le répertoire personnel ne figure pas dans la liste des volumes, donc ce fichier n'a jamais été monté. Il voyage à l'intérieur de l'image, ce qui signifie que chaque réplique le transporte, qu'il survit à une rotation de secret, et que quiconque peut extraire l'image l'obtient sans même toucher au cluster.

• Soumettre la première clé trouvée. Le Secret monté est le fichier qui paraît le plus officiel et c'est la mauvaise réponse. Lisez les trois avant de décider.
• Supposer que le Secret monté est celui de production. L'endroit où un identifiant est monté ne dit rien sur le compte qu'il ouvre.
• Ignorer la ConfigMap parce qu'elle ne s'appelle pas secret. C'est précisément pour cette raison qu'une clé qui s'y trouve mérite d'être signalée.
• Soumettre l'identifiant de compte au lieu de l'identifiant de clé. L'identifiant de compte identifie l'environnement. La réponse est la chaîne AKIA....
• Chercher la clé d'accès secrète. Elle est masquée et vous n'en avez pas besoin. L'identifiant de clé suffit pour attribuer l'activité.

Rien ici n'a nécessité d'exploit, et c'est bien le problème : le conteneur s'est vu confier trois jeux d'identifiants, et un seul d'entre eux était même censé s'y trouver.

• Arrêtez de livrer des clés statiques aux workloads. Utilisez IAM Roles for Service Accounts pour que le pod reçoive des identifiants de courte durée liés à son identité, sans fichier à faire fuiter.
• Ne mettez jamais d'identifiants dans une ConfigMap. Elle n'est pas chiffrée au repos et est lisible par toute personne disposant d'un accès en liste sur le namespace.
• Faites échouer le build en présence d'identifiants intégrés à une image. Une clé dans une couche d'image survit à toute rotation de secret et fuite avec l'image.
• Étiquetez les clés selon leur environnement et déclenchez une alerte lorsqu'une clé de production est utilisée depuis un workload inattendu, ce qui est précisément ce qui a permis de détecter celle-ci.
• Supprimez les identifiants mis hors service au lieu de les laisser en place. Le compte CI a été désactivé en avril et sa clé était toujours présente dans la configuration.