View a markdown version of this page

を使用する ROSA Classic クラスターを作成する AWS PrivateLink - Red Hat OpenShift Service on AWS

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

を使用する ROSA Classic クラスターを作成する AWS PrivateLink

ROSA クラシッククラスターは、パブリック、プライベート、プライベートのいくつかの方法でデプロイできます AWS PrivateLink。ROSA Classic の詳細については、「」を参照してくださいROSA アーキテクチャ。パブリック設定とプライベート クラスター 設定の両方で、OpenShift クラスター はインターネットにアクセスでき、プライバシーはアプリケーションレイヤーのアプリケーションワークロードに設定されます。

クラスター とアプリケーションワークロードの両方をプライベートにする必要がある場合は、ROSA Classic AWS PrivateLink を使用して を設定できます。 AWS PrivateLink は、 ROSA を使用して、 AWS カスタマーアカウントの ROSA サービスとクラスターリソース間にプライベート接続を作成する、可用性が高くスケーラブルなテクノロジーです。を使用すると AWS PrivateLink、Red Hat サイト信頼性エンジニアリング (SRE) チームは、クラスターの AWS PrivateLink エンドポイントに接続されたプライベートサブネットを使用して、サポートと修復の目的でクラスターにアクセスできます。

詳細については AWS PrivateLink、「 とは」を参照してください AWS PrivateLink。

に記載されている前提条件となるアクションを完了しますを使用するように をセットアップする ROSA

次の手順では、クラスターをホストするために使用できる Amazon VPC アーキテクチャを作成します。すべての クラスター リソースはプライベートサブネットでホストされます。パブリックサブネットは、プライベートサブネットからのアウトバウンドトラフィックを NAT ゲートウェイ経由でパブリックインターネットにルーティングします。この例では、 Amazon VPCに CIDR ブロック 10.0.0.0/16 を使用しています。別の CIDR ブロックを選択することもできます。詳細については、「VPC のサイズ設定」を参照してください。

重要

Amazon VPC 要件を満たさない場合、クラスターの作成は失敗します。

Amazon VPC console
  1. Amazon VPC コンソール を開きます。

  2. VPC ダッシュボードで、[Create VPC (VPC を作成する)] を選択します。

  3. [Resources to create] (作成するリソース) で、[VPC and more] (VPC など) を選択します。

  4. [名前タグの自動生成] を選択したままにすると VPC リソース用の名前タグが作成され、オフにすると VPC リソース用の独自の名前タグが作成されます。

  5. [IPv4 CIDR ブロック] に VPC の IPv4 アドレス範囲を入力します。VPC には IPv4 アドレス範囲が必要です。

  6. (オプション) IPv6 トラフィックをサポートするには、IPv6 CIDR ブロック、Amazon 提供の IPv6 CIDR ブロックを選択します。

  7. テナンシーは のままにしますDefault

  8. アベイラビリティーゾーンの数 (AZs) で、必要な数を選択します。マルチ AZ 配置の場合、 には 3 つのアベイラビリティーゾーン ROSA が必要です。サブネットの AZ を選択するには、[AZ のカスタマイズ] を展開します。

    注記

    一部の ROSA インスタンスタイプは、一部のアベイラビリティーゾーンでのみ使用できます。 ROSA CLI rosa list instance-types コマンドを使用して、使用可能なすべての ROSA インスタンスタイプを一覧表示できます。特定のアベイラビリティーゾーンでインスタンスタイプが使用可能かどうかを確認するには、 AWS CLI コマンド を使用しますaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>"

  9. サブネットを設定するには、[パブリックサブネットの数][プライベートサブネットの数] の値を選択します。サブネットの IP アドレス範囲を選択するには、[サブネット CIDR ブロックをカスタマイズ] を展開します。

    注記

    ROSA では、クラスターの作成に使用するアベイラビリティーゾーンごとに少なくとも 1 つのプライベートサブネットを設定する必要があります。

  10. プライベートサブネット内のリソースに IPv4 経由でパブリックインターネットへのアクセスを許可するには、NAT ゲートウェイの場合は、NAT ゲートウェイを作成する AZs の数を選択します。本番環境では、パブリックインターネットへのアクセスを必要とするリソースがある各 AZ に NAT ゲートウェイをデプロイすることをお勧めします。

  11. (オプション) VPC Amazon S3 から直接 にアクセスする必要がある場合は、VPC エンドポイント、S3 Gateway を選択します。

  12. デフォルトの DNS オプションを選択したままにします。VPC での DNS ホスト名のサポート ROSA が必要です。

  13. [Create VPC(VPC の作成)] を選択します。

