View a markdown version of this page

Cree un clúster clásico de ROSA que utilice AWS PrivateLink - Red Hat OpenShift Service en AWS
Requisitos previosCree una Amazon VPC arquitecturaCree un clúster clásico de ROSA mediante la ROSA CLI y AWS PrivateLinkConfigure el reenvío de AWS PrivateLink DNSConfigure un proveedor de identidades y conceda el acceso clústerConceda al usuario acceso a un clústerConfiguración de permisos de cluster-adminConfiguración de permisos de dedicated-adminAcceda a a clúster través de la consola Red Hat Hybrid CloudImplemente una aplicación del catálogo para desarrolladoresRevoque los permisos de cluster-admin de un usuarioRevoque los permisos de dedicated-admin de un usuarioRevocar el acceso del usuario a un clústerEliminar un clúster y sus AWS STS recursos

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Cree un clúster clásico de ROSA que utilice AWS PrivateLink

Los clústeres ROSA classic se pueden implementar de diferentes maneras: públicos, privados o privados con. AWS PrivateLink Para obtener más información sobre ROSA classic, consulteROSA arquitectura. Tanto para clúster las configuraciones públicas como privadas, OpenShift clúster tiene acceso a Internet y la privacidad se establece en las cargas de trabajo de la aplicación en la capa de aplicación.

Si necesita que tanto las cargas clúster de trabajo como las de la aplicación sean privadas, puede configurarlas AWS PrivateLink con ROSA classic. AWS PrivateLink es una tecnología escalable y de alta disponibilidad que se ROSA utiliza para crear una conexión privada entre el ROSA servicio y los recursos del clúster en la cuenta del AWS cliente. Con AWS PrivateLink ella, el equipo de ingeniería de confiabilidad de sitios (SRE) de Red Hat puede acceder al clúster con fines de soporte y reparación mediante una subred privada conectada al punto final del AWS PrivateLink clúster.

Para obtener más información al respecto AWS PrivateLink, consulte ¿Qué es? AWS PrivateLink

Complete las acciones previas que se enumeran enConfigurar para usar ROSA.

El siguiente procedimiento crea una Amazon VPC arquitectura que se puede utilizar para alojar un clúster. Todos clúster los recursos están alojados en la subred privada. La subred pública enruta el tráfico saliente de la subred privada a través de una puerta de enlace NAT a la Internet pública. En este ejemplo, se utiliza 10.0.0.0/16 con bloque de CIDR para la Amazon VPC. Sin embargo, puede elegir otro bloque de CIDR. Para obtener más información, consulte Tamaño de la VPC.

importante

Si no se Amazon VPC cumplen los requisitos, se produce un error en la creación del clúster.

ejemplo
Amazon VPC console

  1. Abra la consola de Amazon VPC.

  2. En el panel de VPC, elija Create VPC (Crear VPC).

  3. En Recursos para crear, elija VPC y más.

  4. Mantenga seleccionada la opción Generación automática de etiquetas de nombre para crear etiquetas de nombre para los recursos de la VPC, o desactívela para proporcionar sus propias etiquetas de nombre para los recursos de la VPC.

  5. Para el bloque IPv4 CIDR, introduzca un rango de IPv4 direcciones para la VPC. Una VPC debe tener un rango de IPv4 direcciones.

  6. (Opcional) Para admitir IPv6 el tráfico, elige el bloque IPv6 CIDR, el bloque CIDR proporcionado por Amazon IPv6 .

  7. Deje Tenancy como. Default

  8. En Número de zonas de disponibilidad (AZs), elija el número que necesite. Para las implementaciones en zonas de disponibilidad múltiples (Multi-AZ), ROSA requiere tres zonas de disponibilidad. Para elegir una AZs para sus subredes, expanda Personalizar. AZs

    nota

    Algunos tipos de ROSA instancias solo están disponibles en determinadas zonas de disponibilidad. Puede usar el rosa list instance-types comando ROSA CLI para enumerar todos los tipos de ROSA instancias disponibles. Para comprobar si un tipo de instancia está disponible para una zona de disponibilidad determinada, usa el AWS CLI comandoaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

  9. Para configurar las subredes, elija valores para Cantidad de subredes públicas y Cantidad de subredes privadas. Para elegir los rangos de direcciones IP para las subredes, expanda Personalizar bloques CIDR de subredes.

    nota

    ROSA requiere que los clientes configuren al menos una subred privada por cada zona de disponibilidad utilizada para crear clústeres.

  10. Para conceder a los recursos de la subred privada acceso a Internet pública, en el caso de las puertas de enlace NAT IPv4, elija el número de puertas de enlace NAT AZs en las que desee crear las puertas de enlace NAT. En producción, se recomienda implementar una puerta de enlace de NAT en cada AZ con recursos que necesiten acceso a la Internet pública.

  11. (Opcional) Si necesita acceder Amazon S3 directamente desde su VPC, elija los puntos de enlace de la VPC, S3 Gateway.

  12. Deje seleccionadas las opciones de DNS predeterminadas. ROSA requiere compatibilidad con nombres de host DNS en la VPC.

  13. Seleccione Creación de VPC.

