Restreindre le trafic entrant aux applications et aux fonctions à l'aide de restrictions basées sur le contexte

Vous pouvez utiliser IBM Cloud® context-based restrictions (CBR) pour contrôler le trafic réseau entrant vers vos applications et fonctions IBM Cloud® Code Engine. Avec CBR, vous pouvez restreindre l'accès via des points d'extrémité privés, des points d'extrémité publics ou les deux, offrant ainsi une sécurité flexible au niveau du réseau pour vos charges de travail. Au lieu d'attribuer l'accès sur la base de l'identité, les restrictions basées sur le contexte vérifient qu'une demande d'accès provient d'un contexte autorisé que vous configurez. Vous pouvez limiter le trafic entrant vers vos applications et fonctions au sein de vos projets Code Engine afin de protéger vos projets contre le trafic entrant indésirable. Ces restrictions contextuelles s'appliquent au niveau du compte, du projet, du groupe de ressources ou de la localisation (région) et s'appliquent à toutes les applications et fonctions concernées par la restriction.

Les restrictions basées sur le contexte pour les applications et les fonctions de Code Engine prennent en charge les cas d'utilisation suivants :

Bloquer entièrement les entrées publiques: Limitez l'accès à vos applications et fonctions à leur point d'extrémité privé via CBR. Cette approche élimine la nécessité de configurer les paramètres de visibilité des applications, puisque l'accès public est bloqué au niveau du réseau. Vos charges de travail restent accessibles à partir de réseaux privés (tels que les VPC) et d'autres composants Code Engine au sein du même projet.
Bloquer l'accès public et restreindre l'accès privé par IP: contrôlez au maximum le trafic entrant en bloquant tous les accès publics à l'internet et en restreignant l'accès privé à des adresses IP ou à des zones de réseau spécifiques. Cela permet de combiner les restrictions basées sur l'IP pour les terminaux privés avec la possibilité de bloquer entièrement les terminaux publics au niveau du réseau.
Isolez entièrement les charges de travail: Bloquez les points d'extrémité privés et publics pour isoler complètement vos applications et fonctions au niveau du réseau. Ce cas d'utilisation est idéal pour des scénarios tels que les charges de travail de traitement par lots qui ne doivent établir que des connexions sortantes, les microservices internes qui communiquent exclusivement par l'intermédiaire de files d'attente de messages ou d'abonnements à des événements, ou les charges de travail en cours de maintenance pour lesquelles vous souhaitez empêcher temporairement tout trafic entrant tout en maintenant le déploiement de l'application.

Les restrictions basées sur le contexte ne s'appliquent qu'aux applications et aux fonctions, car ces charges de travail exposent les points d'extrémité du réseau. Les restrictions basées sur le contexte ne s'appliquent pas aux emplois et aux flottes puisqu'ils n'exposent aucun point d'extrémité du réseau.

Lorsque vous sécurisez les ressources Code Engine avec des restrictions basées sur le contexte, en plus de restreindre le trafic entrant qui se connecte à vos applications ou fonctions avec des règles basées sur le contexte, vous pouvez restreindre les contextes(chemins de réseau)à partir desquels vos ressources Code Engine peuvent être gérées, comme le déploiement ou la mise à jour d'applications et de secrets.

Les restrictions contextuelles pour Code Engine peuvent être limitées à un seul projet, à un groupe de ressources entier ou à un lieu (région). Pour plus d'informations sur les restrictions basées sur le contexte d' IBM Cloud, consultez la section « Sécurité multicouche avec restrictions basées sur le contexte ».

Lorsqu'une règle de restriction contextuelle couvre un groupe de ressources ou une localisation (région), les restrictions s'appliquent aux projets existants. Si vous créez un nouveau projet dans le même emplacement ou groupe de ressources, les restrictions sont automatiquement appliquées au nouveau projet. Quelques minutes peuvent être nécessaires pour que le nouveau projet soit associé aux restrictions. Pour observer l'application des règles CBR, vérifiez la section de connectivité de l'état du projet dans l'interface utilisateur, la CLI ou l'API.

Créer une restriction contextuelle pour vos ressources Code Engine

Vous pouvez créer des restrictions basées sur le contexte pour vos ressources Code Engine en utilisant la console IBM Cloud, le CLI, l'API, les SDK ou Terraform. Pour plus d'informations sur la création de restrictions basées sur le contexte, voir Création de restrictions basées sur le contexte. Les sections suivantes fournissent des conseils spécifiques pour la création de restrictions pour les applications et les fonctions de Code Engine.

IPv6 ne sont pas prises en charge pour Code Engine.

Ajouter une restriction contextuelle à l'aide de la console

