Authentification auth Décidé

Une paire de clés par machine, née à l'enrôlement, qui ne quitte jamais le disque — et des tickets courts pour travailler. Le secret durable ne voyage jamais ; ce qui voyage expire vite. mTLS et clés d'API statiques écartés.

Deux populations très différentes

Les machines — le cas central : des milliers d'agents par revendeur, sans humain devant. Identité longue durée, révocation indispensable (machine volée, décommissionnée). C'est le sujet de cette page.
Les humains — admins revendeur, clients finaux : sur le dashboard, avec SSO/OIDC + MFA (sections H/I, RBAC). Frontière nette : la CLI et la GUI locales parlent au daemon (IPC), qui porte l'identité machine ; ce qui dépasse les droits de la machine (déverrouiller un champ locked de la config…) se fait sur le dashboard, avec une identité humaine.

Les options écartées

mTLS — le sceau de cire qui ne survit pas à la réouverture Le certificat client mTLS prouve l'expéditeur… tant que personne ne rouvre l'enveloppe. Or les proxies d'inspection TLS des entreprises ouvrent et recachettent chaque enveloppe (MITM assumé) : le sceau du client est détruit au passage, l'authentification casse — précisément dans les réseaux que le transport a été conçu pour traverser. mTLS reste excellent entre nos services internes ; côté agents installés chez les autres, c'est une source de tickets sans fin. Écarté pour les agents. Les clés d'API statiques, elles, font transiter un secret éternel à chaque requête — une fuite = accès complet jusqu'à révocation manuelle. Le modèle des années 2010. Écarté aussi.

La décision — la carte d’identité et le ticket journalier

En clair — rien de durable ne voyage, rien de volé ne dure À l'enrôlement, la machine fabrique sa carte d'identité : une paire de clés Ed25519 — la privée ne quitte jamais la machine. Pour travailler, elle se présente au guichet, prouve son identité en signant un défi, et reçoit un ticket journalier (token court, ~1 h) qu'elle joint à chaque requête. Un ticket qui fuite ? Il expire tout seul. On décommissionne la machine ? On invalide la carte côté serveur — plus aucun ticket ne sera émis. C'est le modèle moderne (AWS SigV4, OAuth client assertion), en headers standards : passe tous les proxies.

Note post-quantique : ces signatures sont du temps réel (pas de harvest-now-decrypt-later possible) — Ed25519 suffit, hybridable plus tard comme les signatures d’update.

L’enrôlement — le code d’invitation à usage unique

# attacher une machine à un tenant
1. dashboard / revendeur → token d'enrôlement # usage unique, durée courte
2. cairn enroll <serveur> <code> # l'agent fabrique sa paire de clés
3. agent → serveur : code + clé publique + métadonnées # hostname, OS — jamais la clé privée
4. serveur : consomme le code, enregistre la machine sous le tenant du code

Le bootstrap TOML (config) est écrit ; la clé privée va dans le keystore OS quand il existe (Keychain, DPAPI), en fichier à permissions strictes sinon (NAS). Le provisioning du matériel de chiffrement (CK, CMK) chevauche ce moment mais roule sur son propre rail — le flux custody de la section F : le canal d’authentification ne transporte jamais de secret de chiffrement.

Ce que le ticket porte — l’autorisation

Les claims du token : tenant, machine, scopes. C’est ici que le scoping de l’API d’existence se matérialise — le serveur lit le tenant dans le token, jamais dans la requête. Scopes machine : écrire/lire le CAS de son tenant, lire sa config, heartbeat, sessions. Pas de scope de suppression — l’endpoint n’existe pas. Les quotas et le rate limiting s’accrochent aux mêmes claims (par machine, par tenant) — sujet suivant de la section B.

Ce que font les gros — vérifié

Veeam vs Acronis — deux époques Veeam Cloud Connect (le produit le plus proche de notre modèle revendeur) : des comptes username/password statiques par tenant (format TENANT\SOUS-TENANT), saisis dans l'agent, rotation manuelle — et un port TCP custom 6180 via leur « cloud gateway » : littéralement le modèle « construire sa propre route » qu'on a disqualifié, avec les tickets de pare-feu qui vont avec. Un modèle antérieur au zero-trust, tenu par la position de marché.

Acronis Cyber Protect Cloud : token d'enrôlement à l'installation (qui passe l'identité sans stocker les credentials), identité machine gérée, access tokens style OAuth2 sur API REST en HTTPS standard — notre modèle, à deux crans près : chez nous le secret ne transite jamais (seule la clé publique voyage) et les codes d'enrôlement sont strictement à usage unique.

L'argument commercial en prime : « aucun port à ouvrir dans votre pare-feu » (443 standard) face au 6180 de Veeam — un vrai différenciateur terrain pour les revendeurs qui déploient chez des PME.

Keyboard shortcuts