AWS CLI
  1. 10.0.0.0/16 CIDR ブロックを持つ VPC を作成します。

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

    前述のコマンドは VPC ID を返します。以下に出力例を示します。

    vpc-1234567890abcdef0
  2. VPC ID を 環境変数に保存します。

    export VPC_ID=vpc-1234567890abcdef0
  3. VPC_ID 環境変数を使用して、VPC のNameタグを作成します。

    aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC
  4. VPC で DNS ホスト名サポートを有効にします。

    aws ec2 modify-vpc-attribute \ --vpc-id $VPC_ID \ --enable-dns-hostnames
  5. VPC にパブリックサブネットとプライベートサブネットを作成し、リソースを作成するアベイラビリティーゾーンを指定します。

    重要

    ROSA では、クラスターの作成に使用するアベイラビリティーゾーンごとに少なくとも 1 つのプライベートサブネットを設定する必要があります。マルチ AZ 配置の場合、3 つのアベイラビリティーゾーンが必要です。これらの要件を満たさないと、クラスターの作成は失敗します。

    注記

    一部の ROSA インスタンスタイプは、一部のアベイラビリティーゾーンでのみ使用できます。 ROSA CLI rosa list instance-types コマンドを使用して、使用可能なすべての ROSA インスタンスタイプを一覧表示できます。特定のアベイラビリティーゾーンでインスタンスタイプが使用可能かどうかを確認するには、 AWS CLI コマンド を使用しますaws 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. パブリックサブネット ID とプライベートサブネット IDsを環境変数に保存します。

    export PUBLIC_SUB=subnet-1234567890abcdef0 export PRIVATE_SUB=subnet-0987654321fedcba0
  7. アウトバウンドトラフィックのインターネットゲートウェイとルートテーブルを作成します。プライベートトラフィックのルートテーブルと Elastic IP アドレスを作成します。

    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. IDsを環境変数に保存します。

    export IGW=igw-1234567890abcdef0 export PUBLIC_RT=rtb-0987654321fedcba0 export EIP=eipalloc-0be6ecac95EXAMPLE export PRIVATE_RT=rtb-1234567890abcdef0
  9. インターネットゲートウェイを VPC にアタッチします。

    aws ec2 attach-internet-gateway \ --vpc-id $VPC_ID \ --internet-gateway-id $IGW
  10. パブリックルートテーブルをパブリックサブネットに関連付け、インターネットゲートウェイにルーティングするようにトラフィックを設定します。

    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. NAT ゲートウェイを作成し、Elastic IP アドレスに関連付けて、プライベートサブネットへのトラフィックを有効にします。

    aws ec2 create-nat-gateway \ --subnet-id $PUBLIC_SUB \ --allocation-id $EIP \ --query NatGateway.NatGatewayId \ --output text
  12. プライベートルートテーブルをプライベートサブネットに関連付け、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. (オプション) マルチ AZ 配置の場合は、上記のステップを繰り返して、パブリックサブネットとプライベートサブネットでさらに 2 つのアベイラビリティーゾーンを設定します。

ROSA CLI と を使用して AWS PrivateLink 、単一のアベイラビリティーゾーン (シングル AZ) または複数のアベイラビリティーゾーン (マルチ AZ) クラスター を持つ を作成できます。いずれの場合も、マシンの CIDR 値は VPC の CIDR 値と一致する必要があります。

次の手順では、 rosa create cluster コマンドを使用して ROSA Classic を作成します クラスター。マルチ AZ を作成するには クラスター、 コマンド--multi-azで を指定し、プロンプトが表示されたら使用するプライベートサブネット IDsを選択します。

注記

ファイアウォールを使用する場合は、 が機能するために必要なサイト ROSA にアクセスできるように設定する必要があります。

