Accéder aux API privées et publiques depuis un VPC via API Gateway

Nom de domaine API Gateway

Le nom de domaine API Gateway est un endpoint géré par AWS, créé lors de la configuration du nom de domaine personnalisé de votre API. Il s'agit d'un alias de l'endpoint par défaut de votre API apiID.execute-api.REGION.amazonaws.com, qui assure la terminaison TLS et fournit des URL conviviales.

Voici son fonctionnement :

1. Structure du nom de domaine API Gateway pour les deux types d'endpoints d'API publiques

• Edge-Optimized :

Utilise une distribution CloudFront (par exemple, d123.cloudfront.net) pour un accès global à faible latence.

• Regional :

Utilise un endpoint propre à la région (par exemple, d-abc123.execute-api.us-east-1.amazonaws.com).

2. Configuration DNS

• Votre fournisseur DNS (par exemple, GoDaddy) :

Vous créez un enregistrement CNAME qui fait pointer votre nom de domaine personnalisé (api.mydomain.com) vers le nom de domaine API Gateway (par exemple, d-abc123.execute-api.us-east-1.amazonaws.com).

• Exemple d'enregistrement DNS GoDaddy :

Nom : api.mydomain.com

Type : CNAME

Valeur : d-abc123.execute-api.us-east-1.amazonaws.com

• Cet enregistrement garantit que le trafic à destination de api.mydomain.com est routé vers l'endpoint d'API Gateway.

3. Association du certificat

• Certificat AWS Certificate Manager (ACM) :

Lorsque vous définissez un nom de domaine personnalisé dans API Gateway, vous l'associez à un certificat ACM (par exemple, *.mydomain.com).

• Le Subject Alternative Name (SAN) du certificat doit inclure votre nom de domaine personnalisé (par exemple, api.mydomain.com, ou le wildcard de niveau supérieur *.mydomain.com).
• API Gateway s'appuie sur ce certificat pour la terminaison TLS au niveau de sa couche edge.

4. Le tout en action — le flux de requête

• Un client envoie une requête à https://api.mydomain.com.
• Le DNS résout vers le nom de domaine API Gateway (par exemple, d-abc123.execute-api.us-east-1.amazonaws.com).
• Le DNS d'AWS résout le nom de domaine API Gateway vers les IP publiques du service AWS Gateway, qui assure la terminaison TLS (avec votre certificat ACM) et l'équilibrage de charge de votre trafic.
• Le service API Gateway appelle l'API et le Stage auxquels vous avez mappé votre nom de domaine personnalisé.

Au cœur du problème se trouve le VPC Endpoint API Gateway nécessaire pour accéder aux API privées. Lorsque le Private DNS est activé sur ce VPC Endpoint, des complications peuvent survenir lors de l'accès aux API publiques. Concrètement, les appels aux API publiques peuvent échouer en raison de problèmes de certificat SSL. Pour bien comprendre, il faut saisir le fonctionnement de la résolution DNS dans cette architecture (voir l'Annexe A).

Une API publique sans nom de domaine personnalisé n'a qu'une URL d'endpoint publique, accessible à toute personne sur Internet.

Comme les API publiques ne peuvent être invoquées que depuis Internet, appeler cette URL depuis un VPC dont le VPC Endpoint API Gateway a Private DNS activé tentera d'invoquer l'API depuis le VPC plutôt que depuis Internet, et renverra une erreur HTTP 403 (forbidden).

Les API publiques exigent un certificat lorsqu'elles sont mappées à un nom de domaine personnalisé.

Lorsque vous créez un enregistrement Alias de type A dans Route 53 pour invoquer votre API publique via votre nom de domaine personnalisé, vous pouvez appeler des API privées et publiques depuis votre VPC, même lorsqu'un VPC Endpoint API Gateway avec Private DNS est configuré.

Si vous hébergez votre domaine chez un fournisseur externe, vous pouvez créer un enregistrement CNAME dans le DNS externe.

Cet enregistrement CNAME est précisément la source du problème.

