Exemples de scénarios de restrictions contextuelles

Avec les restrictions basées sur le contexte, les propriétaires de comptes et les administrateurs peuvent définir et appliquer des restrictions d'accès aux ressources IBM Cloud®, en fonction du contexte des demandes d'accès. L'accès aux ressources IBM Cloud Kubernetes Service peut être contrôlé par des restrictions contextuelles et des politiques de gestion des identités et des accès. Pour plus d'informations, voir Protection des ressources IBM Cloud Kubernetes Service avec des restrictions basées sur le contexte.

Les applications fonctionnant sur les clusters IBM Cloud Kubernetes Service, par exemple les serveurs web exposés par un Kubernetes LoadBalancer,, ne sont pas limitées par les règles CBR.

Description du scénario

Dans cet exemple de scénario, vous utilisez des restrictions basées sur le contexte pour limiter le trafic à votre cluster en autorisant uniquement une adresse IP individuelle à se connecter aux API cluster sur le réseau public tout en autorisant tout le trafic privé.

Dans les étapes suivantes, vous commencez par créer une zone réseau, ou une liste autorisée, qui inclut une adresse IP unique. Ensuite, vous créez une règle de restrictions basée sur le contexte pour votre cluster qui autorise tous les accès au réseau privé et autorise la zone réseau qui contient l'adresse IP individuelle. Lorsque vous créez la règle, vous l'associez à la zone réseau qui contient l'adresse IP individuelle.

Prérequis

Avant de commencer ce tutoriel, assurez-vous d'avoir créé ou installé les ressources et outils suivants.

Création de votre zone réseau

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

  1. Exécutez l'exemple de commande suivant pour créer un réseau qui inclut une seule adresse IP client que vous souhaitez utiliser.

    ibmcloud cbr zone-create --addresses 129.XX.XX.XX --description "Allow only client IP" --name allow-client-ip

  2. Vérifiez que la zone réseau a été créée.

    ibmcloud cbr zones

Création de votre règle CBR

  1. Après avoir créé votre zone réseau (liste autorisée), créez une règle CBR et ajoutez la zone réseau que vous avez créée à l'étape précédente. L'exemple suivant crée une règle qui utilise le type d'API cluster. Remplacez NETWORK-ZONE-ID par l'ID de la zone réseau allow-client-ip que vous avez créée à l'étape 1.

    ibmcloud cbr rule-create --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --description "privateAccess=allowAll, publicAccess=oneIP" --service-name containers-kubernetes --service-instance CLUSTER-ID --context-attributes endpointType=private --context-attributes endpointType=public,networkZoneId=NETWORK-ZONE-ID

    Description des options de commande.

    --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster
    Définissez l'API crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster pour n'autoriser que les ressources de la zone réseau que vous avez créée précédemment à accéder uniquement aux API cluster, qui incluent les API pour diverses commandes kubectl.
    --service-instance CLUSTER-ID
    Limitez la portée de la règle à un seul cluster de sorte que seules les ressources de la zone réseau que vous avez créée précédemment puissent accéder au CLUSTER-ID.
    --context-attributes endpointType=private
    Définir l'attribut de contexte endpointType=private sans associer de zone réseau autorise tout le trafic privé vers le cluster.
    --context-attributes endpointType=public,networkZoneId=all-client-ip
    Définissez l'attribut de contexte endpointType=public et associez le networkZoneId=allow-client-ip que vous avez créé précédemment pour autoriser uniquement les ressources de la zone allow-client-ip à accéder au cluster sur le réseau public.

  2. Vérifier que la règle a été créée.

    ibmcloud cbr rules

Test de vos restrictions contextuelles

Pour tester votre configuration de restrictions basées sur le contexte, vous pouvez essayer d'appeler les API de cluster pour votre cluster, par exemple en répertoriant les pods, sur le réseau public à partir d'une adresse IP autre que l'adresse IP individuelle que vous avez autorisée dans votre zone réseau. Avec cette configuration, toute la connectivité privée est autorisée, tandis que seule l'adresse IP individuelle de votre zone réseau peut se connecter aux API de cluster sur le réseau public.

Scénarios supplémentaires

Maintenant que vous avez créé une règle et une zone réseau CBR simples, consultez les exemples plus avancés suivants pour contrôler davantage l'accès à vos ressources IBM Cloud Kubernetes Service.

Autorisation de différentes adresses IP pour accéder aux noeuds finaux de service publics et privés