AWS CLI

  1. Cree una VPC con un bloque de CIDR 10.0.0.0/16.

     aws ec2 create-vpc \
     --cidr-block 10.0.0.0/16 \
     --query Vpc.VpcId \
     --output text

    El comando anterior devuelve el ID de VPC. El siguiente es un ejemplo de salida.

    vpc-1234567890abcdef0

  2. Guarde el ID de VPC en una variable de entorno.

    export VPC_ID=vpc-1234567890abcdef0

  3. Cree una Name etiqueta para la VPC mediante la variable de VPC_ID entorno.

    aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC

  4. Habilite la compatibilidad con nombres de host DNS en la VPC.

    aws ec2 modify-vpc-attribute \
    --vpc-id $VPC_ID \
    --enable-dns-hostnames

  5. Cree una subred pública y privada en la VPC, especificando las zonas de disponibilidad en las que se deben crear los recursos.

    importante

    ROSA requiere que los clientes configuren al menos una subred privada por cada zona de disponibilidad utilizada para crear clústeres. Para las implementaciones Multi-AZ, se requieren tres zonas de disponibilidad. Si no se cumplen estos requisitos, se producirá un error en la creación del clúster.

    nota

    Algunos tipos de ROSA instancias solo están disponibles en determinadas zonas de disponibilidad. Puede usar el rosa list instance-types comando ROSA CLI para enumerar todos los tipos de ROSA instancias disponibles. Para comprobar si un tipo de instancia está disponible para una zona de disponibilidad determinada, usa el AWS CLI comandoaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

    aws ec2 create-subnet \
    --vpc-id $VPC_ID \
    --cidr-block 10.0.1.0/24 \
    --availability-zone us-east-1a \
    --query Subnet.SubnetId \
    --output text
aws ec2 create-subnet \
    --vpc-id $VPC_ID \
    --cidr-block 10.0.0.0/24 \
    --availability-zone us-east-1a \
    --query Subnet.SubnetId \
    --output text

  6. Almacene la subred pública y privada IDs en variables de entorno.

    export PUBLIC_SUB=subnet-1234567890abcdef0
export PRIVATE_SUB=subnet-0987654321fedcba0

  7. Cree una puerta de enlace a Internet y una tabla de rutas para el tráfico saliente. Cree una tabla de enrutamiento y una dirección IP elástica para el tráfico privado.

    aws ec2 create-internet-gateway \
    --query InternetGateway.InternetGatewayId \
    --output text
aws ec2 create-route-table \
    --vpc-id $VPC_ID \
    --query RouteTable.RouteTableId \
    --output text
aws ec2 allocate-address \
    --domain vpc \
    --query AllocationId \
    --output text
aws ec2 create-route-table \
    --vpc-id $VPC_ID \
    --query RouteTable.RouteTableId \
    --output text

  8. Almacene IDs las variables de entorno.

    export IGW=igw-1234567890abcdef0