Lorsque vous appelez une API publique avec un nom de domaine personnalisé, une recherche DNS est déclenchée pour trouver l'enregistrement qui fait correspondre ce nom au nom de domaine API Gateway. Une seconde recherche DNS est ensuite nécessaire pour obtenir l'adresse IP du nom de domaine API Gateway renvoyé par la première.

Sans Private DNS activé, la recherche renverra l'IP publique de votre API publique, ce qui est le comportement attendu.

Cette IP publique appartient au service AWS Gateway, qui ira chercher votre nom de domaine personnalisé dans un Subject Alternative Name (SAN) du certificat associé. Comme le certificat de votre nom de domaine personnalisé (par exemple, mydomain.com) a été associé au nom de domaine API Gateway, le handshake SSL aboutira et votre API publique sera invoquée.

Lorsqu'un VPC dispose d'un VPC Endpoint API Gateway avec Private DNS activé, ce Private DNS interceptera la recherche du nom de domaine API Gateway (puisqu'il intercepte tous les sous-domaines de execute-api.REGION.amazonaws.com) et renverra l'IP privée attribuée à l'Elastic Network Interface (ENI) du VPC Endpoint.

Cette IP privée correspond à l'adresse du service API Gateway, qui n'acceptera que des endpoints d'URL internes appartenant à l'URL d'endpoint d'une API privée, au format apiID.execute-api.REGION.amazonaws.com.

Le résultat ressemble à ceci :

Résultat de l'appel d'une API publique en présence d'un VPC Endpoint API Gateway avec Private DNS activé

Conséquence : toute tentative d'invocation de l'API publique depuis le VPC se solde par un échec du handshake SSL, et la connexion est bloquée.

Comme expliqué plus haut, lorsqu'un VPC Endpoint pour API Gateway a Private DNS activé, toutes les recherches DNS pour execute-api.REGION.amazonaws.com résolvent vers des IP privées, ce qui fait échouer la validation SSL des appels d'API publiques (qui passent par des noms de domaine personnalisés). La solution repose sur la priorisation DNS via les zones hébergées privées Route 53, aussi appelée Split-Horizon / Split-View DNS.

L'idée : avec une zone hébergée privée (PHZ), les recherches DNS effectuées depuis le VPC consultent la PHZ avant tout autre serveur DNS public.

Imaginons un serveur DNS GoDaddy qui héberge notre domaine au niveau supérieur : mydomain.com.

Si nous mappons api.mydomain.com à notre API publique, nous hébergerons ce sous-domaine dans notre DNS PHZ pour mettre en place le split-view DNS.

Ainsi, les recherches pour api.mydomain.com en provenance de notre VPC seront servies depuis notre PHZ, tandis que les appels vers d'autres sous-domaines qui n'utilisent pas API Gateway (par exemple, pointant vers un autre service que le VPC Endpoint n'intercepte pas) passeront par le DNS public.

Cette solution s'appuie sur trois concepts clés :

1. VPC Endpoint : pour l'accès aux API privées (Private DNS activé)
2. Zone hébergée privée : pour mettre en place le split-view DNS
3. Un enregistrement Alias de type A dans la PHZ : pour diriger le trafic vers le nom de domaine API Gateway public

Prérequis

• Une API Gateway publique avec un nom de domaine personnalisé hébergé en dehors de Route 53 et accessible depuis Internet, ou un nom de domaine personnalisé public hébergé dans Route 53 mais qui pointe via un enregistrement CNAME plutôt qu'un enregistrement Alias de type A.
• Un VPC Endpoint API Gateway avec Private DNS activé, défini dans le VPC depuis lequel nous souhaitons appeler notre API publique.

Si vous disposez déjà de ce VPC Endpoint, passez directement à l'étape 2 ci-dessous.

Sans cela, vous ne pourrez pas appeler les API privées.

1. Configurer un VPC Endpoint pour API Gateway afin d'accéder aux API privées

Si vous disposez déjà de cet endpoint, passez à l'étape " 2 ".

• Dans la console AWS, rendez-vous dans Console VPC > Endpoints.
• Créez un endpoint d'interface pour com.amazonaws.REGION.execute-api.
• Activez Private DNS (paramètre par défaut).
• Attachez un groupe de sécurité autorisant le trafic HTTPS entrant (port 443) depuis le VPC (ou depuis les IP des ressources spécifiques de votre VPC auxquelles vous voulez permettre d'appeler des API privées d'API Gateway).

2. Créer une zone hébergée privée

• Créez une PHZ dans la console Route 53 correspondant au chemin du nom de domaine personnalisé public de votre API (par exemple, api.mydomain.com).

Notez que si votre domaine public comporte des URL que vous souhaitez appeler mais qui ne sont pas mappées à une API Gateway (par exemple, si dev.mydomain.com pointe vers un Load Balancer et non vers API Gateway), vous devez utiliser le nom de domaine personnalisé complet de votre API (tel que api.mydomain.com) comme nom de domaine de votre zone hébergée privée.

Si tous les sous-domaines de votre domaine sont mappés à des API d'API Gateway, utilisez le niveau supérieur mydomain.com comme nom de domaine.

• Associez la zone à votre VPC.

Créez une PHZ pour votre nom de domaine personnalisé et associez-la au VPC qui doit accéder à ce domaine

3. Configurer les enregistrements DNS

• Vous devez créer un Alias de type A pour chaque domaine utilisé par une API.

Par exemple, si vous avez api.mydomain.com et special-api.mydomain.com, vous devez créer un enregistrement pour chacun : un pour api et un autre pour special-api. Choisissez donc le type d'enregistrement " A ".

• Pour le nom de l'enregistrement :

- Si le nom de votre nom de domaine personnalisé est identique au nom de domaine complet de votre API, ne saisissez pas le sous-domaine (ne tapez pas " api ") dans " Record Name " (laissez le champ vide). Par exemple, si vous avez créé la PHZ pour api.mydomain.com car c'est le seul sous-domaine utilisé avec API Gateway, laissez le champ Record Name vide.

- Si vous utilisez le niveau supérieur — mydomain.com, parce que plusieurs sous-domaines sont mappés à API Gateway, saisissez le nom de votre api dans " Record Name " pour chaque enregistrement. Par exemple, saisissez " api " pour un enregistrement et " special-api " pour un autre.

• Définissez-le comme un enregistrement Alias en cochant la case " alias ".
• Choisissez " Alias to API Gateway API ".
• Sélectionnez la région de votre API.
• Sélectionnez l'endpoint régional (le nom de domaine API Gateway créé pour votre nom de domaine personnalisé) de votre API publique.

Il porte un nom du type :

d-abc123.execute-api.REGION.amazonaws.com

• Si vous ne le voyez pas, copiez-le depuis la console API Gateway, sous " custom domain names " -> API Gateway domain name.
• Enregistrez l'enregistrement.

Route 53 peut prendre un peu de temps avant que votre nouvelle zone hébergée privée soit disponible pour votre VPC.

Voir l'Annexe B pour l'architecture de cette solution.

Vous aurez besoin d'une instance EC2 fonctionnant dans votre VPC, avec une connexion Internet pour les API publiques.

Connectez-vous à votre instance EC2 puis, après avoir remplacé l'URL ci-dessous par la vôtre, exécutez :

curl -v https://your-public-api.yourdomain.com/your-path

Vous devriez obtenir une sortie similaire à celle-ci :

Notez qu'avant la création et la configuration de la PHZ, le Private DNS (associé au VPC Endpoint API Gateway) renvoyait une IP privée pour le nom de domaine personnalisé (c'était 10.0.3.79), correspondant à l'ENI du VPC Endpoint. Avec une PHZ pour le nom de domaine personnalisé, nous obtenons désormais les IP publiques du nom de domaine API Gateway, qui (dans cet exemple) sont :

IPv4: 44.221.197.141, 34.192.177.183, 34.232.190.93

Pour travailler à la fois avec des API privées et publiques, désactivez le Private DNS associé à votre VPC Endpoint API Gateway. Créez ensuite une PHZ nommée execute-api.REGION.amazonaws.com et associez-la à tous les VPC auxquels vous prévoyez d'accorder l'accès au VPC qui héberge vos API privées. (Note : associer cette PHZ à un VPC d'une autre région relève de la partie " Bonus " de cet article.)

Vous créez un enregistrement wildcard pour intercepter tous les API-IDs d'API Gateway, comme :

Créez la zone hébergée pour les API privées dans cette région

Vous allez maintenant créer un enregistrement " catch-all " qui pointera vers le DNS du VPC Endpoint, comme :

Créez un enregistrement catch-all pour toutes les API privées de cette région

Cela garantit que toutes les URL d'une API Gateway privée définie dans us-east-1 seront interceptées par cette PHZ et renverront l'adresse IP privée du VPC Endpoint API Gateway.

Pour les API publiques avec un nom de domaine personnalisé, nous avons vu que la création d'une PHZ pour ce nom de domaine résout le problème.

Pour les API publiques sans nom de domaine personnalisé, il faut ajouter un enregistrement Alias en utilisant l'API ID de l'API et en le faisant pointer vers l'URL publique.

Prenons un exemple : supposons que nous ayons une API publique dans us-east-1 dont l'URL est bmf11pk5je.execute-api.us-east-1.amazonaws.com.

Si nous l'appelons depuis le VPC, elle renverra " Forbidden (403) ", comme expliqué plus haut pour le scénario du nom de domaine personnalisé. Pour résoudre ce problème, nous ajoutons un enregistrement nommé " bmf11pk5je " et le faisons pointer vers l'URL d'invocation, comme suit :

Nous pourrons désormais appeler depuis le VPC l'API publique définie dans cet enregistrement. Chaque API publique supplémentaire à appeler dans cette région nécessitera l'ajout d'un enregistrement Alias, comme nous venons de le faire.

Appeler une API privée hébergée dans une région donnée depuis un VPC situé dans une autre région AWS.

Le problème

Les API privées peuvent être facilement partagées entre plusieurs VPC d'une même région. Il suffit d'avoir des VPC Endpoints API Gateway dans chaque VPC, une politique de ressources pour votre API privée autorisant l'accès depuis ces VPC, et d'ajouter les VPC Endpoints à l'API privée (via ses paramètres d'API).

Cela ne fonctionne pas si votre VPC se trouve dans une région différente de celle qui héberge l'API privée.

Dans ce cas, voici la marche à suivre :

1. Établir un peering entre les deux VPC : celui qui héberge l'API privée et celui auquel vous souhaitez donner accès.

Pour le peering VPC, vous devez vous assurer que les deux VPC n'ont pas de blocs CIDR qui se chevauchent. 2. Si vous n'avez pas de zone hébergée privée pour la région API Gateway hébergeant votre API privée, créez-en une. 3. Le nom de la zone hébergée privée (PHZ) doit être :

execute-api.REGION.amazonaws.com 4. Vous devez associer cette PHZ au VPC Endpoint API Gateway de la région ainsi qu'au VPC auquel vous souhaitez accorder l'accès. 5. Ajoutez un enregistrement Alias de type A à la PHZ (définissez-le comme alias en cochant la case " alias "), puis sélectionnez " Alias to VPC Endpoint " dans le menu déroulant. 6. Sélectionnez la région du VPC auquel vous souhaitez donner accès. 7. Choisissez le VPC Endpoint pour l'API Gateway dans ce VPC. 8. Ajoutez le bloc CIDR du VPC peered au groupe de sécurité du VPC Endpoint. Sans cela, la communication depuis le VPC peered sera bloquée. 9. Enregistrez l'enregistrement.

Une fois ces étapes réalisées, vous pouvez invoquer l'API privée depuis le VPC de l'autre région.

Notez qu'avec le peering VPC, la politique de ressources de votre API Gateway privée n'a pas besoin d'autoriser le trafic provenant du VPC peered ; elle doit uniquement autoriser le VPC principal dans lequel l'API est déployée. Cela s'explique par le fait que la communication vers l'API Gateway proviendra du VPC Endpoint situé dans son propre VPC, même si elle a pour origine le VPC peered.

Ce peering inter-régions provoquera le même problème d'échec de certification SSL si vous tentez d'accéder à une API publique définie dans le même VPC que l'API privée. Bien qu'elle soit dans une autre région, elle reste associée à une PHZ pour execute-api.REGION (REGION où l'API est déployée) et tentera donc d'appeler l'IP privée du VPC Endpoint, à moins qu'une PHZ pour votre API publique ne soit définie.

Si vous voulez appeler à la fois des API privées et publiques, en inter-régions ou non, suivez les instructions de la première partie de cet article.

Le diagramme ci-dessous montre ce qui se passe lorsqu'une instance EC2 appelle une API Gateway publique avec un VPC Endpoint API Gateway dont Private DNS est activé.

Appel d'une API publique depuis un VPC sans PHZ en place

1. EC2 tente d'appeler https://api.mydomain.com , ce qui déclenche une recherche DNS.
2. La réponse du DNS est le nom de domaine API Gateway.
3. Une seconde recherche DNS est effectuée, et elle est interceptée par le Private DNS associé au VPC Endpoint API Gateway.
4. Il renvoie l'adresse IP privée du VPC Endpoint.
5. EC2 tente d'invoquer l'API via cette adresse IP privée.
6. Le service API Gateway, joignable via l'adresse IP privée, fournit un certificat valide pour *.execute-api.REGION.amazonaws.com et non pour api.mydomain.com ; une erreur de certificat est donc renvoyée.

Le diagramme ci-dessous montre ce qui se passe lorsqu'une instance EC2 appelle une API Gateway publique avec un VPC Endpoint API Gateway dont Private DNS est activé. Cette fois, une zone hébergée privée est également définie pour le nom de domaine personnalisé.

Appel d'API publiques depuis un VPC avec une PHZ en place

Appel de l'API publique depuis Internet

1. Une recherche DNS est effectuée auprès du service d'hébergement de domaine externe (par exemple, GoDaddy) pour le nom de domaine personnalisé de l'API (par exemple, api.mydomain.com).
2. La requête renvoie le nom de domaine API Gateway correspondant à ce nom de domaine personnalisé.
3. Le nom de domaine API Gateway est interrogé dans Route 53 d'AWS.
4. La réponse renvoie une adresse IP publique pour le service API Gateway public.
5. L'IP publique est utilisée pour appeler le service API Gateway et, comme il est associé aux certificats api.mydomain.com, il termine le SSL et appelle la cible pertinente du stage de l'API Gateway.

Appel d'une API privée depuis le VPC

6. Les API privées disposent d'une URL au format apiID.execute-api.REGION.amazonaws.com. Lorsqu'une telle URL est appelée depuis un VPC dont le VPC Endpoint pour API Gateway a Private DNS actif, la requête est gérée par ce Private DNS.

7. Le Private DNS renvoie l'IP privée de l'ENI du VPC Endpoint API Gateway.

8. Le service API Gateway joignable via cette IP privée dispose d'un certificat pour *.execute-api.REGION.amazonaws.com ; l'appel d'API privée passé via cette URL est donc authentifié et transféré vers la cible de l'API privée.

Appel d'une API API Gateway publique depuis le VPC

9. Le DNS de la zone hébergée privée créée pour le nom de domaine personnalisé capture et traite les requêtes qui relèvent de son nom de domaine.

10. La PHZ, qui contient un enregistrement Alias de type A, renvoie l'IP publique du nom de domaine API Gateway associé au nom de domaine personnalisé.

11. L'IP publique est appelée via l'Internet Gateway, ce qui permet d'atteindre l'adresse du service de l'API Gateway. Comme le service joignable depuis l'IP publique dispose bien de l'association de certificat entre le nom de domaine personnalisé et le nom de domaine API, le handshake SSL aboutit et le TLS est terminé. La requête est transférée à la cible du stage pertinent de l'API publique d'API Gateway.

J'espère que cet article vous aura apporté des éclairages utiles. Si vous souhaitez en savoir plus ou si nos services vous intéressent, n'hésitez pas à nous contacter. Vous pouvez nous joindre ici.

• API Gateway Custom Domain Names
• API endpoint types for REST APIs in API Gateway
• Working with private hosted zones
• AWS Route 53 Split View DNS
• Choosing between alias and non-alias records

Contient une bonne explication des enregistrements alias dans Route 53.