非公開レジストリに対する認証を行うようにノードを構成する

ワーカーノードが Artifact Registry などの非公開レジストリを使用できるように Google Distributed Cloud クラスタを構成できます。ノードレベルの限定公開レジストリは、ワークロードを使用してイメージの pull とそれに関連するセキュリティをより細かく制御できるようにすることを目的としています。このドキュメントで説明するように、非公開レジストリを使用してクラスタを構成すると、Google Distributed Cloud は containerd 構成を適宜更新します。クラスタが構成されると、Pod 仕様で imagePullSecrets を指定する必要なく、適格なノード上のすべての Pod がレジストリを使用できるようになります。

この機能は、クラスタのライフサイクルの任意の時点で有効または無効にできます。

次のリストに、この機能のリリース ステージ（バージョンごと）を示します。

前提条件

1.30 以降

この一般提供の機能を使用するには、クラスタが次の要件を満たしている必要があります。

  • クラスタのバージョンは 1.30 以降である必要があります。
  • ノードプールのバージョンは 1.29 以降である必要があります（1.30 クラスタにはバージョン 1.28 のノードプールを含めることができますが、この機能はバージョン 1.29 以降のノードプールでのみ機能します）。

  • この機能は、次の表に示すように、ワーカー ノードプールを使用するユーザー クラスタと自己管理（ハイブリッドおよびスタンドアロン）クラスタに使用されます。

    デプロイモデル サポートされるクラスタタイプ
    管理クラスタとユーザー クラスタのデプロイ

    管理クラスタ

    ユーザー クラスタ 1

    ユーザー クラスタ 2
    ハイブリッド クラスタ デプロイ

    ハイブリッド クラスタ

    ユーザー クラスタ 1

    ユーザー クラスタ 2
    スタンドアロン クラスタ デプロイ

    スタンドアロン クラスタ

1.29

このプレビュー機能を使用するには、クラスタが次の要件を満たしている必要があります。

  • クラスタのバージョンは 1.29 である必要があります。
  • ノードプールのバージョンは 1.29 である必要があります（すべてのノードプールがバージョン 1.29 である必要はありませんが、この機能はバージョン 1.29 のノードプールでのみ機能します）。
  • クラスタには、プレビュー機能のアノテーション preview.baremetal.cluster.gke.io/private-registry: "enable" が必要です。

  • この機能は、次の表に示すように、ワーカー ノードプールを使用するユーザー クラスタと自己管理（ハイブリッドおよびスタンドアロン）クラスタに使用されます。

    デプロイモデル サポートされるクラスタタイプ
    管理クラスタとユーザー クラスタのデプロイ

    管理クラスタ

    ユーザー クラスタ 1

    ユーザー クラスタ 2
    ハイブリッド クラスタ デプロイ

    ハイブリッド クラスタ

    ユーザー クラスタ 1

    ユーザー クラスタ 2
    スタンドアロン クラスタ デプロイ

    スタンドアロン クラスタ

非公開レジストリ用の自己管理クラスタを構成する

ノードレベルの非公開レジストリを使用するようにスタンドアロン クラスタまたはハイブリッド クラスタを構成するには:

  1. クラスタ構成ファイルを編集して、認証情報セクションに privateRegistries ブロックを追加します。

    ---
gcrKeyPath: baremetal/gcr.json
sshPrivateKeyPath: .ssh/id_rsa
...
privateRegistries:
  - host: REGISTRY_HOST
    caCertPath: CA_CERT_PATH
    pullCredentialConfigPath: CREDENTIALS_FILE_PATH
...
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-hybrid-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-basic
  namespace: cluster-hybrid-basic
  annotations:
    preview.baremetal.cluster.gke.io/private-registry: "enable" # Version 1.29 clusters only
    ...
spec:
  type: hybrid
  ...

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

    • REGISTRY_HOST: 非公開レジストリとポートのドメイン名または IP アドレス。例: 10.200.0.2:5007。

    • CA_CERT_PATH: CA 証明書ファイル（サーバールート CA）のパス。例: /root/cert.pem。非公開レジストリでプライベート TLS 証明書が不要な場合、このフィールドは省略できます。

    • CREDENTIALS_FILE_PATH: 構成ファイルのパス config.json（例: $HOME/.docker/config.json）。非公開レジストリにアクセスするために containerd を認証するには、config.json のファイルの auths セクションに、認証情報の base64 でエンコードされたバージョンが含まれている必要があります。

      Artifact Registry の場合は、次の値でサービス アカウントの JSON キーを使用して認証します。

      • username: _json_key
      • password: サービス アカウントの JSON キーファイルの内容全体。貼り付けた JSON キーの内容を単一引用符（'）で囲んで、解析エラーを防ぎます。

      このファイルの生成方法については、Artifact Registry ドキュメントの Docker 用に Artifact Registry への認証を構成するをご覧ください。

      他の非公開レジストリの場合、base64 でエンコードされた auth 文字列は、通常、特定のレジストリ認証情報を使用して USERNAME:PASSWORD から作成されます。非公開レジストリ サーバーで認証に認証情報が必要ない場合は、pullCredentialConfigPath フィールドを省略できます。

      センシティブ データを保護するには、chown と chmod を使用して構成ファイルへのアクセスを制限できます。

  2. 変更をクラスタに適用します。

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG

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

    • CLUSTER_NAME: 更新するクラスタの名前。

    • CLUSTER_KUBECONFIG: セルフマネージド（ハイブリッドまたはスタンドアロン）クラスタの kubeconfig ファイルのパス。

