View a markdown version of this page

Crie um cluster ROSA clássico que usa AWS PrivateLink - Serviço Red Hat OpenShift na AWS
Pré-requisitosCrie Amazon VPC arquiteturaCrie um cluster ROSA clássico usando a ROSA CLI e AWS PrivateLinkConfigurar o AWS PrivateLink encaminhamento de DNSConfigurar um provedor de identidade e conceder cluster acessoConceder acesso ao usuário a um clusterConfigurar permissões do cluster-adminConfigurar permissões do dedicated-adminAcesse um cluster por meio do Red Hat Hybrid Cloud ConsoleImplemente um aplicativo do Catálogo de DesenvolvedoresRevogue as permissões cluster-admin de um usuárioRevogue as permissões dedicated-admin de um usuárioRevogar o acesso do usuário a um clusterExcluir um cluster e AWS STS recursos

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Crie um cluster ROSA clássico que usa AWS PrivateLink

Os clusters clássicos do ROSA podem ser implantados de algumas maneiras diferentes: públicos, privados ou privados com AWS PrivateLink. Para obter mais informações sobre o ROSA classic, consulteROSA arquitetura. Para cluster configurações públicas e privadas, o OpenShift cluster tem acesso à Internet e a privacidade é definida nas cargas de trabalho do aplicativo na camada do aplicativo.

Se você precisar que as cargas de trabalho do aplicativo cluster e as do aplicativo sejam privadas, você pode configurar AWS PrivateLink com o ROSA classic. AWS PrivateLink é uma tecnologia altamente disponível e escalável ROSA usada para criar uma conexão privada entre o ROSA serviço e os recursos do cluster na conta do AWS cliente. Com isso AWS PrivateLink, a equipe de engenharia de confiabilidade de sites (SRE) da Red Hat pode acessar o cluster para fins de suporte e remediação usando uma sub-rede privada conectada ao endpoint do cluster. AWS PrivateLink

Para obter mais informações sobre AWS PrivateLink, consulte O que é AWS PrivateLink?

Conclua as ações de pré-requisito listadas em. Configurado para usar ROSA

O procedimento a seguir cria uma Amazon VPC arquitetura que pode ser usada para hospedar um cluster. Todos os cluster recursos estão hospedados na sub-rede privada. A sub-rede pública roteia o tráfego de saída da sub-rede privada por meio de um gateway NAT para a Internet pública. Este exemplo usa o bloco CIDR 10.0.0.0/16 para o Amazon VPC. No entanto, você pode escolher um bloco CIDR diferente. Para obter mais informações, consulte Dimensionamento da VPC.

Importante

Se Amazon VPC os requisitos não forem atendidos, a criação do cluster falhará.

exemplo
Amazon VPC console

  1. Abra o console do Amazon VPC.

  2. No painel da VPC, escolha Criar VPC.

  3. Em Resources to create (Recursos a serem criados), escolha VPC and more (VPC e mais).

  4. Mantenha a opção Geração automática de tags de nome selecionada para criar tags de nome para os recursos da VPC, ou desmarque-a para fornecer suas próprias tags de nome para os recursos da VPC.

  5. Para o bloco IPv4 CIDR, insira um intervalo de IPv4 endereços para a VPC. Uma VPC deve ter um intervalo de IPv4 endereços.

  6. (Opcional) Para oferecer suporte ao IPv6 tráfego, escolha bloco IPv6 CIDR, bloco CIDR fornecido pela Amazon IPv6 .

  7. Deixe a locação comoDefault.

  8. Em Número de zonas de disponibilidade (AZs), escolha o número necessário. Para implantações Multi-AZ, são ROSA necessárias três zonas de disponibilidade. Para escolher o AZs para suas sub-redes, expanda Personalizar. AZs

    nota

    Alguns tipos de ROSA instância só estão disponíveis em algumas zonas de disponibilidade. Você pode usar o rosa list instance-types comando ROSA CLI para listar todos os tipos de ROSA instância disponíveis. Para verificar se um tipo de instância está disponível para uma determinada zona de disponibilidade, use o 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 suas sub-redes, escolha valores para Número de sub-redes públicas e Número de sub-redes privadas. Para escolher os intervalos de endereços IP para suas sub-redes, expanda Personalizar blocos CIDR de sub-redes.

    nota

    ROSA exige que os clientes configurem pelo menos uma sub-rede privada por zona de disponibilidade usada para criar clusters.

  10. Para conceder aos recursos da sub-rede privada acesso à Internet pública por meio de IPv4, para gateways NAT, escolha o número AZs no qual criar gateways NAT. Em produção, recomendamos que você implante um gateway NAT em cada AZ com recursos que precisem de acesso à Internet pública.

  11. (Opcional) Se você precisar acessar Amazon S3 diretamente da sua VPC, escolha VPC endpoints, S3 Gateway.

  12. Deixe as opções de DNS padrão selecionadas. ROSA requer suporte a nomes de host DNS na VPC.

  13. Escolha Criar VPC.

