Isolation multi-tenant
ConceptProduitDepuis la version 0.3.0
Guide produit : ce que la capacité apporte, pour qui, ses limites et la version qui l'a livrée - sans syntaxe de configuration.
Côté développeurs : Obtenir des identifiants ; côté exploitation : Brancher son fournisseur d'identité, Poser des quotas.
Le tenant est le client final d'une API : une entreprise, une équipe, un compte. Flexway le lit d'une source vérifiée et l'applique partout, pas seulement au routage.
| Où | Ce qui est garanti |
|---|---|
| Identité | Le tenant vient d'une claim signée, d'une clé d'API, d'un certificat ou d'un maillage de confiance ; la valeur que le client écrit n'atteint jamais l'amont |
| Quotas et budgets | Comptés par tenant : un tenant ne consomme pas le quota d'un autre |
| Cache | Une réponse authentifiée est cachée par tenant et par personne ; test d'isolation à chaque PR |
| Plan asynchrone | Un abonné ne lit que son tenant ; un canal peut être lié à une personne |
| Kafka natif | Un cluster virtuel par tenant ; aucun nom d'un autre tenant, ni dans une réponse, ni vers le courtier ; preuve par mutation à chaque PR |
| Chiffrement | Un champ chiffré est lié à son tenant, son topic et son chemin : copié ailleurs, il ne se déchiffre pas |
| Console | Un compte lié à un tenant ne voit que lui ; ailleurs, 403 |
Limite : l'isolation est logique, dans une passerelle partagée ; une isolation physique se fait en déployant une passerelle par client.