export PUBLIC_RT=rtb-0987654321fedcba0
export EIP=eipalloc-0be6ecac95EXAMPLE
export PRIVATE_RT=rtb-1234567890abcdef0

  9. Adjunte la puerta de enlace de Internet a la VPC.

    aws ec2 attach-internet-gateway \
    --vpc-id $VPC_ID \
    --internet-gateway-id $IGW

  10. Asocie la tabla de rutas públicas a la subred pública y configure el tráfico para que se dirija a la puerta de enlace de Internet.

    aws ec2 associate-route-table \
    --subnet-id $PUBLIC_SUB \
    --route-table-id $PUBLIC_RT
aws ec2 create-route \
    --route-table-id $PUBLIC_RT \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id $IGW

  11. Cree la puerta de enlace NAT y asóciela a la dirección IP elástica para permitir el tráfico a la subred privada.

    aws ec2 create-nat-gateway \
    --subnet-id $PUBLIC_SUB \
    --allocation-id $EIP \
    --query NatGateway.NatGatewayId \
    --output text

  12. Asocie la tabla de rutas privadas a la subred privada y configure el tráfico para que se dirija a la puerta de enlace NAT.

    aws ec2 associate-route-table \
    --subnet-id $PRIVATE_SUB \
    --route-table-id $PRIVATE_RT
aws ec2 create-route \
    --route-table-id $PRIVATE_RT \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id $NATGW

  13. (Opcional) Para las implementaciones Multi-AZ, repita los pasos anteriores para configurar otras dos zonas de disponibilidad con subredes públicas y privadas.

Puede usar la ROSA CLI y AWS PrivateLink crear una clúster con una sola zona de disponibilidad (Single-AZ) o varias zonas de disponibilidad (Multi-AZ). En cualquier caso, el valor de CIDR de su máquina debe coincidir con el valor de CIDR de su VPC.

El siguiente procedimiento utiliza el rosa create cluster comando para crear un ROSA classic. clúster Para crear una zona de disponibilidad múltiple clúster, especifique --multi-az en el comando y, a continuación, seleccione la subred privada IDs que desee utilizar cuando se le solicite.

nota

Si utiliza un firewall, debe configurarlo para que ROSA pueda acceder a los sitios que necesita para funcionar.

Para obtener más información, consulte los requisitos para el uso de AWS PrivateLink clústeres en la documentación de Red Hat.

  1. Cree los roles y políticas de IAM cuenta necesarios utilizando --mode auto o--mode manual.

  2. Cree un clúster mediante la ejecución de uno de los siguientes comandos.

    • Single-AZ

      rosa create cluster --private-link --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16 --subnet-ids=<PRIVATE_SUBNET_ID>

    • Multi-AZ

      rosa create cluster --private-link --multi-az --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16
      nota

      Para crear un clúster que utilice credenciales de corta duración AWS PrivateLink con AWS Security Token Service (AWS STS), añada --sts --mode auto o --sts --mode manual al final del rosa create cluster comando.

  3. Cree los IAM roles de clúster operador siguiendo las instrucciones interactivas.

    rosa create operator-roles --interactive -c <CLUSTER_NAME>

  4. Cree el proveedor de OpenID Connect (OIDC) que los clúster operadores utilizan para autenticarse.

    rosa create oidc-provider --interactive -c <CLUSTER_NAME>

  5. Compruebe el estado de su. clúster

    rosa describe cluster -c <CLUSTER_NAME>
    nota

    El clúster State campo puede tardar hasta 40 minutos en mostrar el ready estado. Si se produce un error en el aprovisionamiento o no aparece ready después de 40 minutos, consulteResolución de problemas. Para ponerse en contacto con Soporte el servicio de asistencia de Red Hat para obtener asistencia, consulteObtener ROSA apoyo.

  6. Realice un seguimiento del progreso de la clúster creación observando los registros del OpenShift instalador.

    rosa logs install -c <CLUSTER_NAME> --watch

Los clústeres que se utilizan AWS PrivateLink crean una zona alojada pública y una zona alojada privada en Route 53. Los registros de la zona alojada Route 53 privada solo se pueden resolver desde la VPC a la que están asignados.

La validación DNS-01 de Let’s Encrypt requiere una zona pública para poder emitir certificados válidos y de confianza pública para el dominio. Los registros de validación se eliminan una vez finalizada la validación de Let's Encrypt. La zona sigue siendo necesaria para emitir y renovar estos certificados, que normalmente se requieren cada 60 días. Si bien estas zonas suelen aparecer vacías, una zona pública desempeña un rol fundamental en el proceso de validación.