詳細については、Red Hat ドキュメントのAWS PrivateLink クラスターを使用するための要件」を参照してください。

  1. --mode auto または を使用して、必要な IAM アカウントロールとポリシーを作成します--mode manual

  2. 次のいずれかのコマンド クラスター を実行して、 を作成します。

    • シングル AZ

      rosa create cluster --private-link --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16 --subnet-ids=<PRIVATE_SUBNET_ID>
    • マルチ AZ

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

      AWS Security Token Service (AWS STS) の存続期間の短い認証情報 AWS PrivateLink を使用するクラスターを作成するには、 rosa create cluster コマンドの最後に --sts --mode manual --sts --mode autoまたは を追加します。

  3. インタラクティブプロンプトに従って クラスター オペレーター IAM ロールを作成します。

    rosa create operator-roles --interactive -c <CLUSTER_NAME>
  4. クラスター オペレーターが認証に使用する OpenID Connect (OIDC) プロバイダーを作成します。

    rosa create oidc-provider --interactive -c <CLUSTER_NAME>
  5. のステータスを確認します クラスター。

    rosa describe cluster -c <CLUSTER_NAME>
    注記

    State フィールドのステータス クラスター が表示されるまでに最大 40 分かかる場合がありますready。プロビジョニングが失敗した場合、または 40 分ready後に と表示されない場合は、「」を参照してくださいトラブルシューティング。サポートが必要な場合は、 サポート 「」または「Red Hat サポート」を参照してくださいROSA サポートを受ける

  6. OpenShift インストーラログを監視して、 クラスター 作成の進行状況を追跡します。

    rosa logs install -c <CLUSTER_NAME> --watch

を使用するクラスターは、パブリックホストゾーンとプライベートホストゾーン AWS PrivateLink を作成します Route 53。 Route 53 プライベートホストゾーン内のレコードは、割り当てられた VPC 内からのみ解決できます。

Let's Encrypt DNS-01 の検証では、有効で公的に信頼されている証明書をドメイン用に発行できるようにパブリックゾーンが必要です。Let's Encrypt の検証が完了すると、検証レコードは削除されます。そのゾーンはこれらの証明書の発行と更新にも必要で、通常は 60 日ごとに求められます。通常、これらのゾーンは空のように見えますが、検証プロセスではパブリックゾーンが重要な役割を果たします。

AWS プライベートホストゾーンの詳細については、「プライベートゾーンの使用」を参照してください。パブリックホストゾーンの設定の詳細については、「パブリックホストゾーンの使用」を参照してください。

  1. api.<cluster_domain> や などのレコードを VPC の外部*.apps.<cluster_domain>で解決できるようにするには、 Route 53 Resolver インバウンドエンドポイントを設定します

    注記

    インバウンドエンドポイントを設定する場合、冗長性を確保するために最低 2 つの IP アドレスを指定する必要があります。少なくとも 2 つのアベイラビリティーゾーンで IP アドレスを指定することをお勧めします。必要に応じて、それらのアベイラビリティーゾーンまたは他のアベイラビリティーゾーンに追加の IP アドレスを指定できます。

  2. インバウンドエンドポイントを設定するときは、クラスターの作成時に使用された VPC とプライベートサブネットを選択します。

Route 53 Resolver 内部エンドポイントが関連付けられて動作したら、ネットワーク上の指定されたサーバーが DNS クエリを処理できるように DNS 転送を設定します。

  1. DNS クエリをトップレベルドメイン (drow-pl-01.htno.p1.openshiftapps.com など) の IP アドレスに転送するように企業ネットワークを設定します。

  2. DNS クエリをある VPC から別の VPC に転送する場合は、「転送ルールの管理」の手順に従ってください。

  3. リモートネットワークの DNS サーバーを設定する場合は、使用している DNS サーバーのドキュメントを参照して、インストールしたクラスタードメインの選択的 DNS 転送を設定してください。

ROSA には組み込みの OAuth サーバーが含まれています。 ROSA クラスター を作成したら、ID プロバイダを使用するように OAuth を設定する必要があります。次に、設定した ID プロバイダーにユーザーを追加すると、そのユーザーに クラスターへのアクセス権を付与できます。必要に応じて、これらのユーザーに cluster-admin または dedicated-admin 権限を付与できます。

クラスターにはさまざまな ID プロバイダータイプを設定できます。サポートされているタイプには、GitHub、GitHub Enterprise、GitLab、Google、LDAP、OpenID Connect、および HTPasswd ID プロバイダーが含まれます。

重要

HTPasswd ID プロバイダーは、単一の静的な管理者ユーザーを作成できるようにするためだけに組み込まれています。HTPasswd は ROSAにおける汎用の ID プロバイダーとしてはサポートされていません。

