検索

19.5. Amazon Web Services Security Token Service での手動モードの使用

download PDF

STS を使用した手動モードは Amazon Web Services (AWS) でサポートされます。

注記

このクレデンシャルストラテジーは、新しい OpenShift Container Platform クラスターでのみサポートされており、インストール中に設定する必要があります。この機能を使用するために、既存のクラスターが別のクレデンシャルストラテジーを使用するように再設定することはできません。

19.5.1. AWS Security Token Service での手動モード

STS での手動モードでは、個別の OpenShift Container Platform クラスターコンポーネントは AWS Security Token Service (STS) を使用して、短期的かつ権限が制限されたセキュリティー認証情報を提供する IAM ロールをコンポーネントに割り当てます。これらの認証情報は、AWS API 呼び出しを行う各コンポーネントに固有の IAM ロールに関連付けられます。

19.5.1.1. AWS Security Token Service の認証プロセス

AWS Security Token Service (STS) と AssumeRole API アクションを使用すると、Pod が IAM ロールポリシーで定義されたアクセスキーを取得できるようになります。

OpenShift Container Platform クラスターには、Kubernetes サービスアカウント署名サービスが組み込まれています。このサービスは、秘密鍵を使用してサービスアカウント JSON Web トークン (JWT) に署名します。サービスアカウントトークンを必要とする Pod は、Pod 仕様を通じてサービスアカウントトークンを要求します。Pod が作成されてノードに割り当てられると、そのノードがサービスアカウント署名サービスから署名付きサービスアカウントを取得し、それを Pod にマウントします。

STS を使用するクラスターでは、Kubernetes 設定シークレットに IAM ロール ID が含まれています。ワークロードは、この IAM ロール ID のアイデンティティーを引き継ぎます。ワークロードに発行された署名付きサービスアカウントトークンが AWS の設定と一致するため、AWS STS は指定された IAM ロールのアクセスキーをワークロードに付与できます。

AWS STS は、次の条件を満たすサービスアカウントトークンを含む要求に対してのみアクセスキーを付与します。

  • トークンの名前と namespace が、サービスアカウントの名前と namespace と一致している。
  • トークンが公開鍵と一致する鍵によって署名されている。クラスターで使用されるサービスアカウント署名鍵の公開鍵ペアは、AWS S3 バケットに保存されます。AWS STS のフェデレーションによって、サービスアカウントトークンの署名が S3 バケットに保存されている公開鍵と一致していることが検証されます。

19.5.1.2. AWS STS の認証フロー

次の図は、AWS STS を使用する場合の AWS と OpenShift Container Platform クラスター間の認証フローを示しています。

  • トークン署名 は、OpenShift Container Platform クラスター上の Kubernetes サービスアカウント署名サービスです。
  • Pod 内の Kubernetes サービスアカウント は、署名付きサービスアカウントトークンです。

図19.2 AWS Security Token Service の認証フロー

AWS STS 使用時の AWS とクラスター間の詳細な認証フロー

新しい認証情報と更新された認証情報の要求は、適切に設定された AWS IAM OpenID Connect (OIDC) ID プロバイダーと AWS IAM ロールを組み合わせて使用することで自動化されます。AWS IAM によって信頼されているサービスアカウントトークンは、OpenShift Container Platform によって署名されており、Pod に展開して認証に使用できます。

19.5.1.3. AWS STS のトークン更新

Pod が使用する署名付きサービスアカウントトークンは、一定期間が経過すると期限切れになります。AWS STS を使用するクラスターの場合、この期間は 3600 秒、つまり 1 時間です。

トークンの更新は、Pod が割り当てられているノード上の kubelet により実行されます。kubelet は、トークンの有効期間の 80% を超えると、トークンのローテーションを試みます。

19.5.1.4. AWS STS の OpenID Connect の要件

OIDC 設定の暗号鍵のパブリック部分は、パブリックまたはプライベート S3 バケットに保存できます。

OIDC 仕様では HTTPS を使用する必要があります。AWS サービスは、OIDC ドキュメントを JSON Web Key Set (JWKS) 公開鍵の形式で公開するパブリックエンドポイントを必須としています。これにより、AWS サービスは、Kubernetes によって署名されたバインドされたトークンを検証し、証明書を信頼するかどうかを判断できるようになります。そのため、どちらの S3 バケットオプションでもパブリック HTTPS エンドポイントは必要です。プライベートエンドポイントはサポートされません。

AWS STS を使用するには、AWS STS サービスのパブリック AWS バックボーンが、パブリック S3 バケット、またはパブリック CloudFront エンドポイントを備えたプライベート S3 バケットと通信できる必要があります。インストール時に、CredentialsRequest オブジェクトの処理に使用するバケットのタイプを選択できます。

  • デフォルトでは、CCO ユーティリティー (ccoctl) が、OIDC 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。
  • または、ccoctl ユーティリティーで OIDC 設定をプライベート S3 バケットに保存し、そのバケットに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーからアクセスすることもできます。