AWS CLI

  1. Crie uma VPC com um bloco CIDR 10.0.0.0/16.

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

    O comando anterior retorna o ID da VPC. Veja a seguir um exemplo de saída.

    vpc-1234567890abcdef0

  2. Armazene o ID da VPC em uma variável de ambiente.

    export VPC_ID=vpc-1234567890abcdef0

  3. Crie uma Name tag para a VPC usando a variável de VPC_ID ambiente.

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

  4. Habilite o suporte ao nome de host DNS na VPC.

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

  5. Crie uma sub-rede pública e privada na VPC, especificando as zonas de disponibilidade em que os recursos devem ser criados.

    Importante

    ROSA exige que os clientes configurem pelo menos uma sub-rede privada por zona de disponibilidade usada para criar clusters. Para implantações Multi-AZ, são necessárias três zonas de disponibilidade. Se estes requisitos não forem atendidos, a criação do cluster falhará.

    nota

    Alguns tipos de ROSA instância só estão disponíveis em algumas zonas de disponibilidade. Você pode usar o rosa list instance-types comando ROSA CLI para listar todos os tipos de ROSA instância disponíveis. Para verificar se um tipo de instância está disponível para uma determinada zona de disponibilidade, use o 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. Armazene a sub-rede pública e privada IDs em variáveis de ambiente.

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

  7. Crie um gateway de internet e uma tabela de rotas para o tráfego de saída. Crie uma tabela de rotas e um endereço IP elástico para tráfego 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. Armazene IDs as variáveis de ambiente.

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

  9. Anexar o Gateway da Internet à VPC.

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

  10. Associe a tabela de rotas públicas à sub-rede pública e configure o tráfego para rotear para o gateway da 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. Crie o gateway NAT e associe-o ao endereço IP elástico para habilitar o tráfego para a sub-rede privada.

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

  12. Associe a tabela de rotas privadas à sub-rede privada e configure o tráfego para rotear para o gateway 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 implantações Multi-AZ, repita as etapas acima para configurar mais duas zonas de disponibilidade com sub-redes públicas e privadas.

Você pode usar a ROSA CLI e AWS PrivateLink criar uma cluster com uma única zona de disponibilidade (Single-AZ) ou várias zonas de disponibilidade (Multi-AZ). Em ambos os casos, o valor do CIDR da sua máquina deve coincidir com o valor do CIDR da sua VPC.

O procedimento a seguir usa o rosa create cluster comando para criar um ROSA clássico cluster. Para criar um Multi-AZ cluster, especifique --multi-az no comando e selecione a sub-rede privada IDs que você deseja usar quando solicitado.

nota

Se você usa um firewall, deve configurá-lo para que ROSA possa acessar os sites necessários para funcionar.

