19.6. GCP ワークロード ID で手動モードを使用する

Google Cloud Platform (GCP) では、GCP ワークロード ID を使用した手動モードがサポートされています。

注記

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

19.6.1. GCP Workload ID の手動モードについて

GCP ワークロード ID を使用する手動モードでは、個々の OpenShift Container Platform クラスターコンポーネントは、短期間の限定された特権のクレデンシャルを使用して IAM サービスアカウントを偽装できます。

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

図19.3 Workload ID の認証フロー

GCP Workload ID を使用する場合の GCP とクラスター間の詳細な認証フロー

GCP Workload Identity で手動モードを使用すると、個々の OpenShift Container Platform コンポーネントに提供される GCP クレデンシャルのコンテンツが変更されます。

GCP シークレットフォーマット

apiVersion: v1
kind: Secret
metadata:
  namespace: <target_namespace> 1
  name: <target_secret_name> 2
data:
  service_account.json: <service_account> 3

1
コンポーネントの namespace。
2
コンポーネントシークレットの名前。
3
Base64 でエンコードされたサービスアカウント。

長期間有効なクレデンシャルを使用した Base64 でエンコードされた service_account.json ファイルのコンテンツ

{
   "type": "service_account", 1
   "project_id": "<project_id>",
   "private_key_id": "<private_key_id>",
   "private_key": "<private_key>", 2
   "client_email": "<client_email_address>",
   "client_id": "<client_id>",
   "auth_uri": "https://accounts.google.com/o/oauth2/auth",
   "token_uri": "https://oauth2.googleapis.com/token",
   "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
   "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/<client_email_address>"
}

1
クレデンシャルの種類は service_account です。
2
GCP への認証に使用される秘密 RSA キー。このキーは安全に保管する必要があり、回転させないでください。

GCP Workload Identity を使用した Base64 でエンコードされた service_account.json ファイルのコンテンツ

{
   "type": "external_account", 1
   "audience": "//iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/test-pool/providers/test-provider", 2
   "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
   "token_url": "https://sts.googleapis.com/v1/token",
   "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<client_email_address>:generateAccessToken", 3
   "credential_source": {
      "file": "<path_to_token>", 4
      "format": {
         "type": "text"
      }
   }
}

1
クレデンシャルの種類はexternal_accountです。
2
ターゲットオーディエンスは GCP ワークロード ID プロバイダーです。
3
これらのクレデンシャルで偽装できるサービスアカウントのリソース URL。
4
Pod 内のサービスアカウントトークンへのパス。通常、これは OpenShift Container Platform コンポーネントの /var/run/secrets/openshift/serviceaccount/token です。

19.6.2. GCP Workload Identity ID を使用して手動モード用に設定された OpenShift Container Platform クラスターのインストール

Cloud Credential Operator (CCO) を手動モードで GCP Workload Identity を使用して使用するように設定されたクラスターをインストールするには、次の手順を実行します。

注記

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

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

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

注記

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

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) がインストールされている。

手順

  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.6.2.2. Cloud Credential Operator ユーティリティーを使用した GCP リソースの作成

ccoctl gcp create-all コマンドを使用して、GCP リソースの作成を自動化できます。

注記

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

前提条件

以下が必要になります。

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

手順

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

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

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

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

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

    0000_26_cloud-controller-manager-operator_16_credentialsrequest-gcp.yaml 1
    0000_30_machine-api-operator_00_credentials-request.yaml 2
    0000_50_cloud-credential-operator_05-gcp-ro-credentialsrequest.yaml 3
    0000_50_cluster-image-registry-operator_01-registry-credentials-request-gcs.yaml 4
    0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 5
    0000_50_cluster-network-operator_02-cncc-credentials.yaml 6
    0000_50_cluster-storage-operator_03_credentials_request_gcp.yaml 7

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

    $ ccoctl gcp create-all \
    --name=<name> \
    --region=<gcp_region> \
    --project=<gcp_project_id> \
    --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests

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

    • <name> は、トラッキングに使用される、作成されたすべての GCP リソースのユーザー定義名です。
    • <gcp_region> は、クラウドリソースが作成される GCP リージョンです。
    • <gcp_project_id> は、クラウドリソースが作成される GCP プロジェクト ID です。
    • <path_to_directory_with_list_of_credentials_requests>/credrequests は、GCP サービスアカウントを作成するためのCredentials Requestマニフェストのファイルを含むディレクトリーです。
    注記

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

検証

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

    $ ls <path_to_ccoctl_output_dir>/manifests

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

19.6.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.6.2.4. インストールの検証

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

    $ oc get secrets -n kube-system gcp-credentials

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

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

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

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

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

    Image Registry Operator を使用した出力例

    {
       "type": "external_account", 1
       "audience": "//iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/test-pool/providers/test-provider",
       "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
       "token_url": "https://sts.googleapis.com/v1/token",
       "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<client-email-address>:generateAccessToken", 2
       "credential_source": {
          "file": "/var/run/secrets/openshift/serviceaccount/token",
          "format": {
             "type": "text"
          }
       }
    }

    1
    クレデンシャルの種類はexternal_accountです。
    2
    Image Registry Operator が使用するサービスアカウントのリソース URL。

19.6.3. 関連情報