AWS
Jetscale se connecte au moyen d’un rôle IAM intercomptes plutôt que d’une clé d’accès partagée. Vous créez le rôle dans votre propre compte, puis Jetscale l’assume temporairement avec sts:AssumeRole, protégé par un External ID unique qui empêche toute autre partie d’assumer ce même rôle, soit la protection contre le « confused deputy » recommandée par AWS pour les accès de tiers. La politique associée est entièrement limitée aux opérations de lecture dans Cost Explorer, Cost Optimization Hub, Compute Optimizer, EC2, RDS, Redshift, DynamoDB, S3, ElastiCache, CloudWatch, ECS, EKS et les services connexes. Elle repose uniquement sur les actions Describe*, Get*, List* et Export*. Aucune autorisation Put, Create, Delete ou Modify n’est jamais demandée.
Azure
Jetscale s’authentifie au moyen d’une App Registration dédiée (service principal) que vous créez et contrôlez, avec un certificat ou un client secret. L’accès est accordé par les rôles Azure intégrés Reader, Cost Management Reader et Monitoring Reader, à l’échelle de l’abonnement, ou par un rôle personnalisé facultatif pour les équipes qui souhaitent un contrôle encore plus strict. Ce rôle personnalisé exclut explicitement les actions sensibles, comme l’affichage ou la régénération des clés de comptes de stockage. Même des justificatifs compromis ne peuvent donc pas 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 des ressources dont Jetscale a besoin, sans autorisation de modifier ou de supprimer l’infrastructure.