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

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

クラスタがクラウドインフラストラクチャ API およびリソースへのアクセスに使用する認証情報。「クラスタ認証情報の更新」を参照してください。
内部クラスタコンポーネントが要求の認証に使用するクライアント証明書（スタンドアローン管理クラスタが展開されたワークロードクラスタのみ）。「クラスタ証明書の更新」を参照してください。
クラスタがプライベートコンテナレジストリにアクセスするために使用する認証局 (CA) 証明書。「信頼できる複数のレジストリを持つクラスタの構成」および「既存のクラスタへのカスタム CA 証明書の信頼の追加」を参照してください。
クラスタが認証済みのプライベートコンテナレジストリにアクセスするために使用する認証情報。「プライベートコンテナレジストリへの認証の構成」を参照してください。

クラスタ認証情報の更新

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

vSphere

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

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

tanzu context use MGMT-CLUSTER を実行して、更新する管理クラスタにログインします。
tanzu mc credentials update を実行します。次のコマンドオプションに値を渡すか CLI でプロンプトを表示させることができます。
- --vsphere-user：vSphere アカウントの名前。
- --vsphere-password：vSphere アカウントのパスワード。
- --vsphere-thumbprint：vCenter Server インスタンスの TLS サムプリント。

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

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

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

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

tanzu context use MGMT-CLUSTER を実行して、更新するワークロードクラスタを作成した管理クラスタにログインします。管理クラスタは、スーパーバイザークラスタまたはスタンドアローン管理クラスタです。
tanzu cluster credentials update CLUSTER-NAME を実行します。次のコマンドオプションに値を渡すか CLI でプロンプトを表示させることができます。
- --namespace：default など、認証情報を更新するクラスタの名前空間。
- --vsphere-user：vSphere アカウントの名前。
- --vsphere-password：vSphere アカウントのパスワード。
- --vsphere-thumbprint：vCenter Server インスタンスの TLS サムプリント。

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

AWS

このセクションは、AWS 環境には適用されません。

Azure

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

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

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

tanzu context use MGMT-CLUSTER を実行して、更新する管理クラスタにログインします。
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 コマンドを使用します。

tanzu context use MGMT-CLUSTER を実行して、更新するワークロードクラスタを作成した管理クラスタにログインします。
tanzu cluster credentials update CLUSTER-NAME を実行します。次のコマンドオプションに値を渡すか CLI でプロンプトを表示させることができます。
- --namespace：default など、認証情報を更新するクラスタの名前空間。
- --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 年間有効です。証明書を更新するには、クラスタをアップグレードするか、次の手順に従います。この手順は、期限切れになっていない有効なクラスタ証明書を対象としています。

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

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

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

kubectl get nodes -o wide

証明書の有効期限を確認します。

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

kubectl コンテキストを管理クラスタに設定します。例：
```
kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
```

ターゲットクラスタの 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.26.8+vmware.1

制御プレーンのロールアウトをトリガして証明書を更新します。

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.26.8+vmware.1
workload-slot35rp10-control-plane-ggsmj     workload-slot35rp10   workload-slot35rp10-control-plane-ggsmj     vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f   Running        42h   v1.26.8+vmware.1
workload-slot35rp10-control-plane-hxbxb     workload-slot35rp10   workload-slot35rp10-control-plane-hxbxb     vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd   Running        42h   v1.26.8+vmware.1
workload-slot35rp10-control-plane-sm4nw     workload-slot35rp10   workload-slot35rp10-control-plane-sm4nw     vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce   Running        42h   v1.26.8+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.26.8+vmware.1
...

すべてのマシンが Running である場合、証明書の更新が正常に完了したことを確認します。

kubectl コンテキストをワークロードクラスタに設定します。
```
kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
```

証明書の有効期限を再度確認します。

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 ドキュメントの次のトピックを参照してください。

vSphere 8：TKG 2 クラスタとプライベートコンテナレジストリの統合
vSphere 7：Tanzu Kubernetes クラスタでの外部コンテナレジストリの使用

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

スタンドアローン管理クラスタを使用するインターネットが制限された環境では、「vSphere でのオフライン Harbor レジストリの展開」の説明に従って、TKG_CUSTOM_IMAGE_REPOSITORY_* 変数を構成し、Harbor 仮想マシンなどの、ブートストラップ元の TKG システムイメージを含むプライベートレジストリへのアクセスを TKG クラスタに許可できます。

ADDITIONAL_IMAGE_REGISTRY_* 変数は、次に示すような、自己署名認証局 (CA) 証明書を使用する追加のレジストリとの信頼できる通信がある新しいクラスタを構成します。

CLI で管理されるパッケージをインストールするためのパッケージリポジトリとして機能するプライベートレジストリ。
TKG でホストされるアプリケーションイメージ用のスケーラブルな自己署名 Harbor レジストリ。「サービスレジストリ用の Harbor のインストール」で説明されているように、Harbor パッケージとともに展開されます。
containerd リポジトリの「イメージレジストリの構成」で説明されているような containerd の自己署名イメージレジストリ。

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

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

