Exécution des commandes « ibmcloud », « ibmcloud oc » et « ibmcloud cr » à partir d'une liste blanche

Si les politiques réseau de votre entreprise empêchent l'accès depuis votre système local à des terminaux publics via des proxys ou des listes d'autorisation, pour exécuter les commandes ibmcloud, ibmcloud oc et ibmcloud cr, vous devez autoriser l'accès à TCP pour IBM Cloud, Red Hat OpenShift on IBM Cloud et IBM Cloud Container Registry.

1. Ajoutez cloud.ibm.com sur le port 443 à votre liste blanche.

2. Vérifiez votre connexion en vous connectant à IBM Cloud via ce noeud final d'API.

   ibmcloud login -a https://cloud.ibm.com/
   

3. Ajoutez containers.cloud.ibm.com sur le port 443 à votre liste blanche.

4. Vérifiez votre connexion. Si l'accès est configuré correctement, les messages similaires aux suivants sont affichés dans la sortie.

   curl https://containers.cloud.ibm.com/global/v1/versions
   

   Exemple de sortie

   {"kubernetes":[{"major":1,"minor":19,"patch":16,"default":false,"end_of_service":""},{"major":1,"minor":20,"patch":13,"default":false,"end_of_service":""},{"major":1,"minor":21,"patch":7,"default":true,"end_of_service":""},{"major":1,"minor":22,"patch":4,"default":false,"end_of_service":""}],"openshift":[{"major":3,"minor":11,"patch":542,"default":false,"end_of_service":"2022-06-06T12:00:00+0000"},{"major":4,"minor":6,"patch":47,"default":false,"end_of_service":""},{"major":4,"minor":7,"patch":37,"default":false,"end_of_service":""},{"major":4,"minor":8,"patch":21,"default":true,"end_of_service":""}]}
   

5. Autorisez l'accès aux régions IBM Cloud Container Registry que vous prévoyez d'utiliser sur le port 443 dans votre liste blanche. Le registre global héberge des images publiques fournies par IBM et les registres régionaux stockent vos propres images privées ou publiques. Si votre liste blanche est basée sur les adresses IP, vous pouvez consulter ce tableau pour voir quelles adresses IP sont autorisées lorsque vous accordez l'accès aux points de terminaison du service régional « IBM Cloud Container Registry ».

6. Vérifiez votre connexion. Voici un exemple pour le registre régional américain Est des Etats-Unis et Sud des Etats-Unis. Si l'accès est configuré correctement, un message du jour est renvoyé dans la sortie. Notez que s'il n'y a pas de message, un 204 est renvoyé.

   curl -i https://us.icr.io/api/v1/messages
   

Exécution de commandes oc à partir d'une liste autorisée

Si les politiques du réseau d'entreprise empêchent l'accès depuis votre système local aux terminaux publics via des proxys ou des listes d'autorisation, pour exécuter les commandes oc, vous devez autoriser l'accès TCP pour le cluster.

Lorsqu'un cluster est créé, le port des URL de nœud final de service est affecté de manière aléatoire à partir de 30000 - 32767. Vous pouvez choisir d'ouvrir la plage de ports 30000 - 32767 pour tout cluster qui pourrait être créé ou vous pouvez choisir d'autoriser l'accès à un cluster existant spécifique.

Avant de commencer, autorisez l'accès pour exécuter des commandes ibmcloud oc.

Pour autoriser l'accès à un cluster spécifique :

1. Connectez-vous à l'interface de ligne de commande IBM Cloud. A l'invite, entrez vos données d'identification IBM Cloud. Si vous disposez d'un compte fédéré, incluez l'option --sso.

   ibmcloud login [--sso]
   

2. Si le cluster se trouve dans un autre groupe de ressources que default, ciblez ce groupe de ressources. Pour voir à quel groupe de ressources appartient chaque cluster, exécutez la commande ibmcloud oc cluster ls. Remarque : vous devez disposer au moins du rôle Afficheur pour le groupe de ressources.

   ibmcloud target -g RESOURCE_GROUP_NAME
   

3. Obtenez le nom de votre cluster.

   ibmcloud oc cluster ls
   

4. Extrayez les URL de noeud final de service pour votre cluster.

   • Si seule l'URL du noeud final de service privé est indiquée, extrayez cette URL. Vos utilisateurs de cluster autorisés peuvent accéder au maître via ce noeud final sur le réseau privé.
   • Si l'URL du noeud final de service public et l'URL du noeud final de service privé sont indiquées, extrayez ces deux URL. Vos utilisateurs de cluster autorisés peuvent accéder au maître via le noeud final public sur le réseau public ou via le noeud final privé sur le réseau privé.

   ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID
   

   Exemple de sortie

   ...
   Public Service Endpoint URL:    https://c3.<region>.containers.cloud.ibm.com:30426
   Private Service Endpoint URL:   https://c3-private.<region>.containers.cloud.ibm.com:31140
   ...
   

5. Autorisez l'accès aux URL de noeud final de service et aux ports que vous avez obtenus à l'étape précédente. Si votre liste blanche est basée sur les adresses IP, vous pouvez consulter ce tableau pour voir quelles adresses IP sont autorisées lorsque vous autorisez l'accès aux URL des points de terminaison du service.

