kubectl を使用して Config Sync を手動でインストールする（非推奨）

SSH 認証鍵ペア

SSH 認証鍵ペアは、公開鍵と秘密鍵の 2 つのファイルから構成されています。通常、公開鍵の拡張子は .pub です。

SSH 認証鍵ペアを使用するには、次の手順に従います。

1. SSH 認証鍵ペアを作成し、Config Sync が Git リポジトリに対して認証されるようにします。この手順は、リポジトリのクローンを作成するか、リポジトリの内容を読み取る際にリポジトリに対する認証が必要になる場合に必要になります。鍵ペアがセキュリティ管理者から提供される場合は、この手順を省略します。自社のセキュリティとコンプライアンスの要件に応じて、すべてのクラスタに対して単一の鍵ペアを使用するか、クラスタごとに 1 つの鍵ペアを使用するかを選びます。

   次のコマンドは 4,096 ビットの RSA 鍵を作成します。これよりビット数の少ない鍵はおすすめできません。

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   次のように置き換えます。

   • GIT_REPOSITORY_USERNAME: Config Sync がリポジトリに対する認証で使用するユーザー名。
   • /path/to/KEYPAIR_FILENAME: 鍵ペアへのパス。

   GitHub などのサードパーティ Git リポジトリ ホストを使用している場合や、Cloud Source Repositories でサービス アカウントを使用する場合は、別のアカウントを使用することをおすすめします。

2. 新しく作成した公開鍵を認識するようにリポジトリを構成します。ご使用の Git ホスティング プロバイダのドキュメントをご覧ください。よく使われる Git ホスティング プロバイダの手順へのリンクを以下に示します。

   • Cloud Source Repositories
   • Bitbucket
   • GitHub 単一の GitHub リポジトリへの読み取り専用アクセスを提供するために、個別のデプロイキーを作成することをおすすめします。
   • GitLab

3. 秘密鍵をクラスタ内の新しい Secret に追加します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   /path/to/KEYPAIR_PRIVATE_KEY_FILENAME は、秘密鍵の名前に置き換えます（.pub 拡張子は付けません）。

4. （推奨）SSH 認証を使用して既知のホストのチェックを構成するには、git_creds Secret の data.known_hosts フィールドに既知のホストキーを追加します。known_hosts のチェックを無効にするには、Secret から known_hosts フィールドを削除します。既知のホスト鍵を追加するには、次のコマンドを実行します。

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   次に、data の下に、既知のホストのエントリを追加します。

   known_hosts: KNOWN_HOSTS_KEY
   

5. ローカル ディスクから秘密鍵を削除するか、秘密鍵を保護します。

6. Config Sync を構成して Git リポジトリの URL を追加する場合は、SSH プロトコルを使用します。Cloud Source Repositories のリポジトリを使用している場合は、URL を入力する際に次の形式を使用する必要があります。

   ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
   

   次のように置き換えます。

   • EMAIL: Google Cloud ユーザー名
   • PROJECT_ID: リポジトリが配置されている Google Cloud プロジェクトの ID
   • REPO_NAME: リポジトリの名前

Cookiefile

cookiefile を取得するプロセスは、リポジトリの構成によって異なります。サンプルについては、Cloud Source Repositories のドキュメントの静的認証情報を生成するをご覧ください。認証情報は通常、ユーザーのホーム ディレクトリにある .gitcookies ファイルに保存されますが、セキュリティ管理者から提供されることもあります。

cookiefile を作成するには、次の手順を行います。

1. cookiefile を作成して取得したら、クラスタの新しい Secret に追加します。

   HTTPS プロキシを使用しない場合は、次のコマンドを使用して Secret を作成します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   HTTPS プロキシを使用する必要がある場合は、次のコマンドを実行して、cookiefile と一緒に Secret に追加します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   次のように置き換えます。

   • /path/to/COOKIEFILE: 適切なパスとファイル名
   • HTTPS_PROXY_URL: Git リポジトリとの通信時に使用する HTTPS プロキシの URL

2. 引き続きローカルで必要な場合は、cookiefile の内容を保護します。必要でなければ削除します。

トークン

組織で SSH 認証鍵の使用が許可されていない場合は、トークンを使用することをおすすめします。Config Sync では、トークンとして GitHub の個人アクセス トークン（PAT）、GiLab の PAT、デプロイキー、Bitbucket のアプリ パスワードを使用できます。

トークンを使用して Secret を作成するには、次の手順を行います。

