Identifiants

Le volet Identifiants est l'endroit où vous fournissez à un espace de travail les secrets dont son agent a besoin — jetons git, clés SSH, identifiants cloud, mots de passe de base de données — sans qu'aucun de ces secrets n'entre jamais dans la VM. Chaque valeur que vous saisissez ici est stockée chiffrée sur votre Mac. À l'intérieur du bac à sable, l'agent ne voit qu'un faux préservant la structure (par exemple brm_…) ; lorsqu'une requête quitte réellement votre Mac, le proxy côté hôte réintègre la vraie valeur, en la limitant à l'hôte de destination.

Cette page constitue la référence champ par champ du volet. Le mécanisme sous-jacent — la frontière du fil, les faux déterministes, le cantonnement par hôte, le resigner AWS à sécurité intégrée et le détecteur de compromission — est documenté en détail dans Identifiants et la frontière du fil. Lisez ce chapitre pour le modèle de sécurité ; lisez cette page pour remplir les champs. Les contrôles d'approbation et de politique d'écriture par identifiant se trouvent désormais dans le volet Garde-fous, et non ici.

Remarque : La capture d'écran ci-dessus est antérieure à la refonte et peut afficher l'ancienne pile de sections repliables. Le volet actuel n'affiche que les identifiants que vous avez configurés, regroupés sous des en-têtes de catégorie, ainsi que les deux boutons décrits ci-dessous.

Le volet s'ouvre avec Identité Git épinglée en haut, suivie d'une liste des identifiants que vous avez déjà configurés — rien d'autre. Chaque identifiant configuré occupe une ligne ; les familles vides qui étaient auparavant repliées sur le volet ont disparu. Deux boutons en bas, Ajouter un identifiant et Importer un fichier env…, permettent d'en ajouter davantage. Rien n'est appliqué tant que vous ne cliquez pas sur Enregistrer.

Identité Git

Les deux champs en haut définissent l'identité d'auteur git écrite dans ~/.gitconfig à l'intérieur de la VM :

• user.name — texte indicatif Votre nom.
• user.email — texte indicatif [email protected].

La légende indique : Écrit dans ~/.gitconfig dans la VM. Laissez les deux champs vides pour conserver les valeurs par défaut de git. Ce ne sont pas des secrets et ils ne sont pas échangés — il s'agit d'une simple configuration afin que les commits réalisés par l'agent soient correctement attribués. Laisser un champ vide conserve la valeur par défaut de git correspondante.

La liste des identifiants configurés

Sous Identité Git, le volet ne liste que les identifiants qui produisent effectivement un échange au lancement de la session, regroupés sous des en-têtes de catégorie :

Chaque ligne affiche une icône, un titre et le ou les hôtes auxquels l'identifiant est cantonné (pour un jeton git, user@host ; pour une base de données ou un registre, son hôte ; pour AWS, amazonaws.com ; et ainsi de suite). Un menu ⋯ à droite — également accessible en cliquant sur la ligne — propose Modifier… et Retirer :

• Modifier… rouvre l'éditeur de cet identifiant afin que vous puissiez modifier ou révéler ses champs.
• Retirer supprime l'identifiant de l'espace de travail. (Il n'y a pas d'annulation autre que le réajout ; rien n'est retiré du disque tant que vous n'avez pas Enregistré.)

Les lignes sous AGENTS constituent la seule exception : leur menu indique Modifier dans Agents… et n'a pas de Retirer, car les clés d'agent appartiennent au volet Agents. Le choisir bascule l'éditeur vers ce volet.

Lorsqu'un espace de travail n'a aucun identifiant, la liste est remplacée par un état vide — Aucun identifiant pour l'instant — vous rappelant que les vraies valeurs restent sur votre Mac et que la VM ne détient jamais qu'un faux.

Ajouter un identifiant

Cliquez sur Ajouter un identifiant pour ouvrir la feuille de sélection. Elle liste tous les types d'identifiant que l'application peut ajouter ; chaque entrée ouvre l'éditeur de ce type :

Les clés d'API d'agent sont délibérément absentes de ce sélecteur ; une note de bas de page vous rappelle que les clés Anthropic, OpenAI et xAI se configurent dans le volet Agents. Chaque éditeur est une feuille avec un bouton Terminé ; les champs de chaque type sont décrits dans les sections ci-dessous.

Importer un fichier env