19.5.1.5. AWS コンポーネントのシークレット形式

STS で手動モードを使用すると、個別の OpenShift Container Platform コンポーネントに提供される AWS 認証情報の内容が変更されます。次のシークレット形式を比較してください。

有効期間の長い認証情報を使用した AWS シークレット形式

apiVersion: v1
kind: Secret
metadata:
  namespace: <target-namespace> 1
  name: <target-secret-name> 2
data:
  aws_access_key_id: <base64-encoded-access-key-id>
  aws_secret_access_key: <base64-encoded-secret-access-key>

1
コンポーネントの namespace。
2
コンポーネントシークレットの名前。

STS での AWS シークレット形式

apiVersion: v1
kind: Secret
metadata:
  namespace: <target-namespace> 1
  name: <target-secret-name> 2
stringData:
  credentials: |-
    [default]
    sts_regional_endpoints = regional
    role_name: <operator-role-name> 3
    web_identity_token_file: <path-to-token> 4

1
コンポーネントの namespace。
2
コンポーネントシークレットの名前。
3
コンポーネントの IAM ロール。
4
Pod 内のサービスアカウントトークンへのパス。通常、これは OpenShift Container Platform コンポーネントの /var/run/secrets/openshift/serviceaccount/token です。

19.5.2. STS での手動モードに設定された OpenShift Container Platform クラスターのインストール

STS と共に手動モードを使用して Cloud Credential Operator (CCO) を使用するように設定されるクラスターをインストールするには、以下を実行します。

注記

STS を使用する際にクラスターは手動モードで動作するため、必要なパーミッションでコンポーネントの新規の認証情報を作成することはできません。OpenShift Container Platform の別のマイナーバージョンにアップグレードする際に、AWS パーミッションの要件が加わることがよくあります。STS を使用するクラスターをアップグレードする前に、クラスター管理者は、AWS パーミッションが既存のコンポーネントについて使用でき、新規コンポーネントで利用可能であることを手動で確認する必要があります。

19.5.2.1. Cloud Credential Operator ユーティリティーの設定

Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl) バイナリーを抽出して準備します。

注記

ccoctl ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) がインストールされている。
  • ccoctl ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。

    表19.3 必要な AWS パーミッション
    パーミッションのタイプ必須のパーミッション

    iam パーミッション

    • iam:CreateOpenIDConnectProvider
    • iam:CreateRole
    • iam:DeleteOpenIDConnectProvider
    • iam:DeleteRole
    • iam:DeleteRolePolicy
    • iam:GetOpenIDConnectProvider
    • iam:GetRole
    • iam:GetUser
    • iam:ListOpenIDConnectProviders
    • iam:ListRolePolicies
    • iam:ListRoles
    • iam:PutRolePolicy
    • iam:TagOpenIDConnectProvider
    • iam:TagRole

    s3 パーミッション

    • s3:CreateBucket
    • s3:DeleteBucket
    • s3:DeleteObject
    • s3:GetBucketAcl
    • s3:GetBucketTagging
    • s3:GetObject
    • s3:GetObjectAcl
    • s3:GetObjectTagging
    • s3:ListBucket
    • s3:PutBucketAcl
    • s3:PutBucketPolicy
    • s3:PutBucketPublicAccessBlock
    • s3:PutBucketTagging
    • s3:PutObject
    • s3:PutObjectAcl
    • s3:PutObjectTagging

    cloudfront パーミッション

    • cloudfront:ListCloudFrontOriginAccessIdentities
    • cloudfront:ListDistributions
    • cloudfront:ListTagsForResource

    OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、ccoctl ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。

    • cloudfront:CreateCloudFrontOriginAccessIdentity
    • cloudfront:CreateDistribution
    • cloudfront:DeleteCloudFrontOriginAccessIdentity
    • cloudfront:DeleteDistribution
    • cloudfront:GetCloudFrontOriginAccessIdentity
    • cloudfront:GetCloudFrontOriginAccessIdentityConfig
    • cloudfront:GetDistribution
    • cloudfront:TagResource
    • cloudfront:UpdateDistribution
    注記

    これらの追加のパーミッションは、ccoctl aws create-all コマンドで認証情報要求を処理する際の --create-private-s3-bucket オプションの使用をサポートします。

手順

  1. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージを取得します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    $ chmod 775 ccoctl

検証

  • ccoctl を使用する準備ができていることを確認するには、次のコマンドを実行してヘルプファイルを表示します。

    $ ccoctl --help

    ccoctl --help の出力

    OpenShift credentials provisioning tool
    
    Usage:
      ccoctl [command]
    
    Available Commands:
      alibabacloud Manage credentials objects for alibaba cloud
      aws          Manage credentials objects for AWS cloud
      gcp          Manage credentials objects for Google cloud
      help         Help about any command
      ibmcloud     Manage credentials objects for IBM Cloud
      nutanix      Manage credentials objects for Nutanix
    
    Flags:
      -h, --help   help for ccoctl
    
    Use "ccoctl [command] --help" for more information about a command.

