AWS
Jetscale se connecte par l’entremise d’un rôle IAM intercompte plutôt que d’une clé d’accès partagée. Vous créez le rôle dans votre propre compte, et Jetscale l’assume temporairement à l’aide de sts:AssumeRole, sécurisé par un ID externe unique qui empêche toute autre partie d’assumer le même rôle (la protection contre le « confused deputy » qu’AWS recommande pour l’accès de tiers). La politique associée se limite entièrement aux opérations de lecture : Cost Explorer, Cost Optimization Hub, Compute Optimizer, EC2, RDS, Redshift, DynamoDB, S3, ElastiCache, CloudWatch, ECS, EKS et les services connexes, construite uniquement à partir des actions Describe*, Get*, List* et Export*. Aucune permission Put, Create, Delete ou Modify n’est jamais demandée.
Azure
Jetscale s’authentifie par l’entremise d’une inscription d’application (principal de service) dédiée que vous créez et contrôlez, à l’aide d’un certificat ou d’un secret client. L’accès est accordé par les rôles Azure intégrés : Lecteur, Lecteur de gestion des coûts et Lecteur de surveillance, limités au niveau de l’abonnement, ou par un rôle personnalisé facultatif pour les équipes qui souhaitent un contrôle encore plus serré. Ce rôle personnalisé exclut explicitement les actions sensibles comme lister ou régénérer les clés de compte de stockage, de sorte que même un identifiant compromis ne peut atteindre votre plan de données.
GCP
Les connexions Google Cloud suivent le même modèle : une identité dédiée en lecture seule, limitée aux données de coûts, de facturation et d’inventaire de ressources dont Jetscale a besoin, sans aucune permission pour modifier ou supprimer l’infrastructure.