Para obter mais informações, consulte Requisitos para o uso de AWS PrivateLink clusters na documentação da Red Hat.

  1. Crie as funções e políticas de IAM conta necessárias usando --mode auto ou--mode manual.

    • rosa create account-roles --classic --mode auto

    • rosa create account-roles --classic --mode manual
      nota

      Se seu token de acesso off-line tiver expirado, a ROSA CLI exibirá uma mensagem de erro informando que seu token de autorização precisa ser atualizado. Para obter as etapas de solução de problemas, consulteSolucionar problemas de tokens de acesso off-line expirados na ROSA CLI.

  2. Crie um cluster executando um dos seguintes 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 criar um cluster que usa AWS PrivateLink com AWS Security Token Service (AWS STS) credenciais de curta duração, anexe --sts --mode auto ou --sts --mode manual ao final do comando. rosa create cluster

  3. Crie as IAM funções de cluster operador seguindo as instruções interativas.

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

  4. Crie o provedor OpenID Connect (OIDC) que os cluster operadores usam para autenticar.

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

  5. Verifique o status do seu cluster.

    rosa describe cluster -c <CLUSTER_NAME>
    nota

    Pode levar até 40 minutos para que o cluster State campo mostre o ready status. Se o provisionamento falhar ou não aparecer ready após 40 minutos, consulte. Solução de problemas Para entrar em contato com Suporte o suporte da Red Hat para obter assistência, consulteObtendo ROSA suporte.

  6. Acompanhe o progresso da cluster criação observando os registros do OpenShift instalador.

    rosa logs install -c <CLUSTER_NAME> --watch

Os clusters que usam AWS PrivateLink criam uma zona hospedada pública e uma zona hospedada privada em Route 53. Os registros na zona hospedada Route 53 privada só podem ser resolvidos na VPC à qual estão atribuídos.

A validação DNS-01 do Let's Encrypt requer uma zona pública para que certificados válidos e publicamente confiáveis possam ser emitidos para o domínio. Os registros de validação são excluídos após a conclusão da validação do Let's Encrypt. A zona ainda é necessária para emitir e renovar esses certificados, que geralmente são necessários a cada 60 dias. Embora essas zonas geralmente pareçam vazias, uma zona pública desempenha um papel crítico no processo de validação.

Para obter mais informações sobre zonas hospedadas AWS privadas, consulte Como trabalhar com zonas privadas. Para obter mais informações sobre zonas hospedadas, consulte Como trabalhar com zonas hospedadas.

  1. Para permitir registros como api.<cluster_domain> e *.apps.<cluster_domain> resolver fora da VPC, configure um endpoint de Route 53 Resolver entrada.

    nota

    Ao configurar um endpoint de entrada, é necessário especificar no mínimo dois endereços IP para redundância. É recomendável especificar endereços IP em pelo menos duas zonas de disponibilidade. Opcionalmente, você pode especificar endereços IP adicionais nessas ou em outras zonas de disponibilidade.

  2. Ao configurar o endpoint de entrada, selecione a VPC e as sub-redes privadas que foram usadas quando você criou o cluster.

Depois que o endpoint Route 53 Resolver interno estiver associado e operacional, configure o encaminhamento de DNS para que as consultas de DNS possam ser tratadas pelos servidores designados em sua rede.

  1. Configure sua rede corporativa para encaminhar consultas de DNS para esses endereços IP do domínio de nível superior, como drow-pl-01.htno.p1.openshiftapps.com.

  2. Se você estiver encaminhando consultas ao DNS de uma VPC para outra VPC, siga as instruções em Gerenciando regras de encaminhamento.

  3. Se estiver configurando o servidor DNS de sua rede remota, consulte a documentação específica do seu servidor DNS para configurar o encaminhamento seletivo de DNS para o domínio do cluster instalado.

ROSA inclui um OAuth servidor embutido. Depois que o seu ROSA cluster for criado, você deverá configurar OAuth para usar um provedor de identidade. Em seguida, você pode adicionar usuários ao provedor de identidade configurado para conceder a eles acesso ao seu cluster. Você pode conceder a esses usuários permissões cluster-admin ou dedicated-admin conforme necessário.

Você pode configurar diferentes tipos de provedores de identidade para o seu cluster. Os tipos compatíveis incluem GitHub Enterprise GitHub, Google GitLab, LDAP, OpenID Connect e provedores de identidade. HTPasswd

Importante

O provedor de HTPasswd identidade é incluído somente para permitir a criação de um único usuário administrador estático. HTPasswd não é suportado como provedor de identidade de uso geral para. ROSA

