SPIFFE / mTLS
Authentification service à service dans Scrydon — identité SPIFFE native Dapr, mTLS et la chaîne de confiance à quatre couches.
Toutes les communications internes service à service dans Scrydon sont mutuellement authentifiées via l'identité SPIFFE sur mTLS. Il n'existe pas de jetons Bearer partagés pour les appelants de services, ni de chemin de secours contournant la vérification d'identité.
La chaîne de confiance à quatre couches
Chaque appel interne passe par quatre vérifications indépendantes. Tout échec refuse la requête.
| Couche | Ce qu'elle vérifie |
|---|---|
| Transport | mTLS Dapr entre les sidecars. Certificats émis par l'autorité de certification Dapr Sentry. |
| Réseau | Liste de contrôle d'accès Dapr (defaultAction: deny). Seuls les IDs d'application explicitement autorisés atteignent une route donnée. |
| Application | Le service récepteur valide l'ID d'application, l'espace de noms et la capacité requise de l'appelant. |
| Provenance | Le récepteur vérifie que la requête a transité par le sidecar Dapr en inspectant un jeton émis par le sidecar. |
Fermeture en cas d'échec : si une couche échoue, la requête est refusée sans repli.
Vérification d'identité
Chaque route interne résout l'appelant via un seul assistant :
- Extraire l'identité de l'appelant — ID d'application, espace de noms, jeton sidecar.
- Rechercher la capacité requise pour la route.
- Faire correspondre l'identité à la liste d'autorisation de la route.
- Faire correspondre la capacité à l'ensemble des droits de l'appelant.
- Retourner la décision — autorisé, ou refusé avec une erreur structurée.
La décision est enregistrée dans le journal d'audit sous forme d'événement AUTH_INTERNAL_*.
Capacités
Les appels internes n'ont pas carte blanche. Chaque récepteur déclare les capacités qu'il accepte, et chaque appelant ne reçoit que les capacités dont il a besoin. Exemples :
| Capacité | Accordée à | Objectif |
|---|---|---|
llm:complete | La passerelle LLM | Permission d'invoquer un modèle LLM |
managed-table:read | Le service analytique, le service d'ontologie | Lire des lignes de tables gérées |
managed-table:agent-create | Le runtime de workflow | Créer des tables gérées par agent |
kb:read | La surface de récupération, la surface de chat | Lire des documents de base de connaissances au niveau d'habilitation de l'appelant |
secrets:internal | Le runtime de workflow | Récupérer les informations d'identification déchiffrées pour l'autorisation d'exécution active |
Les capacités sont vérifiées par requête. Il n'y a pas de notion de « cet appelant est admin donc tout est permis ».
Mode développement
Le développement local sans plan de contrôle Dapr fonctionne en mode dégradé : un marqueur d'identité de développement éphémère remplace l'identité SPIFFE. Ce mode est rejeté en production. Le récepteur inspecte le mode de déploiement et refuse d'honorer un marqueur de développement s'il ne fonctionne pas dans un environnement de développement.
Ce que cela vous apporte
- Protection contre l'usurpation. Une requête prétendant provenir d'un service interne doit réellement transiter par un sidecar Dapr avec un certificat mTLS valide. Les requêtes fabriquées à la main avec des en-têtes forgés sont rejetées au niveau de la couche transport.
- Confinement des mouvements latéraux. Un pod compromis ne peut appeler que les services que son ID d'application est explicitement autorisé à atteindre. Il n'y a pas de « zone de confiance interne » accordant à tout le monde l'accès à tout.
- Clarté des audits. Chaque appel interne est identifié par l'ID d'application de l'appelant, et non par un jeton de compte de service opaque. Le journal d'audit peut répondre de manière déterministe à « quel service a appelé ce point de terminaison ».
Le plan de contrôle Dapr s'exécute dans votre cluster. Scrydon n'a pas accès à vos matériaux d'identité de maillage de services — l'autorité de certification Sentry vous appartient, et sa clé privée ne quitte jamais votre cluster.
En relation
- Périmètre réseau — le périmètre plus large autour du maillage.
- Durcissement de l'ingress — comment les requêtes externes sont nettoyées avant d'atteindre le maillage.
- Autorisation — comment l'autorisation pilotée par l'utilisateur interagit avec l'identité service à service.