Para obtener más información sobre las zonas alojadas AWS privadas, consulte Trabajar con zonas privadas. Para obtener más información acerca de las zonas alojadas públicas, consulte Uso de zonas alojadas públicas.

  1. Para permitir registros como, por ejemplo, la VPC api.<cluster_domain> y *.apps.<cluster_domain> resolverlos fuera de ella, configure un punto final de Route 53 Resolver entrada.

    nota

    Al configurar un punto final de entrada, debe especificar un mínimo de dos direcciones IP para garantizar la redundancia. Le recomendamos que especifique direcciones IP que se encuentren al menos en dos zonas de disponibilidad. Opcionalmente, puede especificar direcciones IP adicionales en estas u otras zonas de disponibilidad.

  2. Al configurar el punto final de entrada, selecciona la VPC y las subredes privadas que se usaron al crear el clúster.

Una vez que el punto final Route 53 Resolver interno esté asociado y en funcionamiento, configure el reenvío de DNS para que los servidores designados de la red puedan gestionar las consultas de DNS.

  1. Configure su red corporativa para que reenvíe las consultas de DNS a las direcciones IP del dominio de nivel superior, por ejemplo drow-pl-01.htno.p1.openshiftapps.com.

  2. Para reenviar consultas de DNS de una VPC a otra VPC, siga las instrucciones de Administración de reglas de reenvío.

  3. Para configurar el servidor DNS de su red remota, consulte la documentación específica del servidor DNS para configurar el reenvío de DNS selectivo para el dominio del clúster instalado.

ROSA incluye un OAuth servidor integrado. Una vez creado ROSA clúster el suyo, debe configurarlo OAuth para usar un proveedor de identidades. A continuación, puede añadir usuarios a su proveedor de identidad configurado para concederles acceso a su clúster. Puede otorgarles permisos de cluster-admin o dedicated-admin a estos usuarios según sea necesario.

Puede configurar diferentes tipos de proveedores de identidad para su clúster. Los tipos compatibles incluyen GitHub Enterprise GitHub, Google GitLab, LDAP, OpenID Connect y proveedores de identidad. HTPasswd

importante

El proveedor de HTPasswd identidad se incluye solo para permitir la creación de un único usuario administrador estático. HTPasswd no se admite como proveedor de identidades de uso general para. ROSA

El siguiente procedimiento configura un proveedor de GitHub identidades como ejemplo. Para obtener instrucciones sobre cómo configurar cada uno de los tipos de proveedores de identidad compatibles, consulte Configuración de proveedores de identidad para AWS STS.

  1. Ve a github.com e inicia sesión en tu cuenta. GitHub

  2. Si no tienes una GitHub organización que puedas usar para el aprovisionamiento de identidades, crea una. ROSA clúster Para obtener más información, consulta los pasos de la GitHub documentación.

  3. Con el modo interactivo de la ROSA CLI, configure un proveedor de identidades para su clúster ejecutando el siguiente comando.

    rosa create idp --cluster=<CLUSTER_NAME> --interactive

  4. Siga las instrucciones de configuración del resultado para restringir el clúster acceso a los miembros de su GitHub organización.

    I: Interactive mode enabled.
Any optional fields can be left empty and a default will be selected.
? Type of identity provider: github
? Identity provider name: github-1
? Restrict to members of: organizations
? GitHub organizations: <GITHUB_ORG_NAME>
? To use GitHub as an identity provider, you must first register the application:
  - Open the following URL:
    https://github.com/organizations/<GITHUB_ORG_NAME>/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=<CLUSTER_NAME>&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com
  - Click on 'Register application'
...

  5. Abre la URL en el resultado y <GITHUB_ORG_NAME> sustitúyela por el nombre de tu GitHub organización.

  6. En la página GitHub web, elija Registrar aplicación para registrar una nueva OAuth aplicación en su GitHub organización.

  7. Utilice la información de la GitHub OAuth página para rellenar el resto de las solicitudes rosa create idp interactivas, sustituyendo <GITHUB_CLIENT_ID> y <GITHUB_CLIENT_SECRET> utilizando las credenciales GitHub OAuth de la aplicación.

    ...