1. GitHub または Bitbucket を使用してトークンを作成します。

   • GitHub: PAT を作成します。トークンに repo スコープを付与し、非公開リポジトリから読み取れるようにします。PAT を GitHub アカウントにバインドするため、マシンユーザーを作成し、PAT をそのマシンユーザーにバインドすることをおすすめします。
   • GitLab: PAT を作成するか、デプロイ トークンを作成します。
   • Bitbucket: アプリ パスワードを作成します。

2. トークンを作成して取得したら、それをクラスタの新しい Secret に追加します。

   HTTPS プロキシを使用しない場合は、次のコマンドを使用して Secret を作成します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   次のように置き換えます。

   • USERNAME: 使用するユーザー名。
   • TOKEN: 前のステップで作成したトークン。

   HTTPS プロキシを使用する必要がある場合は、次のコマンドを実行して、username および token と一緒に Secret に追加します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   次のように置き換えます。

   • USERNAME: 使用するユーザー名。
   • TOKEN: 前のステップで作成したトークン。
   • HTTPS_PROXY_URL: Git リポジトリとの通信時に使用する HTTPS プロキシの URL。

3. ローカルでのトークンが必要な場合は、トークンを保護します。必要でなければ削除します。

Google サービス アカウント

リポジトリが Cloud Source Repositories にあり、クラスタが GKE Workload Identity Federation for GKE またはフリートの Workload Identity Federation for GKE を使用している場合は、Google サービス アカウントを使用して、マネージド クラスタと同じプロジェクト内のリポジトリに対するアクセス権を Config Sync に付与できます。

1. サービス アカウントがない場合は、サービス アカウントを作成します。

2. Google サービス アカウントに Cloud Source Repositories 読み取り（roles/source.reader）IAM ロールを付与します。Cloud Source Repositories のロールと権限の詳細については、リポジトリの表示権限を付与するをご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

3. Google Cloud コンソールを使用して Config Sync を構成する場合は、[認証タイプ] で [Workload Identity Federation for GKE] を選択し、サービス アカウントのメールアドレスを追加します。

   Google Cloud CLI を使用して Config Sync を構成する場合は、gcpserviceaccount を secretType として追加し、サービス アカウントのメールアドレスを gcpServiceAccountEmail に追加します。

4. Config Sync の構成が完了したら、Kubernetes サービス アカウントと Google サービス アカウントの間に IAM ポリシー バインディングを作成します。Config Sync を初めて構成するまで、Kubernetes サービス アカウントは作成されません。

   フリートに登録されたクラスタを使用している場合は、フリートごとに 1 回だけポリシー バインディングを作成する必要があります。フリートに登録されたすべてのクラスタは、同じ Workload Identity Federation for GKE プールを共有します。フリートのコンセプトである同一性により、1 つのクラスタの Kubernetes サービス アカウントに IAM ポリシーを追加すると、同じフリート内の他のクラスタでも同じ Namespace の Kubernetes サービス アカウントが同じ IAM ポリシーを取得します。

   このバインディングにより、Config Sync Kubernetes サービス アカウントが Google サービス アカウントとして機能できるようになります。

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

次のように置き換えます。

• PROJECT_ID: 組織のプロジェクト ID。
• FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
• GSA_NAME: Artifact Registry への接続に使用するカスタム Google サービス アカウント。このサービス アカウントには、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールが必要です。
• KSA_NAME: Reconciler の Kubernetes サービス アカウント。
  • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールする場合、root-sync という名前の RootSync オブジェクトが自動的に作成されます。
• REPOSITORY: リポジトリの名前。
• POLICY_FILE は、Identity and Access Management ポリシーを含む JSON または YAML ファイルです。

Compute Engine のデフォルトのサービス アカウント

リポジトリが Cloud Source Repositories にあり、クラスタが Workload Identity Federation for GKE が無効になっている GKE である場合は、認証タイプとして gcenode を使用できます。

Google Cloud コンソールを使用して Config Sync を構成する場合は、[認証タイプ] に [Google Cloud Repository] を選択します。

Google Cloud CLI を使用して Config Sync を構成する場合は、gcenode を secretType として追加します。

Google Cloud Repository または gcenode を選択すると、Compute Engine のデフォルトのサービス アカウントを使用できます。Compute Engine のデフォルト サービス アカウントに Cloud Source Repositories 読み取り（roles/source.reader）IAM ロールを付与する必要があります。Cloud Source Repositories のロールと権限の詳細については、リポジトリの表示権限を付与するをご覧ください。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

PROJECT_ID は組織のプロジェクト ID に置き換え、PROJECT_NUMBER は組織のプロジェクト番号に置き換えます。

GitHub アプリ

