Une intégration de service AWS permet à API Gateway d'appeler directement un service AWS backend, et elle le fait avec un rôle de crédentiels d'intégration (credentials sur l'intégration). Quiconque peut invoquer la route atteint ce service en tant que rôle, et quiconque peut définir ou modifier une intégration peut la pointer vers n'importe quel service et y attacher n'importe quel rôle transmissible, transformant la gateway en un proxy qui agit avec les permissions du rôle.
Lire l'intégration#
aws apigateway get-integration --rest-api-id <id> --resource-id <rid> \
--http-method <m> --query '[type,credentials,uri]'
Une valeur credentials qui est un ARN de rôle (et non arn:aws:iam::*:user/*) correspond au rôle d'intégration ; uri indique quelle action de service la route proxifie.
Repointer une intégration que vous pouvez modifier#
aws apigateway put-integration --rest-api-id <id> --resource-id <rid> \
--http-method <m> --type AWS --integration-http-method POST \
--uri 'arn:aws:apigateway:<region>:<service>:action/<Action>' \
--credentials arn:aws:iam::<acct>:role/<privileged-role>
aws apigateway create-deployment --rest-api-id <id> --stage-name <stage>
Notes d'exploitation#
- Définir une intégration avec
--credentialsexigeiam:PassRolesur ce rôle, ce qui en fait aussi un chemin d'escalade PassRole limité à API Gateway. - Une route qui proxifie déjà un service sensible (par exemple
states:StartExecutionous3:GetObject) est exploitable par simple invocation, sans aucune modification. - Redéployez le stage après avoir modifié une intégration, faute de quoi le changement ne prend pas effet.
Outils#
- AWS CLI (
apigateway get-integration,put-integration,create-deployment) : lire et repointer.