クラスタ シークレットの管理

このトピックでは、Tanzu Kubernetes Grid のワークロード クラスタで使用される以下のシークレットを構成および管理する方法について説明します。

ワークロード クラスタ認証情報の更新

vSphere または Azure へのアクセスに使用する認証情報が変更された場合は、新しい認証情報を使用するようにクラスタを更新できます。AWS では認証情報の処理方法が異なるため、このセクションは vSphere と Azure にのみ適用されます。

vSphere
スタンドアローン管理クラスタおよびワークロード クラスタの認証情報の更新

現在のスタンドアローン管理クラスタとそのすべてのワークロード クラスタで使用される vSphere 認証情報を更新するには、tanzu mc credentials update --cascading コマンドを使用します。

  1. tanzu login を実行して、更新する管理クラスタにログインします。

  2. tanzu mc credentials update を実行します。次のコマンド オプションに値を渡すか CLI でプロンプトを表示させることができます。

    • --vsphere-user:vSphere アカウントの名前。
    • --vsphere-password:vSphere アカウントのパスワード。

スタンドアローン管理クラスタの認証情報のみを更新

スタンドアローン管理クラスタの vSphere 認証情報を更新し、ワークロード クラスタについては更新しない場合は、上記のように tanzu mc credentials update コマンドを使用しますが、--cascading オプションは使用しません。

ワークロード クラスタ認証情報の更新

単一のワークロード クラスタが vSphere にアクセスするために使用する認証情報を更新するには、tanzu cluster credentials update コマンドを使用します。

  1. tanzu login を実行して、更新するワークロード クラスタを作成した管理クラスタにログインします。管理クラスタは、スーパーバイザー クラスタまたはスタンドアローン管理クラスタです。

  2. tanzu cluster credentials update CLUSTER-NAME を実行します。次のコマンド オプションに値を渡すか CLI でプロンプトを表示させることができます。

    • --namespacedefault など、認証情報を更新するクラスタの名前空間。
    • --vsphere-user:vSphere アカウントの名前。
    • --vsphere-password:vSphere アカウントのパスワード。

また、tanzu mc credentials update --cascading を使用して、管理クラスタおよび管理対象のすべてのワークロード クラスタの vSphere 認証情報を更新することもできます。

AWS
このセクションは、AWS 環境には適用されません。
Azure
スタンドアローン管理クラスタおよびワークロード クラスタの認証情報の更新
重要

開始する前に、Azure ポータルまたは Azure 管理者から新しい Azure 認証情報を取得します。

現在のスタンドアローン管理クラスタとそのすべてのワークロード クラスタで使用される Azure 認証情報を更新するには、tanzu mc credentials update --cascading コマンドを使用します。

  1. tanzu login を実行して、更新する管理クラスタにログインします。

  2. tanzu mc credentials update を実行します。次のコマンド オプションに値を渡すか CLI でプロンプトを表示させることができます。

    • --azure-client-id:Azure に登録した Tanzu Kubernetes Grid のアプリケーションのクライアント ID。
    • --azure-client-secret:Azure に登録した Tanzu Kubernetes Grid のアプリケーションのクライアント シークレット。
    • --azure-tenant-id:Tanzu Kubernetes Grid のアプリケーションが配置されている Azure Active Directory のテナント ID。

スタンドアローン管理クラスタの認証情報のみを更新

スタンドアローン管理クラスタの Azure 認証情報を更新し、ワークロード クラスタについては更新しない場合は、上記のように tanzu mc credentials update コマンドを使用しますが、--cascading オプションは使用しません。

ワークロード クラスタ認証情報の更新

単一のワークロード クラスタが Azure にアクセスするために使用する認証情報を更新するには、tanzu cluster credentials update コマンドを使用します。

  1. tanzu login を実行して、更新するワークロード クラスタを作成した管理クラスタにログインします。

  2. tanzu cluster credentials update CLUSTER-NAME を実行します。次のコマンド オプションに値を渡すか CLI でプロンプトを表示させることができます。

    • --namespacedefault など、認証情報を更新するクラスタの名前空間。
    • --azure-client-id:Azure に登録した Tanzu Kubernetes Grid のアプリケーションのクライアント ID。
    • --azure-client-secret:Azure に登録した Tanzu Kubernetes Grid のアプリケーションのクライアント シークレット。
    • --azure-tenant-id:Tanzu Kubernetes Grid のアプリケーションが配置されている Azure Active Directory のテナント ID。