O procedimento a seguir configura um provedor de GitHub identidade como exemplo. Para obter instruções sobre como configurar cada um dos tipos de provedores de identidade compatíveis, consulte Configurando provedores de identidade para AWS STS.

  1. Navegue até github.com e faça login na sua GitHub conta.

  2. Se você não tiver uma GitHub organização para usar para provisionamento de identidade ROSA cluster, crie uma. Para obter mais informações, consulte as etapas na GitHub documentação.

  3. Usando o modo interativo da ROSA CLI, configure um provedor de identidade para seu cluster executando o comando a seguir.

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

  4. Siga as instruções de configuração na saída para restringir o cluster acesso aos membros da sua GitHub organização.

    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. Abra a URL na saída, <GITHUB_ORG_NAME> substituindo-a pelo nome da sua GitHub organização.

  6. Na página da GitHub web, escolha Registrar aplicativo para registrar um novo OAuth aplicativo em sua GitHub organização.

  7. Use as informações da GitHub OAuth página para preencher os prompts rosa create idp interativos restantes, substituindo <GITHUB_CLIENT_ID> e <GITHUB_CLIENT_SECRET> com as credenciais do seu aplicativo. GitHub OAuth 

    ...
? 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

    Pode levar cerca de dois minutos para que a configuração do provedor de identidade se torne ativa. Se você configurou um cluster-admin usuário, pode executar o oc get pods -n openshift-authentication --watch comando para observar a reimplantação OAuth dos pods com a configuração atualizada.

  8. Verifique se o provedor de identidade foi configurado corretamente.

    rosa list idps --cluster=<CLUSTER_NAME>

Você pode conceder a um usuário acesso ao seu cluster adicionando-o ao provedor de identidade configurado.

O procedimento a seguir adiciona um usuário a uma GitHub organização que está configurada para provisionamento de identidade no cluster.

  1. Navegue até github.com e faça login na sua GitHub conta.

  2. Convide usuários que precisam de cluster acesso à sua GitHub organização. Para obter mais informações, consulte Convidar usuários para participar da sua organização na GitHub documentação.

  1. Conceda as permissões cluster-admin usando o seguinte comando. Substitua <IDP_USER_NAME> e <CLUSTER_NAME> pelo nome do usuário e do cluster.

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

  2. Verifique se o usuário está listado como membro do grupo cluster-admins.

    rosa list users --cluster=<CLUSTER_NAME>

  1. Conceda as permissões dedicated-admin com o seguinte comando. <CLUSTER_NAME>Substitua <IDP_USER_NAME> e por seu usuário e cluster nome.

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

  2. Verifique se o usuário está listado como membro do grupo cluster-admins.

    rosa list users --cluster=<CLUSTER_NAME>

Depois de criar um usuário cluster administrador ou adicionar um usuário ao seu provedor de identidade configurado, você pode fazer login no seu cluster por meio do Red Hat Hybrid Cloud Console.

  1. Obtenha o URL do console para você cluster usando o comando a seguir. <CLUSTER_NAME>Substitua pelo nome do seu cluster.

    rosa describe cluster -c <CLUSTER_NAME> | grep Console

  2. Navegue até o URL do console na saída e faça login.

    • Se você criou um cluster-admin usuário, faça login usando as credenciais fornecidas.

    • Se você configurou um provedor de identidade para o seu cluster, escolha o nome do provedor de identidade na caixa de diálogo Fazer login com... e conclua todas as solicitações de autorização apresentadas pelo seu provedor.