19.5.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成

CCO ユーティリティー (ccoctl) を使用して、必要な AWS リソースを 個別に 作成したり、1 つのコマンドを使用して 作成したりできます。

19.5.2.2.1. AWS リソースの個別の作成

AWS リソースの変更前に ccoctl ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。たとえば、このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。

それ以外の場合は、ccoctl aws create-all コマンドを使用して AWS リソースを自動的に作成できます。

注記

デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。

一部の ccoctl コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json パラメーターを使用して適用できます。

前提条件

  • ccoctl バイナリーを展開して準備しておく。

手順

  1. クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例:

    2021/04/13 11:01:02 Generating RSA keypair
    2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private
    2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public
    2021/04/13 11:01:03 Copying signing key for use by installer

    serviceaccount-signer.private および serviceaccount-signer.public は、生成されるキーファイルです。

    このコマンドは、クラスターがインストール時に必要とするプライベートキーを /<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key に作成します。

  2. AWS で OpenID Connect アイデンティティープロバイダーおよび S3 バケットを作成します。

    $ ccoctl aws create-identity-provider \
    --name=<name> \
    --region=<aws_region> \
    --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public

    ここでは、以下のようになります。

    • <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    • <aws_region> は、クラウドリソースが作成される AWS リージョンです。
    • <path_to_ccoctl_output_dir> は、ccoctl aws create-key-pair コマンドが生成したパブリックキーファイルへのパスです。

    出力例:

    2021/04/13 11:16:09 Bucket <name>-oidc created
    2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated
    2021/04/13 11:16:10 Reading public key
    2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated
    2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com

    openid-configuration は検出ドキュメントであり、keys.json は JSON Web キーセットファイルです。

    このコマンドは、YAML 設定ファイルを /<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。

  3. クラスターの各コンポーネントについて IAM ロールを作成します。

    1. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。

      $ oc adm release extract --credentials-requests \
      --cloud=aws \
      --to=<path_to_directory_with_list_of_credentials_requests>/credrequests 1
      --from=quay.io/<path_to>/ocp-release:<version>
      1
      credrequests は、CredentialsRequest オブジェクトのリストが格納されるディレクトリーです。ディレクトリーが存在しない場合、このコマンドはディレクトリーを作成します。
    2. クラスターでクラスター機能を使用して 1 つ以上のオプションコンポーネントを無効にする場合は、無効なコンポーネントの CredentialsRequest カスタムリソースを削除します。

      AWS 上の OpenShift Container Platform 4.12 の credrequests ディレクトリーの内容の例

      0000_30_machine-api-operator_00_credentials-request.yaml 1
      0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml 2
      0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml 3
      0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 4
      0000_50_cluster-network-operator_02-cncc-credentials.yaml 5
      0000_50_cluster-storage-operator_03_credentials_request_aws.yaml 6

      1
      Machine API Operator CR が必要です。
      2
      Cloud Credential Operator CR が必要です。
      3
      Image Registry Operator CR が必要です。
      4
      Ingress Operator CR が必要です。
      5
      Network Operator CR が必要です。
      6
      Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。
    3. ccoctl ツールを使用して、credrequests ディレクトリーですべての CredentialsRequest オブジェクトを処理します。

      $ ccoctl aws create-iam-roles \
      --name=<name> \
      --region=<aws_region> \
      --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
      --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
      注記

      GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、--region パラメーターでリージョンを指定する必要もあります。

      クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

      それぞれの CredentialsRequest オブジェクトについて、ccoctl は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各 CredentialsRequest オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。

検証

  • OpenShift Container Platform シークレットが作成されることを確認するには、<path_to_ccoctl_output_dir>/manifests ディレクトリーのファイルを一覧表示します。

    $ ll <path_to_ccoctl_output_dir>/manifests

    出力例:

    total 24
    -rw-------. 1 <user> <user> 161 Apr 13 11:42 cluster-authentication-02-config.yaml
    -rw-------. 1 <user> <user> 379 Apr 13 11:59 openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml
    -rw-------. 1 <user> <user> 353 Apr 13 11:59 openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml
    -rw-------. 1 <user> <user> 355 Apr 13 11:59 openshift-image-registry-installer-cloud-credentials-credentials.yaml
    -rw-------. 1 <user> <user> 339 Apr 13 11:59 openshift-ingress-operator-cloud-credentials-credentials.yaml
    -rw-------. 1 <user> <user> 337 Apr 13 11:59 openshift-machine-api-aws-cloud-credentials-credentials.yaml

AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールのリスト表示について参照してください。

19.5.2.2.2. 単一コマンドでの AWS リソースの作成

AWS リソースの変更前に ccoctl ツールが作成する JSON ファイルを確認する必要がない場合で、ccoctl ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たす場合は、ccoctl aws create-all コマンドを使用して AWS リソースの作成を自動化できます。

それ以外の場合は、AWS リソースを個別に作成できます。

注記

デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。

前提条件

以下が必要になります。

  • ccoctl バイナリーを抽出して準備している。

手順

  1. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    $ oc adm release extract \
    --credentials-requests \
    --cloud=aws \
    --to=<path_to_directory_with_list_of_credentials_requests>/credrequests \ 1
    --from=quay.io/<path_to>/ocp-release:<version>
    1
    credrequests は、CredentialsRequest オブジェクトのリストが格納されるディレクトリーです。ディレクトリーが存在しない場合、このコマンドはディレクトリーを作成します。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  2. クラスターでクラスター機能を使用して 1 つ以上のオプションコンポーネントを無効にする場合は、無効なコンポーネントの CredentialsRequest カスタムリソースを削除します。

    AWS 上の OpenShift Container Platform 4.12 の credrequests ディレクトリーの内容の例

    0000_30_machine-api-operator_00_credentials-request.yaml 1
    0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml 2
    0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml 3
    0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 4
    0000_50_cluster-network-operator_02-cncc-credentials.yaml 5
    0000_50_cluster-storage-operator_03_credentials_request_aws.yaml 6

    1
    Machine API Operator CR が必要です。
    2
    Cloud Credential Operator CR が必要です。
    3
    Image Registry Operator CR が必要です。
    4
    Ingress Operator CR が必要です。
    5
    Network Operator CR が必要です。
    6
    Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。
  3. ccoctl ツールを使用して、credrequests ディレクトリーですべての CredentialsRequest オブジェクトを処理します。

    $ ccoctl aws create-all \
      --name=<name> \1
      --region=<aws_region> \2
      --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \3
      --output-dir=<path_to_ccoctl_output_dir> \4
      --create-private-s3-bucket 5
    1
    追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    2
    クラウドリソースが作成される AWS リージョンです。
    3
    コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーを指定します。
    4
    オプション: ccoctl ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。
    5
    オプション: デフォルトでは、ccoctl ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket パラメーターを使用します。
    注記

    クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

検証

  • OpenShift Container Platform シークレットが作成されることを確認するには、<path_to_ccoctl_output_dir>/manifests ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例:

    cluster-authentication-02-config.yaml
    openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml
    openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml
    openshift-image-registry-installer-cloud-credentials-credentials.yaml
    openshift-ingress-operator-cloud-credentials-credentials.yaml
    openshift-machine-api-aws-cloud-credentials-credentials.yaml

AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールのリスト表示について参照してください。

19.5.2.3. インストーラーの実行

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定します。
  • OpenShift Container Platform リリースイメージを取得します。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、install-config.yaml ファイルを作成します。

    $ openshift-install create install-config --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  2. install-config.yaml 設定ファイルを編集し、credentialsMode パラメーターが Manual に設定されるようにします。

    サンプル install-config.yaml 設定ファイル

    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 1
    compute:
    - architecture: amd64
      hyperthreading: Enabled

    1
    この行は、credentialsMode パラメーターを Manual に設定するために追加されます。
  3. 必要な OpenShift Container Platform インストールマニフェストを作成します。

    $ openshift-install create manifests
  4. ccoctl によって生成されたマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。

    $ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
  5. ccoctltls ディレクトリーに生成したプライベートキーをインストールディレクトリーにコピーします。

    $ cp -a /<path_to_ccoctl_output_dir>/tls .
  6. OpenShift Container Platform インストーラーを実行します。

    $ ./openshift-install create cluster

19.5.2.4. インストールの検証

  1. OpenShift Container Platform クラスターに接続します。
  2. クラスターに root 認証情報がないことを確認します。

    $ oc get secrets -n kube-system aws-creds

    出力は以下のようになります。

    Error from server (NotFound): secrets "aws-creds" not found
  3. コンポーネントが、CCO によって作成される認証情報を使用するのではなく、シークレットマニフェストで指定された IAM ロールを持つことを確認します。

    Image Registry Operator を使用したコマンドの例

    $ oc get secrets -n openshift-image-registry installer-cloud-credentials -o json | jq -r .data.credentials | base64 --decode

    出力には、コンポーネントによって使用されるロールおよび Web アイデンティティートークンが表示され、以下のように表示されるはずです。

    Image Registry Operator を使用した出力例

    [default]
    role_arn = arn:aws:iam::123456789:role/openshift-image-registry-installer-cloud-credentials
    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

19.5.3. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.