Pour créer une restriction basée sur le contexte, voir Création de restrictions basées sur le contexte. Les étapes suivantes sont spécifiques à la création d'une ressource pour Code Engine.

Accédez à la page Règles de restriction basées sur le contexte.
Cliquez sur Créer pour créer une nouvelle règle pour la restriction basée sur le contexte, en commençant par le service.
Sélectionnez Code Engine pour Services et cliquez sur Suivant pour sélectionner les API de service à protéger.
Restreignez l'accès pour protéger vos charges de travail d'application ou de fonction Code Engine en sélectionnant l'option Plan de données pour les API de service.

Vous définissez les restrictions de charge de travail au niveau du plan de données, donc sélectionnez au moins le service du plan de données. Vous pouvez également sélectionner d'autres services ou plateformes API.

Cliquez sur Suivant pour définir la restriction pour vos ressources.
Appliquez la restriction à un seul projet, à l'ensemble du groupe de ressources ou à un emplacement (région) où vous avez plusieurs projets. Appliquez ce champ d'application dans la section Ressources et cliquez sur Réviser pour continuer.
Cliquez sur Continuer pour ajouter un contexte à votre règle.
Configurer les contextes pour définir les points d'extrémité soumis à des restrictions. Choisissez l'un des scénarios suivants en fonction de vos exigences en matière de sécurité :
- Cas d'utilisation A : bloquer entièrement les flux entrants publics
  
  Utilisez ce cas d'utilisation pour rendre vos applications et fonctions accessibles uniquement via leur point d'extrémité privé, en éliminant l'accès public à l'internet au niveau du réseau.
  1. Activez les points de terminaison.
  2. Sélectionnez Privé (autoriser le trafic).
  3. Laisser Public désélectionné (bloquer le trafic).
  4. Laissez les zones de réseau vides. Veillez à ce qu'aucune zone réseau ne soit activée dans cette section afin que tous les points d'extrémité privés restent accessibles.
  5. Cliquez sur Ajouter pour créer un nouveau contexte.