Cliquez sur Importer un fichier env… pour extraire des identifiants d'un fichier .env existant — ou d'un ~/.bashrc. L'analyseur lit les affectations simples KEY=VALUE et export KEY=VALUE, retire les guillemets qui les entourent et les # commentaires en fin de ligne, et prend la dernière affectation lorsqu'un nom est répété. Il n'exécute jamais de shell : toute valeur qui nécessiterait une interpolation (une référence $VAR ou une substitution de commande $(…)) est ignorée plutôt qu'importée de façon erronée, si bien que le pointer vers un vrai .bashrc est sans danger.

Les variables du fichier sont ensuite présentées dans une feuille de révision intitulée Importer depuis <nom-de-fichier>, réparties en deux groupes. Chaque valeur est masquée dans cette feuille.

Les variables Reconnues sont automatiquement associées à leur type d'identifiant :

Chaque ligne reconnue comporte une case à cocher. Un jeton git demande en plus un Nom d'utilisateur git (texte indicatif vous) afin que l'identifiant soit complet. Si une variable correspond à quelque chose que l'espace de travail a déjà configuré, sa ligne est signalée Déjà configuré — cochez pour écraser. et laissée décochée, de sorte qu'une réimportation n'écrase jamais silencieusement un secret existant.

Les variables Non reconnues peuvent être importées comme jetons génériques Autre clé d'API. Chaque ligne comporte un champ Hôte(s) — une liste d'hôtes séparés par des virgules sur lesquels le faux doit être échangé (plusieurs hôtes autorisés ; vide signifie n'importe quel hôte). Le nom de la variable d'environnement est réutilisé à la fois comme nom du jeton et comme variable sous laquelle le faux est exporté.

Le bouton indique Importer N identifiants et ne reflète que les lignes que vous avez laissées cochées. L'importation fusionne les sélections dans le volet ; vous devez toujours cliquer sur Enregistrer pour les persister.

Clés SSH

L'éditeur Clé SSH gère les clés avec lesquelles l'espace de travail peut s'authentifier via SSH. Les octets de la clé privée n'entrent jamais dans la VM : la signature est assurée par un pont ssh-agent en cours de processus via vsock, de sorte que l'invité peut demander des signatures mais ne peut jamais lire la clé.

Il existe deux sources de clés :

• La paire de clés ed25519 propre à l'espace de travail. Les nouveaux espaces de travail comportent un interrupteur Générer une paire de clés ed25519 pré-coché (à moins que votre modèle de préférences ne fournisse déjà une clé). Une fois qu'une clé existe, l'éditeur affiche sa clé publique avec des boutons Copier et Ouvrir la page des clés GitHub (pour la coller dans github.com/settings/keys) et un interrupteur Régénérer.
• Clés SSH importées. Sous Clés SSH importées, cliquez sur Importer… pour ouvrir un sélecteur de fichiers ; une feuille demande alors une Étiquette et, si la clé est chiffrée, une Phrase secrète. Les phrases secrètes sont stockées dans le trousseau macOS, et les clés importées sont chargées dans le ssh-agent propre à l'espace de travail à chaque lancement de session. Les clés RSA, ed25519 et ecdsa sont prises en charge.

Jetons git (GitHub, GitLab, Bitbucket)

L'éditeur Jeton git détient les jetons d'accès personnels pour git via HTTPS, répartis en groupes GitHub, GitLab et Bitbucket. Comme l'indique sa légende : les jetons d'accès personnels sont stockés chiffrés sur l'hôte, et le proxy les échange sur les requêtes sortantes de sorte que la VM ne détient jamais que le faux. gh et glab récupèrent automatiquement GH_TOKEN / GITLAB_TOKEN.

Cliquez sur Ajouter un jeton dans un groupe pour ajouter une ligne. Chaque ligne prend un Hôte, un Nom d'utilisateur et un Jeton d'accès personnel (avec un bouton œil pour révéler et un lien vers la page des jetons de la forge concernée). Le faux est écrit dans ~/.git-credentials et dans les configurations CLI gh / glab à l'intérieur de la VM. Le champ hôte vous permet de pointer une entrée vers github.com, gitlab.com ou une instance auto-hébergée GitLab/Gitea/Bitbucket.

Linear

L'éditeur Clé d'API Linear prend une seule clé d'API personnelle (texte indicatif de la forme lin_api_…, avec un lien Ouvrir les paramètres d'API Linear). Elle est injectée dans la VM sous le nom LINEAR_API_KEY, que le SDK Linear, les serveurs MCP et les outils CLI récupèrent automatiquement, et n'est échangée du faux au vrai que sur les requêtes vers linear.app (y compris api.linear.app et mcp.linear.app). Une clé Linear dans l'espace de travail est également le prérequis pour les déclencheurs d'automatisation planifiée sur les tickets Linear.

