Sujet : secrets
-
Un secret a été committé : pourquoi supprimer le fichier ne suffit pas, et dans quel ordre réagir
Un identifiant poussé dans un dépôt Git persiste dans l'historique, les forks, les clones, les caches et les journaux de CI. Réécrire l'historique réduit l'exposition future mais ne peut pas rappeler les copies déjà faites ; la première étape consiste donc à révoquer et faire tourner l'identifiant, puis à nettoyer l'historique, puis à vérifier s'il a été utilisé.
-
Journalisation depuis les scripts d'administration : logger et systemd-cat sous Linux, Write-EventLog/New-WinEvent et Start-Transcript sous Windows
Chaque plateforme permet d'envoyer la sortie d'un script d'administration à un emplacement où une personne ou un autre outil la retrouvera plus tard, ce qui est distinct d'une simple écriture sur stdout : logger(1) ou systemd-cat vers le journal système sous Linux, le journal d'événements Windows via Write-EventLog (Windows PowerShell 5.1 uniquement) ou New-WinEvent, et Start-Transcript pour une capture brute de session. Aucun de ces mécanismes ne doit jamais recevoir de secret.
-
Où se trouvent les identifiants sur une machine de développement qu'un processus agent peut lire
Un agent qui s'exécute sous l'identité de la personne qui l'utilise peut lire tout ce que cette personne peut lire : variables d'environnement, fichiers d'identifiants des CLI, connexions aux registres de conteneurs, clés SSH, historique du shell et magasins proches du navigateur. Connaître ces emplacements permet à une personne opérant le système de décider ce qui doit rester hors de portée de l'agent et ce qui doit être renouvelé après un incident.
-
ConfigMaps et Secrets dans Kubernetes : limites de taille, propagation des mises à jour et ce qu'un Secret ne protège pas
Les ConfigMaps et les Secrets sont tous deux des objets clé-valeur plafonnés à 1 Mio ; les clés montées en volume se rafraîchissent après un délai de synchronisation du kubelet, alors que les variables d'environnement ne se rafraîchissent jamais, les montages subPath ne se mettent jamais à jour, et un Secret n'est encodé qu'en base64 et stocké non chiffré dans etcd, sauf si le chiffrement au repos et le RBAC sont configurés.
-
Stocker des secrets pour des scripts non supervisés : credentials systemd, DPAPI, trousseau macOS — et ce qu'il faut éviter
Chaque système d'exploitation propose un mécanisme pour fournir un secret à un script sans variable d'environnement ni argument de ligne de commande, lisibles par tout processus voisin ou journal : LoadCredential= de systemd, DPAPI sous Windows via Export-Clixml ou SecretManagement, et le trousseau macOS via security find-generic-password.
-
Caviarder les secrets avant l'écriture des journaux
Journaliser un enregistrement de diagnostic construit à partir d'une liste blanche de champs plutôt que les requêtes brutes de l'outil, et vérifier le caviardage à chaque point de sortie.
-
Gérer les secrets en dehors du dépôt
Les identifiants d'accès doivent se trouver dans une configuration protégée, injectée à l'exécution – jamais dans le contrôle de version, dans des images ni dans des journaux ; chaque service reçoit ses propres identifiants, étroitement délimités, et la rotation est une procédure entraînée plutôt qu'une urgence. Les étapes suivent le cheat sheet OWASP sur la gestion des secrets et la séparation Twelve-Factor entre configuration et code.
-
La rotation planifiée des secrets révèle les consommateurs d'identifiants non documentés avant qu'un incident ne le fasse
Hypothèse : les équipes qui font tourner sur un calendrier fixe des secrets partagés à longue durée de vie découvrent, lors des rotations planifiées, les scripts, tâches et intégrations qui en dépendent silencieusement, si bien qu'une rotation d'urgence consécutive à une fuite se termine plus vite et casse moins de choses que pour les équipes qui ne font tourner leurs secrets qu'en cas de soupçon ; le pense-bête de l'OWASP recommande une rotation régulière, mais ce bénéfice opérationnel n'est pas mesuré.
Lisible par machine : JSON