非公開レジストリ用のユーザー クラスタを構成する

ユーザー クラスタの場合、非公開レジストリの構成は、管理クラスタにあるユーザー クラスタ リソース仕様で指定します。また、非公開レジストリの認証情報を Secret に保存する必要があります。この Secret も管理クラスタにあります。

  1. レジストリ認証情報の kubernetes.io/dockerconfigjson タイプの Kubernetes Secret を作成します。

    Secret のスコープを特定の Namespace に限定する場合は、次のコマンドに --namespace フラグを追加して、Namespace の名前を指定します。Secret がクラスタと同じ Namespace 内にない場合は、この手順の最後の例に示すように、アノテーション baremetal.cluster.gke.io/mark-source: "true" を追加します。

    kubectl create secret docker-registry CREDS_SECRET_NAME \
    --from-file=.dockerconfigjson=CREDENTIALS_FILE_PATH \
    --kubeconfig=ADMIN_KUBECONFIG

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

    • CREDS_SECRET_NAME: Secret の名前。

    • CREDENTIALS_FILE_PATH: 構成ファイルのパス config.json（例: $HOME/.docker/config.json）。非公開レジストリにアクセスするために containerd を認証するには、config.json のファイルの auths セクションに、認証情報の base64 でエンコードされたバージョンが含まれている必要があります。

      Artifact Registry の場合は、次の値でサービス アカウントの JSON キーを使用して認証します。

      • username: _json_key
      • password: サービス アカウントの JSON キーファイルの内容全体。貼り付けた JSON キーの内容を単一引用符（'）で囲んで、解析エラーを防ぎます。

      このファイルの生成方法については、Artifact Registry ドキュメントの Docker 用に Artifact Registry への認証を構成するをご覧ください。

      他の非公開レジストリの場合、base64 でエンコードされた auth 文字列は、通常、特定のレジストリ認証情報を使用して USERNAME:PASSWORD から作成されます。非公開レジストリ サーバーで認証に認証情報が必要ない場合は、pullCredentialSecretRef フィールドを省略できます。

      センシティブ データを保護するには、chown と chmod を使用して構成ファイルへのアクセスを制限できます。

    Secret は次のようになります。

    apiVersion: v1
data:
  .dockerconfigjson: ewoJImF1dGhzIjogewoJ...clpYSXdNak14IgoJCX0KCX0KfQ==
kind: Secret
metadata:
  creationTimestamp: "2024-04-28T22:06:06Z"
  name: private-registry-secret
  namespace: default
  resourceVersion: "5055821"
  ...
  annotations:
    ...
    baremetal.cluster.gke.io/mark-source: "true"
type: kubernetes.io/dockerconfigjson

  2. 必要に応じて、レジストリの CA 証明書を Secret に保存します。

    Secret は次のようになります。

    apiVersion: v1
kind: Secret
metadata:
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
  name: ca-9dd74fd308bac6df562c7a7b220590b5
  namespace: some-namespace
type: Opaque
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2RENDQXFTZ0F3SUJBZ0lVQi
  3UGxjUzVFVk8vS0xuYjZiMHRhRFVleXJvd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2ZqRUxNQWtHQ
  ...
  QnpPTkxTRFZJVk5LMm9YV1JvNEpJY0ZoNFZ4MWRMRHpqMldEaHhrUEljWEhLdGR3dk5iS2tocU
  LUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
  ```

  3. ユーザー クラスタの構成ファイルを編集して、非公開レジストリを有効にして構成します。

    1. バージョン 1.29 のクラスタでのみ、プレビュー機能のアノテーション preview.baremetal.cluster.gke.io/private-registry: "enable" を追加して機能を有効にします。バージョン 1.30 以降のクラスタでは、限定公開レジストリ機能がデフォルトで有効になっています。

      apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
  resourceVersion: "766027"
  annotations:
    ...
    preview.baremetal.cluster.gke.io/private-registry: "enable"
...

    2. ユーザー クラスタの構成ファイルで、nodeConfig セクションに privateRegistries ブロックを追加します。

      apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
...
spec:
  bypassPreflightCheck: false
...
  nodeConfig:
    containerRuntime: containerd
    podDensity:
      maxPodsPerNode: 250
    privateRegistries:
    - caCertSecretRef:
        name: CA_CERT_SECRET_NAME
        namespace: CA_CERT_SECRET_NAMESPACE
      host: REGISTRY_HOST
      pullCredentialSecretRef:
        name: CREDS_SECRET_NAME
        namespace: CREDS_SECRET_NAMESPACE

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

    • CA_CERT_SECRET_NAME: CA 証明書を保存するために作成した Secret の名前。この Secret を作成していない場合は、caCertSecretRef ブロックを削除します。

    • CA_CERT_SECRET_NAMESPACE: CA 証明書 Secret の Namespace の名前（作成した場合）。

    • REGISTRY_HOST: 非公開レジストリとポートのドメイン名または IP アドレス。例: 10.200.0.2:5007。

    • CREDS_SECRET_NAME: レジストリ認証情報の kubernetes.io/dockerconfigjson タイプの Secret の名前。

    • CREDS_SECRET_NAMESPACE: レジストリ認証情報の Secret の名前空間名。

  4. 変更をクラスタに適用します。

    bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

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

    • USER_CLUSTER_NAME: 更新するクラスタの名前。

    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。