Kubernetes

L'éditeur Kubernetes détient une ligne par contexte de cluster. Bromure Agentic Coding construit un ~/.kube/config synthétique à l'intérieur de la VM pour que kubectl communique avec le proxy, jamais directement avec le serveur d'API ; la vraie identité reste sur l'hôte.

Chaque contexte a un nom, une URL de serveur, un certificat CA facultatif (PEM, utilisé pour que le proxy puisse vérifier le serveur d'API en amont), un Espace de noms et une méthode d'authentification choisie à l'aide d'un contrôle segmenté :

• Jeton porteur — un jeton statique, échangé contre la vraie valeur sur le fil.
• Certificat client — le vrai certificat et la vraie clé sont enregistrés sur l'hôte pour le TLS mutuel en amont ; la VM reçoit un certificat auto-signé jetable.
• Plugin exec — une Commande, des Arguments et un incrémenteur Actualisation (1 à 60 minutes). Le plugin s'exécute sur l'hôte à chaque intervalle d'actualisation et le nouveau jeton est injecté dans la table d'échange ; le kubectl de la VM n'exécute jamais le plugin.

Un badge sur chaque ligne indique de quel type il s'agit (jeton / certificat / exec). Utilisez Importer un fichier… pour analyser un kubeconfig existant en une ligne par contexte, ou Ajouter un contexte pour en ajouter un manuellement. La politique d'écriture correspondante par contexte se règle dans le volet Garde-fous.

DigitalOcean

L'éditeur Jeton DigitalOcean prend un seul jeton d'accès personnel (texte indicatif de la forme dop_v1_…, avec un lien vers la page des jetons DigitalOcean). Il est injecté sous le nom DIGITALOCEAN_ACCESS_TOKEN et écrit dans ~/.config/doctl/config.yaml, si bien que doctl auth init est inutile. Le jeton est échangé du faux au vrai sur les requêtes vers digitalocean.com, et une seconde entrée d'échange couvre la forme d'authentification Basic en base64 utilisée lorsque docker login ou doctl registry login s'authentifie auprès de registry.digitalocean.com.

AWS

L'éditeur Identifiants AWS configure les identifiants pour la CLI aws, les SDK, terraform et le mode d'authentification Bedrock de Claude Code. Le vrai secret n'atteint jamais la VM — l'hôte re-signe les requêtes SigV4 avec le vrai matériel, et une requête qui contourne le proxy obtient une InvalidSignatureException d'AWS. Un contrôle segmenté Méthode d'authentification permet de choisir entre :

• Clés statiques — ID de clé d'accès, Clé d'accès secrète, un Jeton de session facultatif (STS uniquement) et une Région par défaut, ainsi qu'un lien Ouvrir la page des identifiants IAM.
• SSO / Identity Center — un sélecteur de dossier Accorder l'accès à ~/.aws, puis un sélecteur de profil SSO rempli à partir des profils découverts dans votre ~/.aws/config (avec un bouton d'actualisation). Les identifiants de rôle temporaires sont résolus sur l'hôte, déclenchant aws sso login dans votre navigateur lorsque le jeton en cache a expiré.

Le traitement complet d'AWS — l'assistant credential_process, le resigner et ses limites — figure dans Identifiants et la frontière du fil.

Registres de conteneurs

L'éditeur Registre de conteneurs détient l'authentification HTTP Basic par registre pour docker pull / docker push. Comme l'explique la légende, le vrai mot de passe n'est jamais écrit dans la VM — bromure place un faux base64("<user>:<derived>") dans ~/.docker/config.json, et le proxy substitue la vraie valeur sur le fil lorsque la requête atteint l'hôte de registre correspondant.