? Client ID: <GITHUB_CLIENT_ID>
? Client Secret: [? for help] <GITHUB_CLIENT_SECRET>
? GitHub Enterprise Hostname (optional):
? Mapping method: claim
I: Configuring IDP for cluster '<CLUSTER_NAME>'
I: Identity Provider 'github-1' has been created.
   It will take up to 1 minute for this configuration to be enabled.
   To add cluster administrators, see 'rosa grant user --help'.
   To login into the console, open https://console-openshift-console.apps.<CLUSTER_NAME>.<RANDOM_STRING>.p1.openshiftapps.com and click on github-1.
    nota

    La configuración del proveedor de identidad puede tardar aproximadamente dos minutos en activarse. Si configuraste un cluster-admin usuario, puedes ejecutar el oc get pods -n openshift-authentication --watch comando para ver cómo se vuelven a implementar los OAuth pods con la configuración actualizada.

  8. Compruebe que el proveedor de identidad esté configurado correctamente.

    rosa list idps --cluster=<CLUSTER_NAME>

Puede conceder acceso a un usuario al suyo clúster agregándolo al proveedor de identidades configurado.

El siguiente procedimiento agrega un usuario a una GitHub organización que está configurada para el aprovisionamiento de identidades en el clúster.

  1. Ve a github.com e inicia sesión en tu cuenta. GitHub

  2. Invita a los usuarios que necesiten clúster acceder a tu organización. GitHub Para obtener más información, consulte Invitar a los usuarios a unirse a su organización en la GitHub documentación.

  1. Otorgue los permisos de cluster-admin mediante el siguiente comando. Sustituya <IDP_USER_NAME> y <CLUSTER_NAME> por su nombre de usuario y clúster.

    rosa grant user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. Compruebe que el usuario aparezca como miembro del grupo de cluster-admins.

    rosa list users --cluster=<CLUSTER_NAME>

  1. Otorgue los permisos de dedicated-admin mediante el siguiente comando. Sustituya <IDP_USER_NAME> y <CLUSTER_NAME> por su clúster nombre de usuario.

    rosa grant user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. Compruebe que el usuario aparezca como miembro del grupo de cluster-admins.

    rosa list users --cluster=<CLUSTER_NAME>

Tras crear un usuario clúster administrador o añadir un usuario a su proveedor de identidad configurado, puede iniciar sesión en su cuenta a clúster través de la consola de Red Hat Hybrid Cloud.

  1. Obtenga la URL de la consola para clúster usted mediante el siguiente comando. <CLUSTER_NAME>Sustitúyala por el nombre de tu clúster.

    rosa describe cluster -c <CLUSTER_NAME> | grep Console

  2. Navegue hasta la URL de la consola en la salida e inicie sesión.

    • Si ha creado un usuario de cluster-admin, inicie sesión con las credenciales proporcionadas.

    • Si configuró un proveedor de identidad para usted clúster, elija el nombre del proveedor de identidad en el cuadro de diálogo Iniciar sesión con... y complete cualquier solicitud de autorización que presente su proveedor.