6. Vérifiez votre connexion.

   • Si le noeud final de service cloud public est activé :

       curl --insecure <public_service_endpoint_URL>/version
       ```
       Exemple de commande
       ```sh {: pre}
       curl --insecure https://c3.<region>.containers.cloud.ibm.com:31142/version
       ```
       Exemple de sortie
       ```json {: screen}
       {
           "major": "1",
           "minor": "7+",
           "gitVersion": "v1.7.4-2+eb9172c211dc41",
           "gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534",
           "gitTreeState": "clean",
           "buildDate": "2017-11-16T08:13:08Z",
           "goVersion": "go1.8.3",
           "compiler": "gc",
           "platform": "linux/amd64"
       }
       ```
   * Si seul le noeud final de service cloud privé est activé, vous devez être dans votre réseau privé IBM Cloud ou vous connecter au réseau privé via une connexion VPN pour vérifier votre connexion au maître. **Remarque** : vous devez [exposer le noeud final maître via un équilibreur de charge privé](/docs/openshift?topic=openshift-access_cluster#access_private_se) de sorte que les utilisateurs puissent accéder au maître via un VPN ou une connexion IBM Cloud&reg; Direct Link.
   ```sh {: pre}
       curl --insecure <private_service_endpoint_URL>/version
       ```
       Exemple de commande
       ```sh {: pre}
       curl --insecure https://c3-private.<region>.containers.cloud.ibm.com:31142/version
       ```
       Exemple de sortie
       ```json {: screen}
       {
           "major": "1",
           "minor": "7+",
           "gitVersion": "v1.7.4-2+eb9172c211dc41",
           "gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534",
           "gitTreeState": "clean",
           "buildDate": "2017-11-16T08:13:08Z",
           "goVersion": "go1.8.3",
           "compiler": "gc",
           "platform": "linux/amd64"
       }
       ```
   

7. Facultatif : répétez ces étapes pour chaque cluster que vous avec besoin d'exposer.

Exécution de commandes calicoctl à partir d'une liste autorisée

Si les politiques réseau de votre entreprise empêchent l'accès depuis votre système local aux terminaux publics via des proxys ou des listes d'autorisation, pour exécuter les commandes calicoctl, vous devez autoriser l'accès à TCP pour les commandes Calico.

Avant de commencer, autorisez l'accès aux sites ibmcloud commandes et oc commandes.

1. Extrayez l'adresse IP de l'URL du maître que vous avez utilisée pour autoriser les commandes oc.

2. Obtenez le port pour etcd.

   oc get cm -n kube-system cluster-info -o yaml | grep etcd_host
   

3. Autorisez l'accès aux règles Calico via l'adresse IP de l'URL du maître et le port etcd.

Autorisation de l'accès au registre d'images Red Hat OpenShift dans une liste autorisée

Si vous configurez une route externe sécurisée pour le registre d'images interne, ou pour accéder à un compartiment IBM Cloud Object Storage qui sert de sauvegarde à votre registre d'images interne dans un cluster VPC, vous devez autoriser l'accès au registre interne et aux points de terminaison IBM Cloud Object Storage dans la liste blanche de votre entreprise.

1. Si vous créez une route externe pour le registre d'images Red Hat OpenShift interne, autorisez l'accès au domaine *.containers.appdomain.cloud afin que vous puissiez accéder à la route image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud à partir de votre réseau d'entreprise.

2. Clusters de VPC : si vous devez accéder à un compartiment IBM Cloud Object Storage qui sauvegarde le registre Red Hat OpenShift interne, ou si vous devez accéder à IBM Cloud Object Storage à partir de votre réseau d'entreprise, autorisez l'accès au domaine *.cloud-object-storage.appdomain.cloud.

Autorisation du trafic entrant à partir d'un cluster vers un autre service

Pour autoriser l'accès depuis votre cluster vers un autre service, modifiez la liste blanche de ce service ou votre liste blanche sur site.

1. Récupérez les zones de noeud worker et les clouds privés virtuels dans lesquels votre cluster est créé.

   ibmcloud oc cluster get -c <cluster>
   

   Exemple de sortie

   ...
   Worker Zones:                   us-south-1, us-south-2, us-south-3
   Ingress Subdomain:              vpc-prod.us-south.containers.appdomain.cloud
   Ingress Secret:                 vpc-prod
   Creator:                        -
   Public Service Endpoint URL:    https://c2.us-south.containers.cloud.ibm.com:20267
   Private Service Endpoint URL:   https://c2.private.us-south.containers.cloud.ibm.com:20267
   Pull Secrets:                   enabled in the default namespace
   VPCs:                           ff537d43-a5a4-4b65-9627-17eddfa5237b
   ...
   

2. Pour les zones de noeud worker et le cloud privé virtuel que vous avez trouvés, vérifiez que vous avez activé une passerelle publique sur les sous-réseaux VPC dans chaque zone de noeud worker.

3. Répertoriez les passerelles publiques pour les sous-réseaux. Dans la sortie, pour les zones et le cloud privé virtuel contenant votre cluster, notez les adresses IP flottantes (Floating IP) de passerelle pour les sous-réseaux.

   ibmcloud is public-gateways
   

   Exemple de sortie

   ID                                     Name                                       Status      Floating IP      VPC              Zone
   5d308ea5-9f32-43b3-aaae-194d5723a3e5   pgw-b9d45630-c053-11e9-b2f8-79328ce05e7e   available   169.XX.XXX.XX    test-vpc         us-south-1
   f8b95e43-a408-4dc8-a489-ed649fc4cfec   pgw-18a3ebb0-b539-11e9-9838-f3f4efa02374   available   169.XX.XXX.XX    prod             us-south-1
   2ba9a280-fffa-4b0c-bdca-7970f09f9b8a   pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374   available   169.XX.XXX.XX    prod             us-south-2
   057ddef6-631f-4b22-89eb-1e99982a54fa   pgw-64c5cae0-0be2-11ea-8f26-e1565e79a36c   available   52.XX.XXX.XXX    prod             us-south-3
   

4. Ajoutez les adresses IP publiques de la passerelle à la liste blanche de votre service ou à votre liste blanche locale pour le trafic entrant.

5. Répétez ces étapes pour chaque cluster vers ou depuis lequel vous souhaitez autoriser le trafic.

Autorisation du trafic sortant vers un cluster à partir d'un autre service

Pour autoriser les sorties vers votre cluster depuis un autre service, modifiez la liste blanche de ce service ou votre liste blanche sur site.

1. Obtenez les sous-réseaux ou les adresses IP des noeuds worker.
   • CIDR des sous-réseaux des nœuds de travail: si vous prévoyez de modifier fréquemment le nombre de nœuds de travail de votre cluster, par exemple si vous activez la fonctionnalité d'ajustement automatique de la taille du cluster, vous ne souhaiterez peut-être pas mettre à jour votre liste blanche à chaque ajout d'un nouveau nœud de travail. A la place, vous pouvez ajouter les sous-réseaux VPC utilisés par le cluster. N'oubliez pas qu'un sous-réseau VPC peut être partagé par des noeuds worker dans d'autres clusters.
     1. Récupérez les zones de noeud worker et les clouds privés virtuels dans lesquels votre cluster est créé.

        ibmcloud oc cluster get -c <cluster>
        

        Exemple de sortie

        ...
        Worker Zones:                   us-south-1, us-south-2, us-south-3
        Ingress Subdomain:              vpc-prod.us-south.containers.appdomain.cloud
        Ingress Secret:                 vpc-prod
        Creator:                        -
        Public Service Endpoint URL:    https://c2.us-south.containers.cloud.ibm.com:20267
        Private Service Endpoint URL:   https://c2.private.us-south.containers.cloud.ibm.com:20267
        Pull Secrets:                   enabled in the default namespace
        VPCs:                           ff537d43-a5a4-4b65-9627-17eddfa5237b
        ...
        

     2. Pour les sous-réseaux dans les zones et le cloud privé virtuel contenant votre cluster, notez le routage CIDR de sous-réseau (Subnet CIDR).

        ibmcloud is subnets
        

        Exemple de sortie

        ID                                     Name             Status      Subnet CIDR        Addresses   ACL                                                          Public Gateway                             VPC              Zone
        5f5787a4-f560-471b-b6ce-20067ac93439   vpc-prod-dal1    available   10.240.0.0/24      183/256     allow-all-network-acl-ff537d43-a5a4-4b65-9627-17eddfa5237b   -                                          prod             us-south-1
        e3c19786-1c54-4248-86ca-e60aab74ed62   vpc-prod-dal2    available   10.240.64.0/24     183/256     allow-all-network-acl-ff537d43-a5a4-4b65-9627-17eddfa5237b   -                                          prod             us-south-2
        2930a068-51cc-4eca-807b-3f296d0891b4   vpc-prod-dal3    available   10.240.128.0/24    249/256     allow-all-network-acl-ff537d43-a5a4-4b65-9627-17eddfa5237b   -                                          prod             us-south-3
        

   • Adresses IP de nœud de travail individuel: Si vous disposez d'un petit nombre de nœuds worker qui exécutent une seule application et n'ont pas besoin d'échelle, ou si vous souhaitez ajouter un seul nœud worker, listez tous les nœuds worker de votre cluster et notez les adresses IP principales. Seuls ces noeuds worker sont ajoutés. Si vous supprimez des nœuds de travail ou si vous en ajoutez au cluster, vous devez mettre à jour votre liste blanche en conséquence.

       ibmcloud oc worker ls --cluster <cluster_name_or_ID>
       ```
   

2. Ajoutez les adresses CIDR des sous-réseaux ou les adresses IP individuelles des nœuds de travail à la liste blanche de votre service ou à votre liste blanche locale pour le trafic sortant.
3. Répétez ces étapes pour chaque cluster vers ou depuis lequel vous souhaitez autoriser le trafic.

Ouverture des ports requis dans les listes d'autorisations publiques