1Password CLI développeur : automatiser la gestion des secrets dans votre pipeline
## 1Password CLI pour les développeurs : pourquoi c’est un game-changer pour la gestion des secrets
Le 1Password CLI est l’un des outils les plus sous-estimés de la gestion des secrets dans les équipes de développement. Lors de mes missions d’audit, je vois régulièrement la même configuration problématique : des fichiers `.env` avec des secrets en dur commités par erreur dans Git, des clés AWS dans des fichiers de configuration accessibles à tout le repo, des mots de passe de base de données dans les logs de CI/CD.
Du point de vue sécurité, la gestion des secrets dans les environnements de développement est souvent le maillon faible de toute une architecture de sécurité par ailleurs solide. Le CLI de 1Password offre une solution élégante à ce problème — à condition de savoir l’utiliser correctement.
## Pourquoi les développeurs ont besoin d’une gestion des secrets dédiée
Le problème fondamental : les développeurs ont besoin de secrets (mots de passe, clés API, tokens, certificats) pour faire leur travail. Ces secrets doivent être accessibles facilement, tout en étant sécurisés et traçables.
Les solutions habituelles sont toutes imparfaites :
**Fichiers .env locaux :** Pratiques mais risqués. Il suffit d’un `.gitignore` mal configuré pour exposer des secrets sur GitHub. Et comment partager ces secrets entre membres d’une équipe ? Par Slack ? Par email ?
**Variables d’environnement dans CI/CD :** Mieux, mais les secrets apparaissent souvent dans les logs si on ne fait pas attention. Et la rotation des secrets devient un cauchemar à gérer manuellement dans chaque pipeline.
**HashiCorp Vault :** Excellent mais over-engineered pour la plupart des équipes. La complexité d’installation et de maintenance dépasse souvent la valeur ajoutée pour des équipes de moins de 20 développeurs.
**1Password CLI + Secrets Automation :** Un bon compromis entre sécurité robuste et praticité, particulièrement quand l’équipe utilise déjà 1Password comme gestionnaire de mots de passe.
## Installation et configuration de 1Password CLI
### Installation
Le CLI de 1Password (`op`) est disponible pour Linux, macOS et Windows.
**Sur macOS (via Homebrew) :**
“`bash
brew install 1password-cli
“`
**Sur Linux (Debian/Ubuntu) :**
“`bash
curl -sS https://downloads.1password.com/linux/keys/1password.asc | sudo gpg –dearmor –output /usr/share/keyrings/1password-archive-keyring.gpg
echo ‘deb [arch=amd64 signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] https://downloads.1password.com/linux/debian/amd64 stable main’ | sudo tee /etc/apt/sources.list.d/1password.list
sudo apt update && sudo apt install 1password-cli
“`
**Vérification de l’installation :**
“`bash
op –version
“`
### Authentification
“`bash
# Se connecter à votre compte
op signin
# Pour les environnements sans interface (CI/CD), utiliser un service account token
export OP_SERVICE_ACCOUNT_TOKEN=”votre-token-service-account”
“`
Ce que révèle l’audit de cette approche : les service account tokens de 1Password sont scoped (limités à des vaults spécifiques) et peuvent être révoqués individuellement. C’est bien supérieur à un token d’application qui aurait accès à tout le compte.
## Utilisation basique du CLI
### Lire un secret
“`bash
# Récupérer un mot de passe
op item get “Database Production” –fields password
# Récupérer un champ spécifique
op item get “AWS Production” –fields “Access Key ID”
# Format JSON pour parsing
op item get “API Keys” –format json | jq ‘.fields[] | select(.label == “api_key”) | .value’
“`
### Injection dans les variables d’environnement
C’est la fonctionnalité la plus utile au quotidien. Plutôt que de stocker vos secrets dans un fichier `.env`, vous créez un fichier `.env.tpl` avec des références 1Password :
**Fichier `.env.tpl` (peut être commité dans Git sans risque) :**
“`bash
DATABASE_URL=op://Production/Database/connection_string
AWS_ACCESS_KEY_ID=op://Production/AWS Credentials/access_key_id
AWS_SECRET_ACCESS_KEY=op://Production/AWS Credentials/secret_access_key
STRIPE_SECRET_KEY=op://Production/Stripe/secret_key
“`
**Commande pour injecter les secrets :**
“`bash
op run –env-file .env.tpl — node server.js
# ou
op run –env-file .env.tpl — docker-compose up
“`
`op run` résout les références 1Password et injecte les valeurs dans l’environnement du processus enfant, sans jamais les écrire sur le disque.
La bonne pratique c’est de commiter `.env.tpl` dans Git (aucune donnée sensible) et d’ajouter `.env` au `.gitignore`. Le secret est résolu au moment de l’exécution, pas au moment du commit.
## Intégration CI/CD : GitHub Actions
1Password propose une GitHub Action officielle pour l’intégration dans vos workflows.
**Exemple de workflow GitHub Actions :**
“`yaml
name: Deploy
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v3
– name: Load secrets from 1Password
uses: 1password/load-secrets-action@v1
with:
export-env: true
env:
OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
DATABASE_URL: op://Production/Database/connection_string
AWS_ACCESS_KEY_ID: op://Production/AWS/access_key_id
– name: Deploy
run: npm run deploy
“`
Du point de vue sécurité, ce que révèle l’audit de cette intégration : les secrets ne sont jamais exposés dans les logs de GitHub Actions car ils sont injectés comme variables d’environnement masquées. Le seul secret stocké dans GitHub est le `OP_SERVICE_ACCOUNT_TOKEN`, et ce token peut être scopé uniquement aux vaults nécessaires.
## Intégration avec les environnements de développement locaux
### SSH Agent Integration
1Password peut servir d’agent SSH, stockant vos clés SSH dans votre coffre chiffré :
“`bash
# Dans ~/.ssh/config
Host *
IdentityAgent “~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock”
“`
Vos clés SSH privées restent dans 1Password, déverrouillées par votre biométrie. Fini les clés SSH en clair sur le disque.
### dotfiles Integration
Pour les développeurs qui synchronisent leurs dotfiles via Git, 1Password CLI permet de stocker les secrets séparément :
“`bash
# Dans .zshrc ou .bashrc
export GITHUB_TOKEN=$(op item get “GitHub Personal Token” –fields credential 2>/dev/null)
export NPM_TOKEN=$(op item get “NPM Registry” –fields token 2>/dev/null)
“`
Les dotfiles peuvent être publics sur GitHub, les secrets restent privés dans 1Password.
## Honnêteté sur les limites : mon avis réel sur 1Password CLI
Du point de vue sécurité, 1Password CLI est excellent mais il y a des points que je dois souligner honnêtement.
**Latence de démarrage.** Chaque résolution de secret via `op run` fait un appel API aux serveurs 1Password. Sur des scripts qui s’exécutent fréquemment (hooks git, scripts de test courts), la latence peut être notable. La mise en cache est possible mais demande une configuration soigneuse.
**Dépendance réseau.** Si vous n’avez pas de connexion internet, `op run` échoue (sauf si vous utilisez le mode biométrique avec cache local). Dans des environnements air-gapped, Bitwarden self-hosted ou HashiCorp Vault sont plus adaptés.
**Coût.** 1Password Teams démarre à 4,99€/mois par utilisateur. Pour une startup de 5 développeurs, c’est 25€/mois. Ce n’est pas prohibitif, mais des alternatives open source comme Bitwarden (5$/mois pour l’organisation) existent.
**La courbe d’apprentissage existe.** L’intégration CI/CD demande une configuration initiale non-triviale. Pour des équipes sans DevOps dédié, le temps d’installation peut être un frein.
Ces limites étant posées, 1Password CLI reste ma recommandation pour les équipes de développement qui cherchent un bon équilibre entre sécurité, praticité et intégration avec l’outillage existant.
Détails sur 1Password Teams et CLI : [1password.com](https://1password.com)
## Comparaison avec les alternatives
**AWS Secrets Manager** : Excellent si vous êtes 100% AWS, mais crée une dépendance vendor et un coût supplémentaire. Moins pratique pour les secrets locaux de développement.
**HashiCorp Vault** : Le standard enterprise pour la gestion des secrets à grande échelle. Overkill pour moins de 20 développeurs, mais la solution à recommander pour les grandes organisations avec des flux de secrets complexes.
**Doppler** : Une alternative intéressante, spécialisée dans les secrets pour les pipelines de développement. Interface plus simple que Vault, bonne intégration CI/CD. Moins de fonctionnalités de gestion de mots de passe personnels.
**Bitwarden CLI + Secrets Manager** : Bitwarden a lancé Bitwarden Secrets Manager (beta puis GA en 2023), une solution dédiée aux secrets techniques. Open source, moins cher, mais moins mâture que 1Password CLI.
La bonne pratique c’est de choisir selon votre contexte : si votre équipe utilise déjà 1Password pour les mots de passe personnels et professionnels, l’extension aux secrets techniques avec le CLI est naturelle. Sinon, évaluez Doppler ou Vault selon votre complexité.
## FAQ — 1Password CLI et gestion des secrets