Dans ce scénario, vous autorisez différentes adresses IP ou routages CIDR à accéder aux noeuds finaux de service publics et privés de vos clusters IBM Cloud Kubernetes Service en créant des zones réseau distinctes pour chaque adresse IP. Ensuite, vous créez une règle qui permet à chaque zone réseau d'accéder aux noeuds finaux de service publics ou privés.

  1. Créez une zone réseau pour une adresse IP publique ou CIDR et une autre pour une adresse IP privée ou CIDR que vous souhaitez autoriser à accéder à vos clusters IBM Cloud Kubernetes Service.

    Exemples de commandes permettant de créer des zones réseau distinctes appelées public-IP-zone et private-IP-zone. Dans cet exemple, chaque zone contient plusieurs adresses IP ou CIDR, séparés par une virgule, que vous souhaitez autoriser à accéder à vos clusters.

    ibmcloud cbr zone-create --addresses 1.2.3.4,12.12.12.0/24 --description "Allowed Public IP Addresses Zone" --name "public-ip-zone"

    ibmcloud cbr zone-create --addresses 10.20.20.20,10.10.10.0/24 --description "Allowed Private IP Addresses Zone" --name "private-ip-zone"

  2. Obtenez les ID des zones private-ip-zone et public-ip-zone que vous avez créées à l'étape précédente.

    ibmcloud cbr zones

  3. Créez une règle qui permet à private-ip-zone de se connecter au noeud final de service privé de votre cluster et qui permet également à public-ip-zone de se connecter au noeud final de service public de votre cluster uniquement. Cette règle s'applique au cluster spécifié avec l'option --service-instance. Si vous souhaitez appliquer la règle à tous les clusters de votre compte, ne spécifiez pas de cluster.

    ibmcloud cbr rule-create --context-attributes "endpointType=public,networkZoneId=PUBLIC-IP-ZONE-ID" --context-attributes "endpointType=private,networkZoneId=PRIVATE-IP-ZONE-ID" --description "Separate private and public IPs for cluster and management rule" --service-name containers-kubernetes --service-instance CLUSTER-ID

Autoriser différentes adresses IP à accéder à différents types d'API sur les noeuds finaux de service publics et privés

Comme dans le scénario précédent, vous autorisez différentes adresses IP à accéder au point de terminaison du service public ou privé pour les clusters IBM Cloud Kubernetes Service. Toutefois, dans ce scénario, l'accès est davantage limité par des types d'API spécifiques pour les API cluster et management. Pour plus d'informations sur les types d'API, voir Protection d'API spécifiques.

  1. Créez quatre zones réseau, une pour chacune des adresses IP que vous souhaitez autoriser à accéder aux API cluster publiques ou privées ou aux API management publiques ou privées. Notez que vous pouvez inclure plusieurs adresses IP ou CIDR, séparés par une virgule, que vous souhaitez autoriser à accéder à vos clusters.

    ibmcloud cbr zone-create --addresses 1.2.3.4,12.12.12.0/24 --description "Allowed Public IP Addresses for IKS and ROKS APIs" --name "public-mgmt-zone"

    ibmcloud cbr zone-create --addresses 10.20.20.20,10.10.10.0/24 --description "Allowed Private IP Addresses IKS and ROKS APIs" --name "private-mgmt-zone"

    ibmcloud cbr zone-create --addresses 11.11.11.0/24 --description "Allowed Public IP Addresses for cluster apiserver" --name "public-cluster-zone"

    ibmcloud cbr zone-create --addresses 10.30.30.30 --description "Allowed Private IP Addresses for cluster apiserver" --name "private-cluster-zone"

  2. Obtenez les ID des zones que vous avez créées à l'étape précédente.

    ibmcloud cbr zones

    Exemple de sortie

    OK
id                                 name                   address_count   
c14c0839c13d8aa0afa8383e2be2e124   public-mgmt-zone       2   
f9676ca6ef37685315fa254b89d73159   public-cluster-zone    1   
c14c0839c13d8aa0afa8383e2be2e843   private-cluster-zone   1   
b53353de929de39ac2381f9b4cde8507   private-mgmt-zone      2

  3. Créez une règle qui protège l'accès aux API cluster et management publiques et privées en utilisant les zones que vous avez créées précédemment.

    ibmcloud cbr rule-create --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:management --context-attributes "endpointType=public,networkZoneId=PUBLIC-MGMT-ZONE-ID" --context-attributes "endpointType=private,networkZoneId=PRIVATE-MGMT-ZONE-ID" --description "Separate private and public IPs for the management APIs" --service-name containers-kubernetes

    ibmcloud cbr rule-create --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --context-attributes "endpointType=public,networkZoneId=PUBLIC-CLUSTER-ZONE-ID" --context-attributes "endpointType=private,networkZoneId=PRIVATE-CLUSTER-ZONE-ID" --description "Separate private and public IPs for cluster APIs" --service-name containers-kubernetes