追加のカスタムイメージレジストリに対する信頼があるクラスベースのワークロードクラスタまたはスタンドアローン管理クラスタを構成するには、最大 3 つの追加イメージレジストリに対して次のように変数を設定します。

3 つを超えるレジストリを構成するには、「クラスベースのクラスタを作成する」で説明されている 2 段階のプロセスの手順 1 で最初の 3 つを構成し、以下の「クラスベースのクラスタがカスタムレジストリを信用するようにする」に従って生成されたマニフェストにレジストリを追加してから手順 2 でクラスタを作成します。
```
ADDITIONAL_IMAGE_REGISTRY_1: "OTHER-REGISTRY-1"
ADDITIONAL_IMAGE_REGISTRY_1_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE: "CA-BASE64-1"

ADDITIONAL_IMAGE_REGISTRY_2: "OTHER-REGISTRY-2"
ADDITIONAL_IMAGE_REGISTRY_2_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_2_CA_CERTIFICATE: "CA-BASE64-2"

ADDITIONAL_IMAGE_REGISTRY_3: "OTHER-REGISTRY-3"
ADDITIONAL_IMAGE_REGISTRY_3_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_3_CA_CERTIFICATE: "CA-BASE64-3"
```
ここで、OTHER-REGISTRY-<n> は追加のプライベートレジストリの IP アドレスまたは FQDN で、CA-BASE64-<n> は、http:// プリフィックスを持たない base64 エンコード形式の CA 証明書です。このようにするのは、このファイルはディスクに書き込まれるので標準の Unix ファイル名にする必要があるためです。

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

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

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

クラスタをカスタマイズし、新しいクラスタプランを作成するオーバーレイについては、「ytt オーバーレイ」を参照してください。ytt のダウンロードおよびインストール方法については、「Carvel ツールのインストール」を参照してください。

カスタム CA をすべての新しいクラスタに適用するか、1 つのクラウドインフラストラクチャで作成されたクラスタにのみ適用するか、または特定のクラスタ API プロバイダバージョン（クラスタ API プロバイダ vSphere v1.7.1 など）で作成されたクラスタに適用するかを選択します。
ローカルの ~/.config/tanzu/tkg/providers/ ディレクトリで、選択した範囲をカバーする ytt ディレクトリを見つけます。たとえば、/ytt/03_customizations/ はすべてのクラスタに適用され、/infrastructure-vsphere/ytt/ はすべての vSphere クラスタに適用されます。

選択した 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)'

同じ ytt ディレクトリで、新規または既存の tkg-custom-ca.pem ファイルに認証局を追加します。
クラスタを作成する前に、「（レガシー）プランベースまたは TKC クラスタの作成」の説明に従って、allow-legacy-cluster 機能を true に設定します。

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

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

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

信頼できるカスタムレジストリを既存のクラスベースのクラスタに追加するには、その Cluster オブジェクトを編集し、オブジェクト仕様の topology.variables に additionalImageRegistries 設定を追加します。

topology:
  variables:
  - name: additionalImageRegistries
    value:
    - caCert: "CA-BASE64"
      host: OTHER-REGISTRY
      skipTlsVerify: false

ここで、

OTHER-REGISTRY は、次の形式の追加のプライベートレジストリの場所です。 : 。たとえば、 10.92.127.192:8443 などです。
CA-BASE64 は Base64 エンコード形式の CA 証明書です。たとえば、LS0tLS1CRU[...] のようになります。

複数のレジストリの信頼を追加するには、複数の additionalImageRegistries 値ブロックを含めます。

topology.variables は、TKG_CUSTOM_IMAGE_REPOSITORY_* および TKG_PROXY_CA_CERT 構成変数からの imageRepository と trust セット値をブロックすることに注意してください。

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

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

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

共有サービスクラスタなど、Harbor を実行しているクラスタにコンテキストを切り替えます。
```
kubectl config use-context SERVICES-CLUSTER-CONTEXT
```
ここで、SERVICES-CLUSTER-CONTEXT はクラスタのコンテキストです。たとえば、tkg-wld-admin@tkg-wld などです。

証明書を取得します。

kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
[...]
yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
-----END CERTIFICATE-----

カスタム CA をスタンドアローン管理クラスタの kubeadmconfigtemplate に追加します。

コンテキストを管理クラスタに切り替えます。
```
kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
```
ここで、MANAGEMENT-CLUSTER-CONTEXT は管理クラスタのコンテキストです。たとえば、tkg-mgmt-admin@tkg-mgmt などです。
エディタで、クラスタの kubeadmconfigtemplate テンプレートファイルを開きます。
```
kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
```
ここで、CLUSTER-NAME は、変更する必要があるクラスタの名前です。

次に示すように、ファイルの 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"

ファイルの下部に、次のように 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)'

kubeadmconfigtemplate テンプレートファイルに変更内容を保存します。
スタンドアローン管理クラスタに変更をパッチ適用します。
```
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'

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

クラスタ認証情報の更新

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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