No console de nuvem híbrida da Red Hat, você pode implantar um aplicativo de teste do Catálogo do desenvolvedor e expô-lo com uma rota.

  1. Navegue até o Console de nuvem híbrida da Red Hat e escolha o cluster no qual deseja implantar o aplicativo.

  2. Na página do cluster, escolha Abrir console.

  3. Na perspectiva do administrador, escolha Início > Projetos > Criar projeto.

  4. Insira um nome para seu projeto e, opcionalmente, adicione um nome de exibição e uma descrição.

  5. Selecione Criar para criar o projeto.

  6. Mude para a perspectiva do desenvolvedor e escolha +Adicionar. Certifique-se de que o projeto selecionado seja aquele que acabou de ser criado.

  7. Na caixa de diálogo Catálogo do desenvolvedor, escolha Todos os serviços.

  8. Na página Catálogo do desenvolvedor, escolha Idiomas > no JavaScriptmenu.

  9. Escolha Node.js e, em seguida, escolha Criar aplicativo para abrir a página Criar Source-to-Image aplicativo.

    nota

    Talvez seja necessário escolher Limpar todos os filtros para exibir a opção Node.js.

  10. Na seção Git, escolha Testar amostra.

  11. No campo Nome, adicione um nome exclusivo.

  12. Escolha Criar.

    nota

    O novo aplicativo leva alguns minutos para ser implantado.

  13. Quando a implantação estiver concluída, escolha o URL da rota para o aplicativo.

    Uma nova guia no navegador é aberta com uma mensagem semelhante à seguinte.

    Welcome to your Node.js application on OpenShift

  14. (Opcional) Exclua o aplicativo e limpe os recursos:

    1. Na perspectiva do Administrador, escolha Início > Projetos.

    2. Abra o menu de ação do seu projeto e escolha Excluir projeto.

  1. Revogue as permissões cluster-admin usando o seguinte comando. <CLUSTER_NAME>Substitua <IDP_USER_NAME> e por seu usuário e cluster nome.

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

  2. Verifique se o usuário não está listado como membro do grupo cluster-admins.

    rosa list users --cluster=<CLUSTER_NAME>

  1. Revogue as permissões dedicated-admin usando o seguinte comando. <CLUSTER_NAME>Substitua <IDP_USER_NAME> e por seu usuário e cluster nome.

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

  2. Verifique se o usuário não está listado como membro do grupo dedicated-admins.

    rosa list users --cluster=<CLUSTER_NAME>

Você pode revogar o cluster acesso de um usuário do provedor de identidade removendo-o do provedor de identidade configurado.

Você pode configurar diferentes tipos de provedores de identidade para o seu cluster. O procedimento a seguir revoga o cluster acesso de um membro de uma GitHub organização.

  1. Navegue até github.com e faça login na sua GitHub conta.

  2. Remova o usuário da sua GitHub organização. Para obter mais informações, consulte Removendo um membro da sua organização na GitHub documentação.

Você pode usar a ROSA CLI para excluir uma cluster que usa AWS Security Token Service ()AWS STS. Você também pode usar a ROSA CLI para excluir as IAM funções e o provedor OIDC criados por. ROSA Para excluir as IAM políticas criadas por ROSA, você pode usar o IAM console.

Importante

IAM funções e políticas criadas por ROSA podem ser usadas por outros ROSA clusters na mesma conta.

  1. Exclua o cluster e observe os registros. Substitua <CLUSTER_NAME> pelo nome ou ID do seu cluster.

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

    Você deve aguardar cluster a exclusão completa antes de remover as IAM funções, as políticas e o provedor OIDC. As perfis do IAM da conta são necessárias para excluir os recursos criados pelo instalador. As funções do operador IAM são necessárias para limpar os recursos criados pelos OpenShift operadores. Os operadores utilizam o provedor OIDC para autenticação.

  2. Exclua o provedor OIDC que os cluster operadores usam para autenticar executando o comando a seguir.

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

  3. Exclua as funções de operador específicas do cluster. IAM 

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

  4. Exclua os perfis do IAM da conta usando o comando a seguir. Substitua <PREFIX> pelo prefixo das perfis do IAM da conta a serem excluídas. Se você especificou um prefixo personalizado ao criar as perfis do IAM da conta, especifique o prefixo padrão ManagedOpenShift.

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

  5. Exclua IAM as políticas criadas por ROSA.

    1. Fazer login no console do IAM.

    2. No menu à esquerda, em Gerenciamento de acesso, escolha Políticas.

    3. Selecione a política que deseja excluir e escolha Ações > Excluir.

    4. Insira o nome da política e escolha Excluir.

    5. Repita essa etapa para excluir cada uma das políticas do IAM para o cluster.