Ejecución de comandos ibmcloud cr ibmcloud, ibmcloud oc, y desde una lista de permitidos

Si las políticas de red de la empresa impiden el acceso desde su sistema local a los puntos finales públicos a través de proxies o listas de permitidos, para ejecutar comandos ibmcloud cr ibmcloud, ibmcloud oc y, debe permitir el acceso TCP para IBM Cloud, Red Hat OpenShift on IBM Cloud y IBM Cloud Container Registry.

1. Permite el acceso cloud.ibm.com al puerto 443 en tu lista de permitidos.

2. Verifique la conexión iniciando una sesión en IBM Cloud a través de este punto final de API.

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

3. Permite el acceso containers.cloud.ibm.com al puerto 443 en tu lista de permitidos.

4. Compruebe la conexión. Si el acceso está configurado correctamente, se muestran mensajes similares a los siguientes en la salida.

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

   Salida de ejemplo

   {"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. Permite el acceso a las regiones de IBM Cloud Container Registry que tengas previsto utilizar en el puerto 443 en tu lista de permitidos. El registro global almacena imágenes públicas proporcionadas por IBM y los registros regionales almacenan sus propias imágenes privadas o públicas. Si tu lista de permitidos se basa en direcciones IP, puedes consultar esta tabla para ver qué direcciones IP están habilitadas cuando permites el acceso a los puntos finales del servicio regional IBM Cloud Container Registry.

6. Compruebe la conexión. A continuación se muestra un ejemplo de registro regional de EE. UU. este y EE. UU. sur. Si el acceso se ha configurado correctamente, se devuelve un mensaje del día en la salida. Tenga en cuenta que si no hay mensajes, se devuelve un 204.

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

Ejecución de mandatos oc desde detrás de una lista de elementos permitidos

Si las políticas de red de la empresa impiden el acceso desde su sistema local a los puntos finales públicos a través de proxies o listas de permitidos, para ejecutar comandos oc, deberá habilitar el acceso TCP para el clúster.

Cuando se crea un clúster, el puerto en los URL de punto final de servicio se asigna aleatoriamente del rango 30000-32767. Puede optar por abrir el rango de puertos 30000-32767 para cualquier clúster que se pueda crear o puede optar por permitir el acceso para un clúster existente específico.

Antes de empezar, permita el acceso para ejecutar mandatos ibmcloud oc.

Para permitir el acceso a un clúster específico:

1. Inicie una sesión en la CLI de IBM Cloud. Escriba sus credenciales de IBM Cloud cuando se le solicite. Si tiene una cuenta federada, incluya la opción --sso.

   ibmcloud login [--sso]
   

2. Si el clúster está en un grupo de recursos distinto de default, elija como destino dicho grupo de recursos. Para ver el grupo de recursos al que pertenece cada clúster, ejecute ibmcloud oc cluster ls. Nota: Debe tener al menos el rol de Visor para el grupo de recursos.

   ibmcloud target -g RESOURCE_GROUP_NAME
   

3. Obtenga el nombre del clúster.

   ibmcloud oc cluster ls
   

4. Recupere los URL de punto final de servicio para el clúster.

   • Si solo está especificado el URL de punto final de servicio privado, obtenga este URL. Los usuarios autorizados del clúster pueden acceder al nodo maestro a través de este punto final en la red privada.
   • Si tanto el URL de punto final de servicio público como el URL de punto final de servicio privado están especificados, obtenga los dos URL. Los usuarios autorizados del clúster pueden acceder al nodo maestro a través del punto final público de la red pública o del punto final privado de la red privada.

   ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID
   

   Salida de ejemplo

   ...
   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. Permita el acceso a los URL de punto final de servicio y a los puertos que ha obtenido en el paso anterior. Si tu lista de permitidos se basa en direcciones IP, puedes consultar esta tabla para ver qué direcciones IP se abren cuando permites el acceso a las URL de los puntos finales del servicio.

6. Compruebe la conexión.

   • Si el punto final de servicio en la nube público está habilitado:

       curl --insecure <public_service_endpoint_URL>/version
       ```
       Mandato de ejemplo
       ```sh {: pre}
       curl --insecure https://c3.<region>.containers.cloud.ibm.com:31142/version
       ```
       Salida de ejemplo
       ```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 solo está habilitado el punto final de servicio en la nube privado, debe estar en la red privada de IBM Cloud o debe conectarse a la red privada a través de una conexión VPN para verificar la conexión con el nodo maestro. **Nota**: Debe [exponer el punto final maestro a través de un equilibrador de carga privado](/docs/openshift?topic=openshift-cluster-access-private-vpc) para que los usuarios puedan acceder al nodo maestro a través de una conexión VPN o IBM Cloud&reg; Direct Link.
   ```sh {: pre}
       curl --insecure <private_service_endpoint_URL>/version
       ```
       Mandato de ejemplo
       ```sh {: pre}
       curl --insecure https://c3-private.<region>.containers.cloud.ibm.com:31142/version
       ```
       Salida de ejemplo
       ```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. Opcional: repita estos pasos para cada clúster que necesite exponer.

Ejecución de mandatos calicoctl desde detrás de una lista de elementos permitidos

Si las políticas de red de la empresa impiden el acceso desde su sistema local a puntos finales públicos a través de proxies o listas de permitidos, para ejecutar comandos calicoctl, debe permitir el acceso TCP para los comandos Calico.

Antes de empezar, permita el acceso para ejecutar mandatos ibmcloud y mandatos oc.

1. Recupere la dirección IP del URL maestro que ha utilizado para permitir los mandatos oc.

2. Obtenga el puerto para etcd.

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

3. Permita el acceso para las políticas de Calico mediante la dirección IP del URL maestro y el puerto etcd.

Permitir el acceso al registro de imágenes Red Hat OpenShift en una lista de elementos permitidos

Si configura una ruta externa segura para el registro de imágenes interno, o para acceder a un depósito de IBM Cloud Object Storage que realiza una copia de seguridad de su registro de imágenes interno en un clúster de VPC, debe permitir el acceso al registro interno y a los puntos finales IBM Cloud Object Storage en la lista de permitidos de su empresa.

1. Si crea una ruta externa para el registro de imagen de Red Hat OpenShift interno, permita el acceso al dominio de *.containers.appdomain.cloud para que pueda acceder a la ruta de image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud desde la red corporativa.

2. Clústeres de VPC: si tiene que acceder a un grupo de IBM Cloud Object Storage que realiza copias de seguridad del registro de imágenes interno de Red Hat OpenShift, o si desea acceder de algún otro modo a IBM Cloud Object Storage desde su red corporativa, permita el acceso al dominio *.cloud-object-storage.appdomain.cloud.

Permitir la entrada de un clúster a otro servicio

Para permitir el acceso desde tu clúster a otro servicio, modifica la lista de servicios permitidos de ese servicio o tu lista de servicios permitidos local.

1. Obtenga las Zonas de nodos trabajadores y las VPC en las que se ha creado el clúster.

   ibmcloud oc cluster get -c <cluster>
   

   Salida de ejemplo

   ...
   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. Para las zonas de nodos trabajadores y la VPC que ha encontrado, asegúrese de que ha habilitado una pasarela pública en las subredes de VPC en cada zona de nodo trabajador.

3. Obtenga una lista de las pasarelas públicas correspondientes a las subredes. En la salida, para las zonas y la VPC en las que se encuentra el clúster, anote las direcciones IP flotantes de la pasarela para las subredes.

   ibmcloud is public-gateways
   

   Salida de ejemplo

   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. Añade las direcciones IP de la puerta de enlace pública a la lista de direcciones permitidas de tu servicio o a tu lista de direcciones permitidas local para el tráfico entrante.

5. Repita estos pasos para cada clúster cuyo tráfico desee permitir, tanto de entrada como de salida.

Permitir la salida a un clúster desde otro servicio

Para permitir el tráfico saliente hacia su clúster desde otro servicio, modifique la lista de servicios permitidos de ese servicio o su lista de servicios permitidos local.

1. Obtenga las subredes de nodos trabajadores o las direcciones IP de los nodos trabajadores.
   • CIDR de las subredes de los nodos de trabajo: si prevé cambiar con frecuencia el número de nodos de trabajo de su clúster, por ejemplo, si habilita el escalador automático del clúster, es posible que no le convenga actualizar su lista de permitidos cada vez que se añada un nuevo nodo de trabajo. Puede, en su lugar, añadir las subredes de VPC que utiliza el clúster. Tenga en cuenta que es posible que la subred de VPC se comparta con nodos trabajadores de otros clústeres.
     1. Obtenga las Zonas de nodos trabajadores y las VPC en las que se ha creado el clúster.

        ibmcloud oc cluster get -c <cluster>
        

        Salida de ejemplo

        ...
        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. Para las subredes de las zonas y la VPC en las que se encuentra el clúster, anote el CIDR de subred.

        ibmcloud is subnets
        

        Salida de ejemplo

        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
        

   • Direcciones IP de nodo de trabajador individual: si tiene un pequeño número de nodos de trabajador que ejecutan solo una aplicación y no necesita escalarlo, o si desea añadir solo un nodo de trabajador, liste todos los nodos de trabajador del clúster y anote las direcciones IP primarias. Solo se añaden estos nodos trabajadores. Si elimina nodos de trabajo o añade nodos de trabajo al clúster, debe actualizar su lista de permitidos en consecuencia.

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

2. Añade los CIDR de las subredes o las direcciones IP individuales de los nodos de trabajo a la lista de permitidos de tu servicio o a tu lista de permitidos local para el tráfico saliente.
3. Repita estos pasos para cada clúster cuyo tráfico desee permitir, tanto de entrada como de salida.

Abrir los puertos necesarios en las listas públicas