Le menu Ajouter propose des préréglages — Docker Hub (docker.io), GitHub Container Registry (ghcr.io), GitLab Container Registry (registry.gitlab.com), Quay (quay.io) et Autre hôte… — ainsi que Importer config.json…, qui extrait les entrées d'un ~/.docker/config.json existant. L'importation ignore les entrées credsStore / credHelpers (leurs mots de passe résident dans le trousseau du système d'exploitation plutôt que dans le fichier) et indique combien ont été ignorées. Chaque ligne de registre prend un Hôte, un Nom d'utilisateur et un Mot de passe ou jeton. La politique d'écriture push/pull/delete correspondante se règle dans le volet Garde-fous.

Bases de données (MongoDB, ClickHouse, Elasticsearch)

L'éditeur Base de données détient une ligne par point de terminaison HTTPS, regroupée par moteur. Le faux est exporté sous les noms de variables d'environnement que vous listez et est échangé contre la vraie valeur partout où il apparaît — en-tête, paramètre de requête ou corps de requête.

Chaque ligne de point de terminaison a :

• Nom — nom d'affichage facultatif.
• Hôte — le nom d'hôte nu ; il cantonne à la fois l'échange et le garde-fou du point de terminaison.
• Authentification — un contrôle segmenté : Nom d'utilisateur + mot de passe, Clé d'API ou Jeton porteur. MongoDB utilise par défaut Clé d'API ; ClickHouse et Elasticsearch utilisent par défaut Nom d'utilisateur + mot de passe.
• Nom d'utilisateur — pour l'authentification Basic uniquement.
• Secret — avec un bouton œil pour révéler.
• Variable(s) d'environnement — une liste séparée par des virgules des noms sous lesquels le faux doit être exporté.

Les nouveaux points de terminaison de base de données ont par défaut leur politique d'écriture par point de terminaison réglée sur Demander avant d'écrire, définie dans le volet Garde-fous — la classification propre à chaque moteur (quelles actions Mongo, quels mots-clés SQL, quels chemins Elasticsearch comptent comme des écritures) y réside.

Autres clés d'API

L'éditeur Autre clé d'API est la solution de secours pour tout service que Bromure Agentic Coding ne gère pas automatiquement. Chaque entrée est une règle d'échange manuelle :

• Nom — une étiquette pour l'entrée.
• Vrai secret — masqué (texte indicatif de la forme sk_live_…).
• Variable d'environnement — le nom sous lequel le faux est exporté à l'intérieur de la VM. Laisser ce champ vide n'exporte rien ; vous copieriez alors le faux depuis la bannière d'accueil de la session.
• Hôte d'API (facultatif) — le ou les hôtes auxquels l'échange est cantonné (exact ou sous-domaine, séparés par des virgules). Vide signifie « injecter sur n'importe quel hôte ».

La VM voit un faux brm_… généré et le proxy le réintègre sur le fil.

Avertissement : Un Hôte d'API vide n'est délibérément jamais contrôlé par le détecteur de compromission — il s'agit d'un choix explicite « injecter sur n'importe quel hôte ». Pour garder un secret non cantonné sous contrôle, donnez-lui soit un hôte, soit activez Demander avant utilisation pour lui dans le volet Garde-fous.

Les politiques d'approbation et d'écriture résident dans Garde-fous

Il n'y a plus de cases à cocher Exiger une approbation pour utiliser dans le volet Identifiants. Le contrôle de consentement par identifiant — désormais présenté sous la forme Demander avant utilisation — et la politique d'écriture de chaque service résident tous deux dans le volet Garde-fous, qui liste une ligne par identifiant configuré. Configurez le secret ici ; décidez de la manière dont l'agent est autorisé à l'utiliser là-bas.

Comment le volet est stocké

Tout ce qui figure dans ce volet est un secret, aussi, à l'enregistrement, il est extrait du profile.json en texte clair pour être placé dans le secrets.enc chiffré de l'espace de travail (AES-GCM, clé issue du trousseau macOS, permissions 600). Les fournisseurs gérés automatiquement — Anthropic, OpenAI, GitHub, GitLab, DigitalOcean, Kubernetes — ne nécessitent aucune saisie manuelle au-delà de ce que vous configurez ici ; la clé d'API de l'agent principal se définit dans le volet Agents.

Référence des paramètres

Les Demander avant utilisation par identifiant et les politiques d'écriture se règlent dans le volet Garde-fous.

Chapitres connexes

• Identifiants et la frontière du fil — le modèle de sécurité complet derrière ce volet.
• Agents — la clé d'API de l'agent principal et les modes d'authentification par abonnement/Bedrock.
• Garde-fous — l'approbation par identifiant et les politiques d'écriture par service pour ces mêmes secrets.
• Référence des paramètres — tous les volets en un coup d'œil.