Principe d’authentification OIDC
OpenID Connect (OIDC) repose sur l’émission d’un JWT à durée limitée par le fournisseur d’identité (IdP). Le workload récupère ce token, souvent via une variable d’environnement (GitHub, GitLab) ou un appel à un endpoint de métadonnées (AWS, GCP, Azure). Le token porte un claim aud qui indique le service récepteur (relying party, RP) afin d’éviter la réutilisation. Le RP interroge le point .well-known/openid-configuration de l’IdP, télécharge la clé publique JWKS et vérifie la signature du JWT ainsi que les claims pertinents. Si la vérification réussit, l’appel API est autorisé.
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...Intégrations OIDC chez Formal
Formal a implémenté ce flux avec plusieurs extensions. Chaque intégration accepte une condition CEL définie par le client ; le token n’est accepté que si la condition renvoie true. Les champs du JWT sont exposés aux Permissions, ce qui permet de restreindre finement les requêtes du plan de contrôle. L’endpoint CreateFederationToken génère un token d’accès court‑durée pour le Connecteur, en incorporant les claims OIDC d’origine, éliminant ainsi le besoin de stocker des credentials persistants. Formal supporte également les JWT‑SVID de SPIFFE, traités comme des tokens OIDC classiques, et les utilise dans les politiques.
Attestation d’identité humaine et contrôles d’accès
Chaque intégration OIDC correspond à un utilisateur machine. Pour les workloads qui agissent au nom d’un humain (jobs CI, agents déclenchés depuis Slack), Formal autorise la définition d’un claim supplémentaire qui est résolu en identité humaine. Cette identité apparaît dans les journaux et sert d’entrée aux politiques. La confiance repose sur le fait que le client a explicitement indiqué à Formal de faire confiance à la source du claim. Cette approche a d’abord été utilisée pour propager l’identité d’un utilisateur Metabase vers les requêtes de base de données, puis adaptée aux agents cloud qui partagent une même plateforme mais sont lancés par différents utilisateurs.
Cas d’usage et limites
Formal a d’abord remplacé les clés API statiques de Terraform Cloud par l’authentification OIDC, ce qui a supprimé les secrets à long terme dans le plan de contrôle. Ensuite, les agents de codage cloud (Cursor, Devin) sont configurés comme émetteurs OIDC ; ils reçoivent un accès en lecture seule, auditable et limité par politique aux bases de données, aux buckets S3 et aux clusters de logs de production. Les politiques peuvent filtrer sur le dépôt GitHub concerné, l’utilisateur qui a déclenché l’agent ou le type de session. Cette granularité réduit le risque d’escalade accidentelle. Le principal point d’attention reste la dépendance à la fiabilité du claim humain : si la plateforme d’agents est compromise, les identités humaines injectées pourraient être falsifiées, ce qui impose une validation stricte du fournisseur d’identité et un monitoring des anomalies.