以下の手順では、例として GitHub ID プロバイダーを設定します。サポートされている各 ID プロバイダータイプを設定する方法については、「AWS STS用 ID プロバイダーの設定」を参照してください。

  1. github.com に移動し、GitHub アカウントにログインします。

  2. ROSA クラスターの ID プロビジョニングに使用する GitHub 組織がない場合は、新規に作成します。詳細については、GitHub ドキュメントの手順を参照してください。

  3. CLI ROSA のインタラクティブモードを使用して、次のコマンドを実行してクラスターの ID プロバイダーを設定します。

    rosa create idp --cluster=<CLUSTER_NAME> --interactive
  4. 出力の設定プロンプトに従って、GitHub 組織のメンバー クラスター へのアクセスを制限します。

    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. 出力内の URL を開き、<GITHUB_ORG_NAME> を GitHub 組織の名前に置き換えます。

  6. GitHub ウェブページで、[アプリケーションを登録] を選択して、新しい OAuth アプリケーションを GitHub 組織に登録します。

  7. GitHub OAuth ページの情報を使用して残りの rosa create idp インタラクティブプロンプトを入力します。<GITHUB_CLIENT_ID><GITHUB_CLIENT_SECRET> は、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.
    注記

    ID プロバイダーの設定が有効になるまでに約 2 分かかる場合があります。cluster-admin ユーザーを設定した場合は、oc get pods -n openshift-authentication --watch コマンドを実行して OAuth ポッドが更新された設定で再デプロイされることを確認できます。

  8. ID プロバイダーが正しく設定されていることを確認します。

    rosa list idps --cluster=<CLUSTER_NAME>

設定済みの ID プロバイダーに追加 クラスター することで、 へのアクセス権をユーザーに付与できます。

以下の手順では、クラスターに ID をプロビジョニングするように設定されている GitHub 組織にユーザーを追加します。

  1. github.com に移動し、GitHub アカウントにログインします。

  2. GitHub 組織 クラスター へのアクセスを必要とするユーザーを招待します。詳細については、GitHub ドキュメントの「ユーザーを組織に招待する」を参照してください。

  1. 次のコマンドを入力して cluster-admin 権限を付与します。<IDP_USER_NAME><CLUSTER_NAME> をお使いのユーザー名とクラスター名に置き換えます。

    rosa grant user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
  2. ユーザーが cluster-admins グループのメンバーとしてリストされていることを確認します。

    rosa list users --cluster=<CLUSTER_NAME>
  1. 次のコマンドを入力して dedicated-admin 権限を付与します。<IDP_USER_NAME> と を自分のユーザー名とパスワード<CLUSTER_NAME>に置き換えます クラスター 。

    rosa grant user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
  2. ユーザーが cluster-admins グループのメンバーとしてリストされていることを確認します。

    rosa list users --cluster=<CLUSTER_NAME>

クラスター 管理者ユーザーを作成した後、または設定された ID プロバイダーにユーザーを追加したら、Red Hat Hybrid Cloud Console クラスター を使用して にログインできます。

  1. 次のコマンド クラスター を使用して、 のコンソール URL を取得します。を の名前<CLUSTER_NAME>に置き換えます クラスター。

    rosa describe cluster -c <CLUSTER_NAME> | grep Console
  2. 出力内のコンソール URL に移動し、ログインします。

    • cluster-admin ユーザーを作成した場合は、提供された認証情報を使用してログインします。

    • の ID プロバイダーを設定した場合は クラスター、Log in with... ダイアログで ID プロバイダー名を選択し、プロバイダーから提示された認可リクエストを完了します。