リポジトリが GitHub にある場合は、認証タイプとして githubapp を使用できます。

GitHub アプリを使用する手順は次のとおりです。

1. GitHub の手順に沿って GitHub アプリをプロビジョニングし、リポジトリからの読み取り権限を付与します。

2. GitHub アプリの構成をクラスタ内の新しい Secret に追加します。

   クライアント ID の使用

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • CLIENT_ID は、GitHub アプリのクライアント ID に置き換えます。
   • INSTALLATION_ID は、GitHub アプリのインストール ID に置き換えます。
   • /path/to/GITHUB_PRIVATE_KEY は、秘密鍵を含むファイルの名前に置き換えます。
   • BASE_URL は、GitHub API エンドポイントのベース URL に置き換えます。これは、リポジトリが www.github.com でホストされていない場合にのみ必要です。それ以外の場合は、引数を省略できます。デフォルトは https://api.github.com/ です。

   アプリケーション ID の使用

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • APPLICATION_ID は、GitHub アプリのアプリケーション ID に置き換えます。
   • INSTALLATION_ID は、GitHub アプリのインストール ID に置き換えます。
   • /path/to/GITHUB_PRIVATE_KEY は、秘密鍵を含むファイルの名前に置き換えます。
   • BASE_URL は、GitHub API エンドポイントのベース URL に置き換えます。これは、リポジトリが www.github.com でホストされていない場合にのみ必要です。それ以外の場合は、引数を省略できます。デフォルトは https://api.github.com/ です。

3. ローカル ディスクから秘密鍵を削除するか、秘密鍵を保護します。

4. Config Sync を構成して Git リポジトリの URL を追加する場合は、認証タイプに githubapp を使用します。

Kubernetes サービス アカウント

OCI イメージを Artifact Registry に保存し、クラスタで GKE の Workload Identity Federation for GKE または フリートの Workload Identity Federation for GKE を使用する場合は、バージョン 1.17.2 以降で認証タイプとして k8sserviceaccount を使用できます。このオプションは、構成プロセスが簡素化されているため、gcpserviceaccount よりも推奨されます。

1. Workload Identity Federation for GKE プールを使用して、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを Kubernetes サービス アカウントに付与します。Artifact Registry のロールと権限の詳細については、Artifact Registry のロールと権限の構成をご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   次のように置き換えます。

   • PROJECT_ID: 組織のプロジェクト ID。
   • FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
   • KSA_NAME: Reconciler の Kubernetes サービス アカウント。
     • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールする場合、root-sync という名前の RootSync オブジェクトが自動的に作成されます。
   • REPOSITORY: リポジトリの ID。
   • LOCATION: リポジトリのリージョンまたはマルチリージョン ロケーション。

Google サービス アカウント

OCI イメージを Artifact Registry に保存し、クラスタで GKE の Workload Identity Federation for GKE またはフリートの Workload Identity Federation for GKE を使用する場合は、認証タイプとして gcpserviceaccount を使用できます。バージョン 1.17.2 以降では、代わりに k8sserviceaccount を使用することをおすすめします。このオプションを使用すると、Google サービス アカウントと関連する IAM ポリシー バインディングを作成する手順が不要になります。

1. サービス アカウントがない場合は、サービス アカウントを作成します。

2. Google サービス アカウントに Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを付与します。Artifact Registry のロールと権限の詳細については、Artifact Registry のロールと権限の構成をご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID  \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. 次のコマンドを実行して、Kubernetes サービス アカウントと Google サービス アカウントの IAM ポリシー バインディングを作成します。

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

次のように置き換えます。

• PROJECT_ID: 組織のプロジェクト ID。
• FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
• GSA_NAME: Artifact Registry への接続に使用するカスタム Google サービス アカウント。このサービス アカウントには、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールが必要です。
• KSA_NAME: Reconciler の Kubernetes サービス アカウント。
  • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールする場合、root-sync という名前の RootSync オブジェクトが自動的に作成されます。
• REPOSITORY: リポジトリの ID。
• LOCATION: リポジトリのリージョンまたはマルチリージョン ロケーション。

Compute Engine のデフォルトのサービス アカウント

Helm チャートを Artifact Registry に保存し、クラスタが Workload Identity Federation for GKE が無効になっている GKE である場合は、認証タイプとして gcenode を使用できます。Config Sync は Compute Engine のデフォルトのサービス アカウントを使用します。Compute Engine のデフォルト サービス アカウントには、Artifact Registry への読み取りアクセス権を付与する必要があります。