Desde la consola de la nube híbrida de Red Hat, puede implementar una aplicación de prueba del catálogo de desarrolladores y exponerla con una ruta.

  1. Diríjase a la Consola de la nube híbrida de Red Hat y seleccione el clúster en el que desea implementar la aplicación.

  2. En la página del clúster, seleccione Abrir consola.

  3. Desde la perspectiva Administrador, seleccione Inicio > Proyectos > Crear proyecto.

  4. Introduzca un nombre para el proyecto y, si lo desea, añada un Nombre de visualización y una Descripción.

  5. Seleccione Crear para crear el proyecto.

  6. Cambie a la perspectiva Desarrollador y seleccione +Añadir. Asegúrese de que el proyecto seleccionado sea el que se acaba de crear.

  7. En el cuadro de diálogo del Catálogo de desarrolladores, seleccione Todos los servicios.

  8. En la página del catálogo para desarrolladores, seleccione Idiomas > en el JavaScriptmenú.

  9. Elija Node.js y, a continuación, elija Crear aplicación para abrir la página Crear Source-to-Image aplicación.

    nota

    Puede que tenga que seleccionar Eliminar todos los filtros para que aparezca la opción Node.js.

  10. En la sección Git, seleccione Probar ejemplo.

  11. En el campo Nombre, agregue un nombre único.

  12. Seleccione Crear.

    nota

    La nueva aplicación tarda varios minutos en implementarse.

  13. Una vez finalizada la implementación, elija la URL de la ruta para la aplicación.

    Se abre una nueva pestaña en el navegador con un mensaje similar al siguiente.

    Welcome to your Node.js application on OpenShift

  14. (Opcional) Elimine la aplicación y limpie los recursos.

    1. Desde la perspectiva de Administrador, seleccione Inicio > Proyectos.

    2. Abra el menú de acciones del proyecto y seleccione Eliminar proyecto.

  1. Otorgue los permisos de cluster-admin mediante el siguiente comando. Sustituya <IDP_USER_NAME> y <CLUSTER_NAME> por su clúster nombre de usuario.

    rosa revoke user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. Compruebe que el usuario no figure como miembro del grupo de cluster-admins.

    rosa list users --cluster=<CLUSTER_NAME>

  1. Otorgue los permisos de dedicated-admin mediante el siguiente comando. Sustituya <IDP_USER_NAME> y <CLUSTER_NAME> por su clúster nombre de usuario.

    rosa revoke user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. Compruebe que el usuario no figure como miembro del grupo dedicated-admins.

    rosa list users --cluster=<CLUSTER_NAME>

Puede revocar el clúster acceso de un usuario del proveedor de identidades quitándolo del proveedor de identidades configurado.

Puede configurar diferentes tipos de proveedores de identidad para su clúster. El siguiente procedimiento revoca el clúster acceso de un miembro de una GitHub organización.

  1. Ve a github.com e inicia sesión en tu cuenta. GitHub

  2. Elimina al usuario de tu organización. GitHub Para obtener más información, consulte Eliminar a un miembro de su organización en la GitHub documentación.

Puede usar la ROSA CLI para eliminar una clúster que use AWS Security Token Service (AWS STS). También puede usar la ROSA CLI para eliminar las IAM funciones y el proveedor de OIDC creados por. ROSA Para eliminar las IAM políticas creadas por ROSA, puede utilizar la IAM consola.

importante

IAM las funciones y políticas creadas por ROSA pueden ser utilizadas por otros ROSA clústeres de la misma cuenta.

  1. Elimine los registros clúster y observe los mismos. Sustituya <CLUSTER_NAME> por el nombre o ID del clúster.

    rosa delete cluster --cluster=<CLUSTER_NAME> --watch
    importante

    Debe esperar clúster a que se eliminen por completo antes de eliminar las IAM funciones, las políticas y el proveedor de OIDC. Los roles de IAM de la cuenta son necesarios para eliminar los recursos creados por el instalador. Las funciones de IAM de los operadores son necesarias para limpiar los recursos creados por los operadores. OpenShift Los operadores utilizan el proveedor de OIDC para autenticar.

  2. Elimine el proveedor de OIDC que utilizan los clúster operadores para autenticarse ejecutando el siguiente comando.

    rosa delete oidc-provider -c <CLUSTER_ID> --mode auto

  3. Elimine las funciones de operador específicas del clúster. IAM 

    rosa delete operator-roles -c <CLUSTER_ID> --mode auto

  4. Elimine los roles de IAM de la cuenta mediante el siguiente comando. Sustituya <PREFIX> por el prefijo de los roles de IAM de la cuenta que desea eliminar. Si especificó un prefijo personalizado al crear los roles de IAM de la cuenta, especifique el prefijo predeterminado de ManagedOpenShift.

    rosa delete account-roles --prefix <PREFIX> --mode auto

  5. Elimine las IAM políticas creadas por. ROSA

    1. Inicie sesión en la consola de IAM.

    2. En el menú Administración de acceso de la izquierda, seleccione Políticas.

    3. Seleccione la política que desea eliminar y elija Acciones > Eliminar.

    4. Introduzca el nombre de la política y seleccione Eliminar.

    5. Repita este paso para eliminar cada una de las políticas de IAM para el clúster.