また、tanzu mc credentials update --cascading を使用して、管理クラスタおよび管理対象のすべてのワークロード クラスタの Azure 認証情報を更新することもできます。


制御プレーン ノードの証明書の自動更新

構成方法とクラスタ タイプに応じて、制御プレーン ノード仮想マシンの証明書を自動的に更新するように、次のように TKG クラスタを構成します。

  • Kubernetes スタイルのオブジェクト仕様(クラスベースのクラスタ):

    • Cluster オブジェクト仕様では、spec.topology.variables 以下に次のブロックを含めます。

      - name: controlPlaneCertificateRotation.activate
      value: true
      - name: controlPlaneCertificateRotation.daysBefore
      value: EXPIRY-DAYS
      
  • フラットなクラスタ構成ファイル(クラスベースまたはレガシー クラスタ):

    • クラスタ構成ファイルに、次の設定を含めます。

      CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
      CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
      

ここで、EXPIRY-DAYS は、クラスタ ノード証明書が自動更新されることになる、証明書の有効期限までの日数のオプション設定です。デフォルト:90; minimum: 7.

クラスタ証明書の更新(スタンドアローン MC)

スタンドアローン管理クラスタとそれらのワークロード クラスタは、クライアント証明書を使用して要求を認証します。これらの証明書は 1 年間有効です。証明書を更新するには、クラスタをアップグレードするか、次の手順に従います。この手順は、期限切れになっていない有効なクラスタ証明書を対象としています。

  1. 更新する証明書を使用しているクラスタを特定します。例:

    tanzu cluster list
    NAME                 NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
    workload-slot35rp10  default    running  3/3           3/3      v1.24.10+vmware.1  <none>  prod  v1.24.10---vmware.2-tkg.1
    

    クラスタ ノードを一覧表示するには、次を実行します。

    kubectl get nodes -o wide
    
  2. 証明書の有効期限を確認します。

    vSphere
    次のコマンドを実行します。
    kubectl get nodes \
    -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
    -l node-role.kubernetes.io/master= > nodes
    
    for i in `cat nodes`; do
       printf "\n######\n"
       ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
       ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
    done;
    
    AWS
    次のコマンドを実行します。
    kubectl get nodes \
    -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
    -l node-role.kubernetes.io/master= > nodes
    
    for i in `cat nodes`; do
        printf "\n######\n"
        ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i hostname
        ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i sudo kubeadm certs check-expiration
    done;
    
    Azure
    次のコマンドを実行します。
    kubectl get nodes \
    -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
    -l node-role.kubernetes.io/master= > nodes
    
    for i in `cat nodes`; do
        printf "\n######\n"
        ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i hostname
        ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i sudo kubeadm certs check-expiration
    done;
    

    出力例:

    ######
    workload-slot35rp10-control-plane-ggsmj
    [check-expiration] Reading configuration from the cluster...
    [check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
    W0923 17:51:03.686273 4172778 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
    
    CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
    admin.conf                 Sep 21, 2023 23:13 UTC   363d            ca                      no
    apiserver                  Sep 21, 2023 23:13 UTC   363d            ca                      no
    apiserver-etcd-client      Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
    apiserver-kubelet-client   Sep 21, 2023 23:13 UTC   363d            ca                      no
    controller-manager.conf    Sep 21, 2023 23:13 UTC   363d            ca                      no
    etcd-healthcheck-client    Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
    etcd-peer                  Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
    etcd-server                Sep 21, 2023 23:13 UTC   363d            etcd-ca                 no
    front-proxy-client         Sep 21, 2023 23:13 UTC   363d            front-proxy-ca          no
    scheduler.conf             Sep 21, 2023 23:13 UTC   363d            ca                      no
    
    CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
    ca                      Sep 18, 2032 23:09 UTC   9y              no
    etcd-ca                 Sep 18, 2032 23:09 UTC   9y              no
    front-proxy-ca          Sep 18, 2032 23:09 UTC   9y              no
    
  3. kubectl コンテキストを管理クラスタに設定します。例:

    kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
    
  4. ターゲット クラスタの KCP オブジェクトの名前を取得します。例:

    kubectl get kcp
    
    NAME                                CLUSTER               INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE   VERSION
    workload-slot35rp10-control-plane   workload-slot35rp10   true          true                   3          3       3         0             42h   v1.24.10+vmware.1
    
  5. 制御プレーンのロールアウトをトリガして証明書を更新します。

    kubectl patch kcp workload-slot35rp10-control-plane --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}
    

    このコマンドを実行すると、Tanzu Kubernetes Grid がクラスタ マシンの再プロビジョニングを開始します。

    kubectl get machines
    
    workload-slot35rp10-control-plane-7z95k     workload-slot35rp10                                                                                                Provisioning   20s   v1.24.10+vmware.1
    workload-slot35rp10-control-plane-ggsmj     workload-slot35rp10   workload-slot35rp10-control-plane-ggsmj     vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f   Running        42h   v1.24.10+vmware.1
    workload-slot35rp10-control-plane-hxbxb     workload-slot35rp10   workload-slot35rp10-control-plane-hxbxb     vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd   Running        42h   v1.24.10+vmware.1
    workload-slot35rp10-control-plane-sm4nw     workload-slot35rp10   workload-slot35rp10-control-plane-sm4nw     vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce   Running        42h   v1.24.10+vmware.1
    workload-slot35rp10-md-0-667bcd6b57-79br9   workload-slot35rp10   workload-slot35rp10-md-0-667bcd6b57-79br9   vsphere://420142a2-d141-7d6b-b322-9c2afcc47da5   Running        42h   v1.24.10+vmware.1
    ...
    
  6. すべてのマシンが Running である場合、証明書の更新が正常に完了したことを確認します。

    1. kubectl コンテキストをワークロード クラスタに設定します。

      kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
      
    2. 証明書の有効期限を再度確認します。

      kubectl get nodes \
      -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
      -l node-role.kubernetes.io/master= > nodes
      
      for i in `cat nodes`; do
        printf "\n######\n"
        ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
        ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
      done;
      

      出力例:

      ######
      workload-slot35rp10-control-plane-4xgw8
      [check-expiration] Reading configuration from the cluster...
      [check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
      
      W0923 18:10:02.660438   13427 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
      CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
      admin.conf                 Sep 23, 2023 18:05 UTC   364d            ca                      no
      apiserver                  Sep 23, 2023 18:05 UTC   364d            ca                      no
      apiserver-etcd-client      Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      apiserver-kubelet-client   Sep 23, 2023 18:05 UTC   364d            ca                      no
      controller-manager.conf    Sep 23, 2023 18:05 UTC   364d            ca                      no
      etcd-healthcheck-client    Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      etcd-peer                  Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      etcd-server                Sep 23, 2023 18:05 UTC   364d            etcd-ca                 no
      front-proxy-client         Sep 23, 2023 18:05 UTC   364d            front-proxy-ca          no
      scheduler.conf             Sep 23, 2023 18:05 UTC   364d            ca                      no
      
      CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
      ca                      Sep 18, 2032 23:09 UTC   9y              no
      etcd-ca                 Sep 18, 2032 23:09 UTC   9y              no
      front-proxy-ca          Sep 18, 2032 23:09 UTC   9y              no
      

      証明書の更新が正常に完了すると、Residual Time 列に 364d と表示されます。ワーカー ノードの証明書は自動的に更新されます。

信頼されたレジストリを持つクラスタの構成 (スーパーバイザー)

TKG の外部にあるプライベート コンテナ レジストリ、つまり TKG クラスタで実行されない自己署名証明書を持つレジストリを使用するようにスーパーバイザーで展開された TKG クラスタを構成するには、vSphere ドキュメントの次のトピックを参照してください。

複数の信頼できるレジストリを持つクラスタの構成(スタンドアローン MC)

TKG_CUSTOM_IMAGE_REPOSITORY_* 変数は、インターネットが制限された環境でカスタム レジストリから TKG イメージをプルする場合など、自己署名認証局 (CA) 証明書を使用する Harbor レジストリとの信頼された通信を維持する新しいクラスタを構成します。

containerd TLS などの用途に対して追加のプライベート レジストリを信頼するようにクラスタを構成できます。これを行う方法は、次に説明するように、クラスタがプランベースかクラスベースかによって異なります。

クラスベースのクラスタの信頼できるレジストリ

追加のカスタム イメージ レジストリの信頼を使用して構成されたクラスベースのクラスタを作成するには、次の手順を実行します。

  1. クラスベースのクラスタの作成」で説明されている 2 段階のプロセスの手順 1 に従って、新しいクラスタ マニフェストを生成します。

  2. 生成されたマニフェストの topology.variablestrust 設定を編集して、additionalTrustedCAs ブロックを追加します。

    topology:
    variables:
    - name: trust
      value:
        additionalTrustedCAs:
        - data: CA-BASE64
        - name: proxy
    

    ここで、CA-BASE64 は base64 でエンコードされた形式の CA 証明書です。

    trust 変数ブロックには、TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE および TKG_PROXY_CA_CERT 構成変数から設定された値がすでに含まれています。

  3. 2 段階のクラスタ作成プロセスの 2 番目の手順として、変更されたマニフェストで tanzu cluster create を実行します。

新しいプランベースのクラスタの信頼できるレジストリ

新しい TKC またはプランベースのクラスタで、自己署名証明書を使用するコンテナ レジストリからイメージをプルできるようにするには、ytt オーバーレイ ファイルを使用して、カスタム証明書をワークロード クラスタ ノードに追加します。

以下のオーバーレイ コードは、新しいクラスタ内のすべてのノードにカスタム CA 証明書を追加します。このコードは、Photon または Ubuntu 仮想マシン イメージ テンプレートに基づくクラスタに対して、すべてのクラウド ターゲット プラットフォームで機能します。

クラスタをカスタマイズし、新しいクラスタ プランを作成するオーバーレイについては、「ytt オーバーレイ」を参照してください。

  1. カスタム CA をすべての新しいクラスタに適用するか、1 つのクラウド インフラストラクチャで作成されたクラスタにのみ適用するか、または特定のクラスタ API プロバイダ バージョン(クラスタ API プロバイダ vSphere v1.5.1 など)で作成されたクラスタに適用するかを選択します。

  2. ローカルの ~/.config/tanzu/tkg/providers/ ディレクトリで、選択した範囲をカバーする ytt ディレクトリを見つけます。たとえば、/ytt/03_customizations/ はすべてのクラスタに適用され、/infrastructure-vsphere/ytt/ はすべての vSphere クラスタに適用されます。

  3. 選択した ytt ディレクトリで、新しい .yaml ファイルを作成するか、既存のオーバーレイ ファイルを次のコードで拡張します。

    #@ load("@ytt:overlay", "overlay")
    #@ load("@ytt:data", "data")
    
    #! This ytt overlay adds additional custom CA certificates on TKG cluster nodes, so containerd and other tools trust these CA certificates.
    #! It works when using Photon or Ubuntu as the TKG node template on all TKG target platforms.
    
    #! Trust your custom CA certificates on all Control Plane nodes.
    #@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
    ---
    spec:
      kubeadmConfigSpec:
        #@overlay/match missing_ok=True
        files:
          #@overlay/append
          - content: #@ data.read("tkg-custom-ca.pem")
            owner: root:root
            permissions: "0644"
            path: /etc/ssl/certs/tkg-custom-ca.pem
        #@overlay/match missing_ok=True
        preKubeadmCommands:
          #! For Photon OS
          #@overlay/append
          - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
          #! For Ubuntu
          #@overlay/append
          - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
    
    #! Trust your custom CA certificates on all worker nodes.
    #@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}), expects="1+"
    ---
    spec:
      template:
        spec:
          #@overlay/match missing_ok=True
          files:
            #@overlay/append
            - content: #@ data.read("tkg-custom-ca.pem")
              owner: root:root
              permissions: "0644"
              path: /etc/ssl/certs/tkg-custom-ca.pem
          #@overlay/match missing_ok=True
          preKubeadmCommands:
            #! For Photon OS
            #@overlay/append
            - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
            #! For Ubuntu
            #@overlay/append
            - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
    
  4. 同じ ytt ディレクトリで、新規または既存の tkg-custom-ca.pem ファイルに認証局を追加します。

  5. クラスタを作成する前に、「(レガシー)プランベースまたは TKC クラスタの作成」の説明に従って、allow-legacy-cluster 機能を true に設定します。

既存のクラスタへのカスタム CA 証明書の信頼の追加(スタンドアローン MC)

containerd TLS およびその他の用途のために、TKG_CUSTOM_IMAGE_REPOSITORY_* 構成変数によって設定されたものを超えて、既存のクラスタと自己署名 CA を使用した追加のカスタム Harbor レジストリ間の信頼できる通信を有効にできます。これを行う方法は、次に説明するように、クラスタがプランベースかクラスベースかによって異なります。

クラスベースのクラスタがカスタム レジストリを信用するようにする

信頼できるカスタム レジストリを既存のクラスベースのクラスタに追加するには、その Cluster オブジェクトを編集し、上の「クラスベース クラスタの信頼されたレジストリ」で説明した additionalTrustedCAs の値を追加し、変更された Cluster 仕様を適用します。

プランベースのクラスタがカスタム レジストリを信用するようにする

自己署名 CA を使用して、既存のプランベースのクラスタと Harbor レジストリ間の信頼を有効にするには、次の手順を実行します。

  1. Harbor CA 証明書を取得します。

    1. 共有サービス クラスタなど、Harbor を実行しているクラスタにコンテキストを切り替えます。

      kubectl config use-context SERVICES-CLUSTER-CONTEXT
      

      ここで、SERVICES-CLUSTER-CONTEXT はクラスタのコンテキストです。たとえば、tkg-wld-admin@tkg-wld などです。

    2. 証明書を取得します。

      kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
      -----BEGIN CERTIFICATE-----
      MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
      [...]
      yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
      -----END CERTIFICATE-----
      
  2. カスタム CA をスタンドアローン管理クラスタの kubeadmconfigtemplate に追加します。

    1. コンテキストを管理クラスタに切り替えます。

      kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
      

      ここで、MANAGEMENT-CLUSTER-CONTEXT は管理クラスタのコンテキストです。たとえば、tkg-mgmt-admin@tkg-mgmt などです。

    2. エディタで、クラスタの kubeadmconfigtemplate テンプレート ファイルを開きます。

      kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
      

      ここで、CLUSTER-NAME は、変更する必要があるクラスタの名前です。

    3. 次に示すように、ファイルの spec.template.spec.files セクションを変更して証明書を含めます。

      spec:
      template:
        spec:
          files:
          - content: |
                -----BEGIN CERTIFICATE-----
               MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
               [...]
               yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
               -----END CERTIFICATE-----
             owner: root:root
             path: /etc/ssl/certs/tkg-custom-ca.pem
             permissions: "0644"
      
    4. ファイルの下部に、次のように preKubeadmCommands ブロックを追加します。

      preKubeadmCommands:
      - '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
      - '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem
         /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
      
  3. kubeadmconfigtemplate テンプレート ファイルに変更内容を保存します。

  4. スタンドアローン管理クラスタに変更をパッチ適用します。

    kubectl patch machinedeployments.cluster.x-k8s.io tkg-test-md-0 --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
    

    このコマンドを実行すると、クラスタ ノードのローリング アップデートがトリガされ、タイムスタンプが更新されます。

プライベート コンテナ レジストリへの認証の構成

認証シークレットを追加して、クラスタがプライベート コンテナ レジストリにアクセスできるようにします。これには、イメージをプルするためのユーザー認証が必要です。クラスタからアクセスされるプライベート レジストリ用に構成した認証シークレットを表示、更新、または削除することもできます。

プライベート コンテナ レジストリの認証シークレットの追加

Tanzu CLI を使用すると、クラスタからプライベート コンテナ レジストリにアクセスするための認証シークレットを追加できます。レジストリ シークレットをクラスタ内の名前空間に追加したら、プライベート レジストリでホストされているすべてのパッケージ リポジトリ、パッケージ、およびコンテナ イメージをプルできます。その後、パッケージ リポジトリとパッケージ リソースをクラスタに追加できます。

この手順を実行する前に、プライベート コンテナ レジストリのユーザー名とパスワードを取得します。

プライベート レジストリに認証シークレットを追加するには、次のコマンドを実行します。

tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD

ここで、

  • SECRET-NAME は、追加するレジストリ認証シークレットの名前です。
  • NAMESPACE は、レジストリが属する Tanzu Kubernetes Grid 名前空間です。
  • USERNAME はレジストリにアクセスするためのユーザー名です。ユーザー名に特殊文字が含まれている場合は、一重引用符で囲みます。
  • PASSWORD は、レジストリにアクセスするためのパスワードです。パスワードに特殊文字が含まれている場合は、一重引用符で囲みます。次の形式でパスワードを指定することもできます。

    • コマンドの --password PASSWORD 文字列を --password-env-var ENV-VAR に置き換えて、すでに構成済みの環境変数を使用してパスワードを指定します。コマンドの形式は次のとおりです。

      tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-env-var ENV-VAR

    • コマンドの --password PASSWORD 文字列を --password-stdin 文字列に置き換えて、標準入力でパスワードを指定し、プロンプトが表示されたらパスワードを入力します。コマンドの形式は次のとおりです。

      tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-stdin

    • コマンドの --password PASSWORD 文字列を --password-file PASSWORD-FILE 文字列に置き換えて、パスワード ファイルを使用してパスワードを指定します。コマンドの形式は次のとおりです。

      tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-file PASSWORD-FILE

必要に応じて、クラスタ内のすべての名前空間でレジストリ シークレットを使用できるようにするには、次の形式で示すように --export-to-all-namespaces オプションを使用します。

tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD --export-to-all-namespaces

次に、このコマンドの出力例を示します。

tanzu secret registry add tanzu-net -n test-ns --server registry.pivotal.io --username test-user --password-file pass-file --export-to-all-namespaces
Warning: By choosing --export-to-all-namespaces, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
/ Adding registry secret 'test-secret'...
  Added registry secret 'test-secret' into namespace 'test-ns'

クラスタ内のレジストリ認証シークレットの表示

デフォルトの名前空間またはクラスタ内のすべての名前空間でレジストリ認証シークレットを表示できます。シークレットは、テーブル、JSON、または YAML ファイルの形式で表示できます。

クラスタ内の特定の名前空間のレジストリ認証シークレットを表示するには、次の手順を実行します。

tanzu secret registry list -n NAMESPACE

ここで、NAMESPACE は、レジストリが属する Tanzu Kubernetes Grid 名前空間です。

次に、このコマンドの例を示します。

tanzu secret registry list -n test-ns
/ Retrieving registry secrets...
  NAME         REGISTRY                 EXPORTED           AGE
  pkg-dev-reg  registry.pivotal.io      to all namespaces  15d

クラスタ内のすべての名前空間のレジストリ認証シークレットのリストを表示するには、次の手順を実行します。

tanzu secret registry list -A

次に、このコマンドの例を示します。

tanzu secret registry list -A
\ Retrieving registry secrets...
 NAME                          REGISTRY             EXPORTED           AGE  NAMESPACE
 pkg-dev-reg                   registry.pivotal.io  to all namespaces  15d  test-ns
 tanzu-standard-fetch-0        registry.pivotal.io  not exported       15d  tanzu-package-repo-global
 private-repo-fetch-0          registry.pivotal.io  not exported       15d  test-ns
 antrea-fetch-0                registry.pivotal.io  not exported       15d  tkg-system
 metrics-server-fetch-0        registry.pivotal.io  not exported       15d  tkg-system
 tanzu-addons-manager-fetch-0  registry.pivotal.io  not exported       15d  tkg-system
 tanzu-core-fetch-0            registry.pivotal.io  not exported       15d  tkg-system

JSON ファイル形式のレジストリ認証シークレットのリストを表示するには、次のコマンドを実行します。

tanzu secret registry list -n kapp-controller-packaging-global -o json

次に、このコマンドの例を示します。

tanzu secret registry list -n kapp-controller-packaging-global -o json
[
 {
   "age": "15d",
   "exported": "to all namespaces",
   "name": "pkg-dev-reg",
   "registry": "us-east4-docker.pkg.dev"
 }
]

YAML ファイル形式のレジストリ認証シークレットのリストを表示するには、次のコマンドを実行します。

tanzu secret registry list -n kapp-controller-packaging-global -o yaml

次に、このコマンドの例を示します。

 tanzu secret registry list -n kapp-controller-packaging-global -o yaml
 - age: 15d
   exported: to all namespaces
   name: pkg-dev-reg
   registry: us-east4-docker.pkg.dev

表形式のレジストリ認証シークレットのリストを表示するには、次のコマンドを実行します。

tanzu secret registry list -n kapp-controller-packaging-global -o table

次に、このコマンドの例を示します。

tanzu secret registry list -n kapp-controller-packaging-global -o table
/ Retrieving registry secrets...
  NAME         REGISTRY                 EXPORTED           AGE
  pkg-dev-reg  us-east4-docker.pkg.dev  to all namespaces  15d

レジストリ認証シークレットの更新

シークレットの認証情報を更新したり、すべての名前空間でシークレットを使用できるようにしたり、クラスタ内の 1 つの名前空間でのみ使用できるようにしたりできます。

シークレットが作成された名前空間内でシークレットを更新するには、次のコマンドを実行します。

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD

ここで、

  • SECRET-NAME は、更新するレジストリ シークレットの名前です。
  • NAMESPACE は、レジストリ認証シークレットを更新している Tanzu Kubernetes Grid 名前空間です。
  • USERNAME は、レジストリにアクセスするための新しいユーザー名です(ユーザー名を更新する場合)。
  • PASSWORD はレジストリの新しいパスワードです(パスワードを更新する場合)。

ユーザー名またはパスワードのいずれか、または両方を更新できます。

次に、このコマンドの例を示します。

tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV
\ Updating registry secret 'test-secret'...
 Updated registry secret 'test-secret' in namespace 'test-ns'

レジストリ認証シークレットを更新し、クラスタ内の他の名前空間で使用できるようにするには、次のコマンドを実行します。

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=true

ここで、

  • SECRET-NAME は、更新するレジストリ シークレットの名前です。
  • NAMESPACE は、レジストリ認証シークレットを更新している Tanzu Kubernetes Grid 名前空間です。
  • USERNAME はレジストリにアクセスするためのユーザー名です。ユーザー名を更新する場合は、新しいユーザー名を入力します。
  • PASSWORD はレジストリのパスワードです。パスワードを更新する場合は、新しいパスワードを入力します。

次に、このコマンドの例を示します。

tanzu secret registry update test-secret--username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=true
Warning: By specifying --export-to-all-namespaces as true, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
Are you sure you want to proceed? [y/N]: y

\ Updating registry secret 'test-secret'...
  Updated registry secret 'test-secret' in namespace 'test-ns'
  Exported registry secret 'test-secret' to all namespaces

クラスタ内の他の名前空間でレジストリ認証シークレットを使用できないようにするには、次のコマンドを実行します。

tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=false

ここで、

  • SECRET-NAME は、更新するレジストリ シークレットの名前です。
  • NAMESPACE は、レジストリ認証シークレットを更新している Tanzu Kubernetes Grid 名前空間です。
  • USERNAME はレジストリにアクセスするためのユーザー名です。
  • PASSWORD はレジストリのパスワードです。

次に、このコマンドの例を示します。

tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=false
Warning: By specifying --export-to-all-namespaces as false, the secret contents will get unexported from ALL namespaces in which it was previously available to.
Are you sure you want to proceed? [y/N]: y

\ Updating registry secret 'test-secret'...
  Updated registry secret 'test-secret' in namespace 'test-ns'
  Unexported registry secret 'test-secret' from all namespaces

レジストリ認証シークレットの削除

Tanzu CLI を使用すると、クラスタ内のレジストリ認証シークレットを削除できます。特定の名前空間内のレジストリ認証シークレットを削除するには、次のコマンドを実行します。

tanzu secret registry delete SECRET-NAME -n NAMESPACE

ここで、

  • SECRET-NAME は削除するレジストリ シークレットの名前です。
  • (オプション)NAMESPACE は、レジストリ認証シークレットを削除する Tanzu Kubernetes Grid 名前空間です。名前空間を指定しない場合、認証シークレットはデフォルトの名前空間から削除されます。シークレットがクラスタ内の他の名前空間にエクスポートされていた場合は、そのシークレットも削除されます。

次に、このコマンドの例を示します。

tanzu secret registry delete test-secret -n test-ns
Deleting registry secret 'test-secret' from namespace 'test-ns'. Are you sure? [y/N]: y
\ Deleting registry secret 'test-secret'...
 Deleted registry secret 'test-secret' from namespace 'test-ns'
check-circle-line exclamation-circle-line close-line
Scroll to top icon