1. 次のコマンドを実行して、Compute Engine サービス アカウントに Artifact Registry への読み取り権限を付与します。

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/artifactregistry.reader
   

   PROJECT_ID は組織のプロジェクト ID に置き換え、PROJECT_NUMBER は組織のプロジェクト番号に置き換えます。

RootSync

1. Git サーバーの証明書の発行に使用された CA 証明書を取得し、ファイルに保存します。

2. RootSync オブジェクトの場合、Secret は config-management-system Namespace 内に作成する必要があります。次に例を示します。

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Operator を構成する場合は、RootSync オブジェクトの caCertSecretRef.name フィールドの値を ROOT_CA_CERT_SECRET_NAME に設定します。

RepoSync

1. Git サーバーの証明書の発行に使用された CA 証明書を取得し、ファイルに保存します。

2. RepoSync オブジェクトの場合、Secret は RepoSync と同じ Namespace に作成する必要があります。次に例を示します。

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. RepoSync を構成する場合は、RepoSync オブジェクトの caCertSecretRef.name フィールドの値を NAMESPACE_CA_CERT_SECRET_NAME に設定します。

トークン

Helm リポジトリのユーザー名とパスワードを使用して Secret を作成します。

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

次のように置き換えます。

• SECRET_NAME: Secret に付ける名前。
• USERNAME: Helm リポジトリのユーザー名。
• PASSWORD: Helm リポジトリのパスワード。

ConfigManagement Operator を構成する場合は、spec.helm.secretRef.name に選択した Secret 名を使用します。

Kubernetes サービス アカウント

Helm チャートを Artifact Registry に保存し、クラスタで GKE の Workload Identity Federation for GKE またはフリートの Workload Identity Federation for GKE を使用する場合、バージョン 1.17.2 以降で k8sserviceaccount を認証タイプとして使用できます。このオプションは、構成プロセスが簡素化されているため、gcpserviceaccount よりも推奨されます。

1. Workload Identity Federation for GKE プールを使用して、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを Kubernetes サービス アカウントに付与します。Artifact Registry のロールと権限の詳細については、Artifact Registry のロールと権限の構成をご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   次のように置き換えます。

   • PROJECT_ID: 組織のプロジェクト ID。
   • FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
   • KSA_NAME: Reconciler の Kubernetes サービス アカウント。
     • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。
   • REPOSITORY: リポジトリの ID。
   • LOCATION: リポジトリのリージョンまたはマルチリージョン ロケーション。

Google サービス アカウント

Helm チャートを Artifact Registry に保存し、クラスタで GKE の Workload Identity Federation for GKE またはフリートの Workload Identity Federation for GKE を使用する場合は、認証タイプとして gcpserviceaccount を使用できます。バージョン 1.17.2 以降では、代わりに k8sserviceaccount を使用することをおすすめします。このオプションを使用すると、Google サービス アカウントと関連する IAM ポリシー バインディングを作成する手順が不要になります。

1. サービス アカウントがない場合は、サービス アカウントを作成します。

2. Google サービス アカウントに Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを付与します。Artifact Registry のロールと権限の詳細については、Artifact Registry のロールと権限の構成をご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID  \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. 次のコマンドを実行して、Kubernetes サービス アカウントと Google サービス アカウントの IAM ポリシー バインディングを作成します。

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
       --project=PROJECT_ID
   

次のように置き換えます。

• PROJECT_ID: 組織のプロジェクト ID。
• FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
• GSA_NAME: Artifact Registry への接続に使用するカスタム Google サービス アカウント。このサービス アカウントには、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールが必要です。
• KSA_NAME: Reconciler の Kubernetes サービス アカウント。
  • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。
• REPOSITORY: リポジトリの ID。
• LOCATION: リポジトリのリージョンまたはマルチリージョン ロケーション。

Compute Engine のデフォルトのサービス アカウント

Helm チャートを Artifact Registry に保存し、クラスタが Workload Identity Federation for GKE が無効になっている GKE である場合は、認証タイプとして gcenode を使用できます。Config Sync は Compute Engine のデフォルトのサービス アカウントを使用します。Compute Engine のデフォルト サービス アカウントには、Artifact Registry への読み取りアクセス権を付与する必要があります。イメージを pull するための読み取り専用アクセス権を付与するには、storage-ro アクセス スコープを付与することが必要な場合があります。

1. Compute Engine サービス アカウントに Artifact Registry への読み取り権限を付与します。

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
       --role=roles/artifactregistry.reader
   

   PROJECT_ID は組織のプロジェクト ID に置き換え、PROJECT_NUMBER は組織のプロジェクト番号に置き換えます。