> ## Content Index > Fetch the complete content index at: https://www.sfeir.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Gestion sécurisée des secrets avec le trousseau de clés MacOS et autoenv - URL: https://www.sfeir.dev/securite/gestion-securisee-des-secrets-avec-le-trousseau-de-cles-macos-et-autoenv/ - Published: 2025-10-08T07:59:17.000Z - Updated: 2025-10-08T07:59:17.000Z - Description: Protégez vos clés et tokens sur macOS grâce au Keychain et autoenv. Secrets chiffrés, chargés automatiquement par projet, sans exposition en clair dans vos fichiers ou historique terminal. - Author: Antoine Méausoone - Tags: shell, Macintosh, Cybersecurité, autoenv, Sécurité La gestion des secrets et variables d'environnement sensibles est un enjeu crucial pour tout développeur. Stocker des tokens, clés API ou mots de passe en clair dans des fichiers `.env`, `.zshrc` ou pire, les laisser traîner dans l'historique bash, peut représenter un risque de sécurité. Cet article présente une approche sécurisée pour macOS qui combine : - Le **Keychain macOS** pour un stockage chiffré des secrets - Des **fonctions shell personnalisées** pour une interface simple - **autoenv** pour le chargement automatique par répertoire ## Problématiques des approches classiques ### ❌ Stockage en clair dans des fichiers La méthode la plus courante consiste à stocker les secrets directement dans des fichiers de configuration ou des scripts shell, par exemple : ```shell # .env ou .zshrc export API_TOKEN="sk_live_xxxxxxxxxxxx" # pragma: allowlist secret export DATABASE_PASSWORD="motdepasse123" # pragma: allowlist secret ``` [Les secrets](https://www.sfeir.dev/cloud/simplifier-la-gestion-des-secrets-avec-vault-secret-operator/) stockés en clair dans les fichiers `.envrc` peuvent être exposés lors de commits accidentels dans Git (d'ailleurs [que faire si vous avez commité un mot de passe ?](https://www.sfeir.dev/securite/de-la-bonne-gestion-des-donnees-sensibles-dans-les-depots-git/)), du partage d'écran, ou être accessibles à tout processus ayant accès au système de fichiers. ### ❌ Historique bash compromis Une autre pratique dangereuse consiste à taper des commandes contenant des secrets directement dans le terminal, laissant des traces permanentes dans l'historique. ```shell # Commandes visibles dans l'historique export SECRET_KEY="ma-cle-secrete" # pragma: allowlist secret curl -H "Authorization: Bearer mon-token" api.example.com ``` Les commandes contenant des secrets restent dans `~/.zsh_history`, sont accessibles via `history | grep token`, visibles par tous les utilisateurs du système et persistent même après redémarrage. ## Solution : Trousseau de clé MacOS La cli [security](https://ss64.com/osx/security.html?ref=sfeir.dev) intégrée à macOS permet de gérer le Keychain, un stockage sécurisé et chiffré pour les secrets. Cependant, son usage direct est peu ergonomique. C'est pourquoi j'ai créé des fonctions shell pour simplifier l'interaction. Le fichier [30\_creds.zsh](https://github.com/Ameausoone/macos-provision/blob/main/roles/mac%5Fdev%5Fplaybook/files/.zshrc.d/core/30%5Fcreds.zsh?ref=sfeir.dev) fournit une interface sécurisée pour le Keychain macOS. Ces fonctions encapsulent les commandes `security` système pour simplifier l'usage. #### Ajout d'un secret Pour ajouter un nouveau secret au Keychain, utilisez la fonction `creds_upsert_local_secret` qui garantit un stockage sécurisé et chiffré. ```shell creds_upsert_local_secret "myservice" "api_key" # Vous serez invité à saisir le secret de manière masquée ``` La fonction vérifie l'existence d'une entrée dans le Keychain, la supprime si nécessaire, puis crée une nouvelle entrée chiffrée en utilisant votre nom d'utilisateur comme identifiant. #### Récupération d'un secret Pour accéder à un secret stocké dans le Keychain, utilisez la fonction `creds_get_local_secret` qui récupère la valeur de manière sécurisée. ```shell # Récupération directe pour usage immédiat export API_TOKEN=$(creds_get_local_secret "myservice" "api_key") # Stockage dans une variable pour usage multiple my_token=$(creds_get_local_secret "myservice" "api_key") echo "Token length: ${#my_token}" ``` **Sécurité :** Le secret est stocké de façon chiffrée dans le Keychain macOS, et chargé temporairement en mémoire. #### Suppression d'un secret Quand un secret n'est plus nécessaire, supprimez-le définitivement du Keychain pour maintenir une hygiène de sécurité optimale. ```shell # Suppression définitive du Keychain creds_delete_local_secret "myservice" "api_key" ``` Cette solution offre un stockage chiffré avec authentification système via Touch ID, sans laisser de traces en clair dans les fichiers. Les secrets sont chargés à la volée depuis le Keychain, et s'intègrent nativement avec tous les outils macOS. ### 2\. Configuration des variables d'environnement Comme indiqué plus haut, vous pouvez maintenant charger les secrets dans vos variables d'environnement de manière sécurisée. Voici un exemple simple d'un fichier `.zshrc` qui charge automatiquement une clé API au démarrage du shell. ```shell #!/usr/bin/env zsh # Récupération de la clé API depuis le Keychain export API_TOKEN=$(creds_get_local_secret "myservice" "api_key") ``` ### Comment charger mes secrets automatiquement par projet ? La solution précédente est efficace, mais elle charge les secrets globalement à chaque ouverture de terminal. Pour une meilleure isolation et sécurité, il est préférable de charger les secrets uniquement dans le contexte d'un projet spécifique. [**autoenv**](https://github.com/hyperupcall/autoenv?ref=sfeir.dev) est un outil qui exécute automatiquement des scripts quand vous naviguez vers un répertoire. **L'avantage principal** : les secrets ne sont chargés que quand vous en avez besoin, dans le contexte du projet spécifique, plutôt que d'être disponibles globalement dans votre shell. Cela permet de : - **Charger les secrets uniquement par projet** : évite l'exposition inutile de tokens - **Isolation des environnements** : chaque projet a ses propres variables - **Chargement automatique** : pas besoin de se souvenir de commandes manuelles #### Installation et configuration ```shell # Installation via Homebrew brew install autoenv # Activation dans votre shell (ajout à ~/.zshrc) echo 'source $(brew --prefix autoenv)/activate.sh' >> ~/.zshrc # Rechargement de la configuration source ~/.zshrc ``` #### Fonctionnement détaillé **1\. Détection automatique :** Quand vous entrez dans un répertoire avec `cd`, autoenv cherche un fichier `.env`. **2\. Exécution sécurisée :** ```shell # Première fois : autoenv demande confirmation cd /mon/projet # autoenv: WARNING: /mon/projet/.env is not trusted. # Do you want to allow this? (y/N) ``` **3\. Exemple de fichier `.env` simple :** ``` #!/usr/bin/env zsh # Chargement simple des secrets depuis le Keychain export API_TOKEN=$(creds_get_local_secret "myservice" "api_key") export DATABASE_URL=$(creds_get_local_secret "myproject" "database_url") export EXTERNAL_API_KEY=$(creds_get_local_secret "external" "api_key") ``` Lorsque vous naviguez vers un projet avec cd, autoenv détecte automatiquement le fichier `.env`, demande éventuellement votre authentification Keychain, puis charge les variables d'environnement qui deviennent disponibles pour tous vos outils. ## Comparaison avec d'autres solutions Plusieurs solutions existent pour gérer les secrets. Les services tiers offrent une gestion centralisée et des droits d'accès granulaires, mais nécessitent une authentification supplémentaire et une interface moins fluide que le Keychain local de macOS. Petite comparaison non exhaustive des solutions : | Solution | Sécurité | Simplicité | Intégration macOS | | ---------------------- | -------- | ---------- | ----------------- | | **Keychain + autoenv** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | | Fichiers .env | ⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | | HashiCorp Vault | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐ | | GCP Secrets Manager | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ## Conclusion Cette approche offre un équilibre optimal entre sécurité et productivité pour les développeurs macOS. En combinant le Keychain système, autoenv et des fonctions shell sur mesure, nous obtenons : - **Sécurité renforcée** : Chiffrement matériel, pas de stockage en clair - **Expérience développeur fluide** : Chargement automatique, interface simple - **Maintenabilité** : Configuration centralisée, gestion d'erreurs robuste L'investissement initial en configuration est rapidement rentabilisé par la tranquillité d'esprit et la réduction des risques de sécurité.