J'ai une fonction Lambda API REST déployée sur un sous-réseau privé, où le type de passerelle API est privé. Suite à ceci , j'ai défini jusqu'à un point de terminaison vpc vers une passerelle API privée vers les deux sous-réseaux publics du même vpc que le sous-réseau privé des fonctions lambda. Le groupe de sécurité correspondant du vpce autorise tout le trafic.
Si j'essaye d'interroger le point de terminaison d'API à partir d'une instance EC2 dans le sous-réseau public, j'obtiens l'erreur suivante:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-central-1:xxxxxxx:xxxxxx/*",
"Condition": {
"StringEquals": {
"aws:sourceVpce": "vpce-xxxxxxxx"
}
}
}
]
}
Je ne trouve pas le problème, car la politique de ressources de la passerelle API privée se présente comme suit:
anonymous is not authorized to perform: execute-api:Invoke on the resource.
Que me manque-t-il?
3 Réponses :
J'ai examiné les documents auxquels vous avez fourni des documents et ce que vous avez écrit. Je crois avoir trouvé la cause de votre problème d'accès.
Comme vous l'avez mentionné, vous avez créé une instance EC2 dans le sous-réseau public. Par défaut, ce sous-réseau aura une passerelle Internet disponible, donc en fait, votre point de terminaison VPC ne sera pas utilisé pour accéder à la passerelle API privée. Dans la documentation, ils disent également ce qui suit:
Pour souligner le caractère «privé» de cette API, testez-la à partir d'une ressource qui ne vit que dans votre VPC et n'a pas d'accès direct au réseau, au sens traditionnel du réseau.
En supposant que votre stratégie est correcte, que la région correcte est utilisée dans votre bloc de ressources et que votre identifiant de point de terminaison vpc est correct, il vous suffit de lancer une autre instance ec2 dans le sous-réseau privé. Ensuite, le processus suivant devrait fonctionner;
Merci pour votre réponse! J'essayais simplement ce que vous avez mentionné. Donc je ssh sur mon bastion Linux qui est dans le sous-réseau public, d'où je ssh sur une instance qui se trouve dans un sous-réseau privé. Pourtant, l'erreur demeure. Ce qu'il faut noter: Le lambda est déployé sur un sous-réseau privé différent car il s'agit uniquement pour les fonctions lambda en raison d'une plage d'adresses IP plus large pour l'évolutivité automatique.
Les deux dernières choses que je vérifierais alors sont; 1. Dans les sous-réseaux de configuration de point de terminaison de VPC, tous les sous-réseaux privés reçoivent un ticket, 2. Le groupe de sécurité utilisé permet un accès HTTPS au point de terminaison pour toute la plage d'adresses IP du VPC.
J'ai essayé quelques trucs, voici ma configuration actuelle qui ne fonctionne toujours pas: fonction lambda déployée sur deux sous-réseaux privés, le groupe de sécurité autorise tout le trafic entrant. Dans l'un des sous-réseaux privés, j'ai déployé une instance EC2, à partir de laquelle j'essaye d'appeler la fonction lambda. Le point de terminaison vpc est configuré avec les deux sous-réseaux privés et le groupe de sécurité autorise tout le trafic https entrant. Je suis très confus ... Je ne vois pas ce qui me manque?
@MC_ avait le même problème que l'OP, ça a fait l'affaire. Ce que j'essaie de comprendre, c'est que lorsque je suis entré dans la console de la passerelle API, cela me donne un lien pour accéder à l'API qui fonctionne. Mais quand j'essaye d'utiliser le dns VPCE, j'obtiens ceci: {"message": "Forbidden"}. Est-ce que tu sais pourquoi?
Pourriez-vous vérifier votre groupe de sécurité sur les points de terminaison de la passerelle API? Vous devez utiliser
Entrée: https source CIDR de votre vpc.
Outgress: tout le trafic, 0.0.0.0/0
J'ai trouvé que si vous utilisez sg- dans le sg (Ingress), cela ne fonctionnera pas. Après avoir changé en tant que CIDR, cela fonctionne maintenant. Je peux appeler cette API depuis la machine basion.
Ce qui a fonctionné pour moi: arn: aws: execute-api: eu-central-1: xxxxxxx: * / *
Si vous avez besoin, vous pouvez faire référence ici: github.com/imyoungyang/…
En fait, ce que @peterhack a dit était aussi la réponse pour moi. Le problème était d'utiliser le modèle fourni "Liste blanche VPC" avec tous les espaces réservés:
...xxx:/{{stageNameOrWildcard}}/{{httpVerbOrWildcard}}/{{resourcePathOrWildcard}}
le remplacement par ... xxx: * / * l'a corrigé