- Cas d'utilisation B : bloquer le public et restreindre le privé par IP
  
  Ce cas d'utilisation permet d'obtenir un contrôle maximal en bloquant tous les accès publics à l'internet et en limitant l'accès des terminaux privés à des adresses IP ou à des zones de réseau spécifiques.
  1. Activez les points de terminaison.
  2. Sélectionnez Privé (autoriser le trafic).
  3. Laisser Public désélectionné (bloquer le trafic).
  4. Sélectionnez les zones du réseau que vous souhaitez autoriser en accès privé (par exemple, des VPC ou des plages d'adresses IP spécifiques).
  5. Cliquez sur Ajouter pour créer un nouveau contexte.
- Cas d'utilisation C : isoler entièrement les charges de travail
  
  Utilisez ce cas d'utilisation pour isoler complètement vos applications et fonctions au niveau du réseau en bloquant les points d'extrémité privés et publics. Cela est utile pour les charges de travail de traitement par lots qui n'établissent que des connexions sortantes, les microservices internes qui communiquent exclusivement par l'intermédiaire de files de messages ou d'événements, ou les charges de travail qui font l'objet d'une maintenance.
  1. Laissez les points de terminaison désactivés (n'ajoutez aucun contexte de point de terminaison).
  2. Cliquez sur Continuer sans ajouter de contexte.
  La console affiche l'avertissement suivant avant que vous ne validiez :
  
  Aucun contexte ajouté. Votre règle sera appliquée sans contexte, ce qui se traduit par une règle totalement restrictive qui bloque tous les accès. Cela est utile lorsque vous souhaitez protéger vos ressources et que vous n'êtes pas certain de l'accès à autoriser. Voulez-vous continuer ?
  
  Remarque : cette règle doit être supprimée, désactivée ou mise à jour avec au moins un contexte pour permettre l'accès à vos ressources.
  
  Confirmez pour enregistrer la règle. Une règle sans contexte refuse tout accès entrant au projet.
Cliquez sur Continuer pour fournir les détails de la règle.
Fournissez une description de votre règle.
Sélectionnez Activé pour l'application.
Vérifiez le résumé, puis cliquez sur Créer.

Ajouter une restriction contextuelle à l'aide de l'interface de programmation

Vous pouvez utiliser le CLI de IBM Cloud pour créer des restrictions basées sur le contexte pour vos ressources Code Engine. Avant de commencer, assurez-vous que le CLI IBM Cloud est installé et que le plug-in de restrictions basées sur le contexte est installé en exécutant ibmcloud plugin install cbr.

Les règles de restriction basées sur le contexte peuvent s'appliquer à un seul projet, à un groupe de ressources entier, à un emplacement (région) ou à l'ensemble du compte. L'indicateur --service-instance figurant dans les exemples limite la portée de la règle à un projet spécifique. Pour limiter la portée à un groupe de ressources, utilisez --resource-group-id <resource-group-id>. Pour limiter la recherche à un emplacement (région), utilisez --resource-attributes "region=<region>". Pour appliquer la règle à l'ensemble du compte, omettez les trois indicateurs.

Les exemples suivants limitent l'application de cette règle à un seul projet nommé my-project. Pour trouver l'identifiant de votre projet, exécutez ibmcloud ce project get --name my-project --output json | grep guid. Pour limiter la portée à un groupe de ressources, remplacez par --service-instance my-project-id --resource-group-id <resource-group-id>. Pour limiter la portée à un emplacement (région), remplacez-le par --resource-attributes "region=<region>". Pour appliquer la règle à l'ensemble du compte, omettez complètement l'indicateur.

Cas d'utilisation A : bloquer entièrement les flux entrants publics

Utilisez ce cas d'utilisation pour rendre vos applications et fonctions accessibles uniquement via leur point d'extrémité privé, en éliminant l'accès public à l'internet au niveau du réseau.

Créez une règle qui autorise l'accès privé et bloque l'accès public :
```
ibmcloud cbr rule-create --description "Block public inbound entirely" \
--service-name codeengine \
--service-instance my-project-id \
--api-types crn:v1:bluemix:public:context-based-restrictions::::api-type:data-plane \
--context-attributes endpointType=private
```
Cas d'utilisation B : bloquer le public et restreindre le privé par IP

Ce cas d'utilisation permet d'obtenir un contrôle maximal en bloquant tous les accès publics à l'internet et en limitant l'accès des terminaux privés à des adresses IP ou à des zones de réseau spécifiques. Pour connaître les identifiants de zone disponibles, exécutez ibmcloud cbr zones.

Créez une règle qui limite l'accès privé à des zones spécifiques et bloque l'accès public :
```
ibmcloud cbr rule-create --description "Block public and restrict private by IP" \
--service-name codeengine \
--service-instance my-project-id \
--api-types crn:v1:bluemix:public:context-based-restrictions::::api-type:data-plane \
--context-attributes endpointType=private,networkZoneId=<zone-id>
```
Cas d'utilisation C : isoler entièrement les charges de travail

Utilisez ce cas d'utilisation pour isoler complètement vos applications et fonctions au niveau du réseau en bloquant les points d'extrémité privés et publics. Cela est utile pour les charges de travail de traitement par lots qui n'établissent que des connexions sortantes, les microservices internes qui communiquent exclusivement par l'intermédiaire de files de messages ou d'événements, ou les charges de travail qui font l'objet d'une maintenance.

Pour bloquer tout le trafic entrant, créez une règle avec une liste de contextes vide à l'aide du drapeau --empty-context-list. Une règle sans contexte refuse tout accès entrant au projet.
```
ibmcloud cbr rule-create --description "Isolate workloads entirely" \
--service-name codeengine \
--service-instance my-project-id \
--api-types crn:v1:bluemix:public:context-based-restrictions::::api-type:data-plane \
--empty-context-list
```

Test de la règle de restriction contextuelle pour la connectivité entrante

Après avoir créé la règle de restriction basée sur le contexte, vous pouvez la tester à l'aide de votre application ou de votre fonction :

Si vous avez bloqué les points de terminaison publics: Les tentatives d'accès à votre application ou fonction par l'intermédiaire de son site public URL donnent lieu à un message d'erreur RBAC Access Denied. Votre charge de travail reste accessible via des points d'extrémité privés (à partir de VPC ou d'autres composants Code Engine dans le même projet).
Si vous avez restreint les terminaux privés par IP: l'accès par les terminaux privés n'est accordé qu'aux zones de réseau ou aux adresses IP figurant sur la liste des autorisations. Si une requête provient d'une source qui n'est pas autorisée, un message d'erreur RBAC Access Denied s'affiche. Par exemple, si vous n'autorisez que 9.9.9.9/32, votre application ou fonction n'est accessible qu'à partir de cette plage d'adresses IP via le point de terminaison privé. Tout ce qui se situe en dehors de cette fourchette entraîne l'affichage d'un message d'erreur.

Si vous avez sélectionné une zone réseau qui pointe vers un nuage privé virtuel (VPC), vous devez également créer une passerelle VPE (point de terminaison privé virtuel) pour permettre au VPC d'accéder aux charges de travail privées. Après avoir créé la passerelle, il se peut que vous constatiez un retard temporaire dû à la résolution du PDNS. Au début, vous verrez des messages d'erreur sur RBAC Access Denied, mais l'accès vous sera accordé au bout d'un certain temps.