Red Hat Hybrid Cloud Console から、開発者カタログのテストアプリケーションをデプロイし、ルートを使用して公開できます。

  1. Red Hat Hybrid Cloud Console に移動し、アプリケーションをデプロイするクラスターを選択します。

  2. クラスターのページで、[コンソールを開く] を選択します。

  3. 管理者パースペクティブで、[ホーム] > [プロジェクト] > [プロジェクトを作成] を選択します。

  4. プロジェクトの名前を入力し、オプションで [表示名][説明] を追加します。

  5. [作成] を選択してプロジェクトを作成します。

  6. 開発者パースペクティブに切り替えて [+追加] を選択します。選択したプロジェクトが、今作成したプロジェクトであることを確認してください。

  7. [開発者カタログ] ダイアログで、[すべてのサービス] を選択します。

  8. [開発者カタログ] ページで、メニューから[言語] > [JavaScript] を選択します。

  9. [Node.js] を選択し、[アプリケーションの作成] を選択して [Source-to-Image アプリケーションの作成] ページを開きます。

    注記

    Node.js オプションを表示するには、[すべてのフィルターをクリア] を選択する必要がある場合があります。

  10. [Git] セクションで、[サンプルを試す] を選択します。

  11. [名前] フィールドに、一意の名前を追加します。

  12. [作成] を選択します。

    注記

    新しいアプリケーションのデプロイには数分かかります。

  13. デプロイが完了したら、アプリケーションのルート URL を選択します。

    ブラウザの新しいタブが開き、次のようなメッセージが表示されます。

    Welcome to your Node.js application on OpenShift
  14. (オプション) アプリケーションを削除し、リソースをクリーンアップします。

    1. 管理者パースペクティブで、[ホーム] > [プロジェクト] を選択します。

    2. プロジェクトのアクションメニューを開き、[プロジェクトを削除] を選択します。

  1. 次のコマンドを使用して cluster-admin 権限を無効にします。<IDP_USER_NAME> と を自分のユーザー名とパスワード<CLUSTER_NAME>に置き換えます クラスター 。

    rosa revoke user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
  2. ユーザーが cluster-admins グループのメンバーとしてリストされていないことを確認します。

    rosa list users --cluster=<CLUSTER_NAME>
  1. 次のコマンドを使用して dedicated-admin 権限を無効にします。<IDP_USER_NAME> と を自分のユーザー名とパスワード<CLUSTER_NAME>に置き換えます クラスター 。

    rosa revoke user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
  2. ユーザーが dedicated-admins グループのメンバーとしてリストされていないことを確認します。

    rosa list users --cluster=<CLUSTER_NAME>

ID プロバイダーユーザーの クラスター アクセスを取り消すには、設定された ID プロバイダーから削除します。

クラスターにはさまざまな ID プロバイダータイプを設定できます。次の手順では、GitHub 組織のメンバーの クラスター アクセスを取り消します。

  1. github.com に移動し、GitHub アカウントにログインします。

  2. GitHub 組織からユーザーを削除します。詳細については、GitHub ドキュメントの「組織からのメンバーアカウントの削除」を参照してください。

CLI を使用して、 AWS Security Token Service () ROSA クラスター を使用する を削除できますAWS STS。 ROSA CLI を使用して、 によって作成された IAM ロールと OIDC プロバイダーを削除することもできます ROSA。によって作成された IAM ポリシーを削除するには ROSA、 IAM コンソールを使用できます。

重要

IAM によって作成された ロールとポリシーは、同じアカウントの他の ROSA クラスターで使用される ROSA 場合があります。

  1. を削除 クラスター し、ログを監視します。<CLUSTER_NAME> を クラスターの名前または ID で置き換えます。

    rosa delete cluster --cluster=<CLUSTER_NAME> --watch
    重要

    IAM ロール クラスター 、ポリシー、および OIDC プロバイダーを削除する前に、 が完全に削除されるのを待つ必要があります。インストーラーが作成したリソースを削除するには、アカウント IAM ロールが必要です。OpenShift オペレーターが作成したリソースをクリーンアップするには、オペレーター IAM ロールが必要です。オペレーターは OIDC プロバイダーを使用して認証します。

  2. 次のコマンドを実行して、 クラスター オペレーターが認証に使用する OIDC プロバイダーを削除します。

    rosa delete oidc-provider -c <CLUSTER_ID> --mode auto
  3. クラスター固有のオペレーター IAM ロールを削除します。

    rosa delete operator-roles -c <CLUSTER_ID> --mode auto
  4. 以下のコマンドを使用してアカウントの IAM ロールを削除します。<PREFIX> を、削除するアカウントの IAM ロールのプレフィックスに置き換えます。アカウントの IAM ロールの作成時にカスタムプレフィックスを指定した場合は、デフォルトの ManagedOpenShift プレフィックスを指定します。

    rosa delete account-roles --prefix <PREFIX> --mode auto
  5. によって作成された IAM ポリシーを削除します ROSA。

    1. IAM コンソールにログインします。

    2. [アクセス管理] の左側のパネルで、[ポリシー] をクリックします。

    3. 削除するポリシーを選択し、[アクション] > [削除] を選択します。

    4. ポリシー名を入力し、[削除] を選択します。

    5. このステップを繰り返して、 クラスターの各 IAM ポリシーを削除します。