2
votes

Comment autoriser un rôle à exécuter "execute-api: Invoke"?

J'essaie de déplacer une suite de tests de bout en bout afin qu'ils soient entièrement contenus dans AWS. J'ai fait cela via la construction de code et j'ai tout mis en marche jusqu'au point d'exécuter les tests, qui invoquent une API pour réinitialiser la base de données avant chaque test. Je continue de rencontrer ce message d'erreur lorsque le premier test tente de s'exécuter.

"requestId": "********-82f8-11e9-a732-0b550cf3fcd6",
"ip": "*.*.*.*",
"caller": "-",
"user": "-",
"requestTime": "30/May/2019:16:32:50 +0000",
"httpMethod": "GET",
"resourcePath": "/*/ref-data/{proxy+}", "status": "403", "protocol": "HTTP/1.1", "responseLength": "185"

Au début, je pensais que l'erreur était causée par un manque d'autorisations sur le rôle qui était utilisé pour tout construire. J'ai essayé d'ajouter les autorisations appropriées au rôle IAM utilisé, les rendant éventuellement plus ouverts que je ne le souhaiterais.

"Effect": "Allow",
"Action": [
    "execute-api:Invoke",
    "execute-api:ManageConnections"
],
"Resource": "arn:aws:execute-api:*:*:*"

Évidemment, je n'ai pas résolu les choses, mais j'ai remarqué que le conseiller d'accès montre que la politique particulière n'est pas consultée.

Ensuite, je est entré dans la stratégie de ressources dans API Gateway pour voir s'il y avait quelque chose là-bas. J'ai supprimé certaines conditions d'adresse IP qui avaient été définies pour restreindre l'accès aux adresses IP du bureau.

J'ai regardé à l'intérieur de WAF et Shield et je ne vois rien qui serait lié à l'appel de l'API. À ce stade, je ne sais plus où doit commencer ma prochaine enquête.

Modifier

Voici la réponse que je ' Je reviens.

StatusCodeError: 403 - "{\"Message\":\"User: anonymous is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:eu-west-2:*:*"}" 


1 commentaires

Avez-vous configuré un autorisateur?


3 Réponses :


0
votes

La politique de votre rôle qui autorise execute-api: Invoke semble être correcte, mais le message d'erreur que vous avez fourni indique User: anonyme n'est pas autorisé à effectuer ... . Si vous vous attendez à ce que votre rôle tente cette action, c'est que quelque chose ne va pas, car vous avez tenté l'action avec un utilisateur nommé anonyme .

Le rôle que vous utilisez pour construire votre pile n'est pas nécessairement le rôle utilisé pour exécuter des fonctions sur cette pile. Je vous recommande de vérifier toutes vos entités IAM tout au long et d'identifier et de comprendre clairement ce que chacune tente de faire. Assurez-vous que tout ce qui appelle votre fonction est en fait le rôle que vous voulez avec la politique correcte attachée.

J'espère que cela vous aidera!


0 commentaires

1
votes

Voici les étapes à suivre.

  1. Pour la méthode API - Make Auth = IAM
  2. Pour la politique de ressources API, assurez-vous d'autoriser le trafic provenant du rôle IAM sélectionné pour des méthodes spécifiques / toutes

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::###############:role/###########"
            },
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:ap-southeast-1:###########:/#########/*/POST/####/####/"
        }
    ]
    

    }

  3. Assurez-vous que le même rôle IAM est associé aux entités à partir desquelles cette API est appelée, par exemple EC2 - si votre code réside sur EC2

  4. Assurez-vous que vos appels d'API ne sont pas des appels curl simples, ils sont signés aws sigv4

J'espère que cela fonctionne!


0 commentaires

1
votes

Dans ce cas, il s'est avéré que le principal bloqueur était les restrictions IP de la passerelle API définies dans la politique. Je ne savais pas que les modifications apportées ne prenaient effet qu'au (re) déploiement. Une fois que j'ai fait cela avec les restrictions IP mises à jour, le point de terminaison de l'API pourrait être invoqué.


0 commentaires