Pinniped および Dex の TLS 証明書の構成と管理
このトピックでは、Tanzu Kubernetes Grid で Pinniped および Dex のカスタム TLS 証明書を構成する方法について説明します。また、Tanzu Kubernetes Grid で Dex 証明書を更新する方法についても説明します。
カスタム TLS 証明書の構成
デフォルトでは、Tanzu Kubernetes Grid は自己署名の Issuer を使用して、Pinniped および Dex への HTTPS トラフィックを保護する TLS 証明書を生成します。必要に応じて、次のように、管理クラスタを展開した後にデフォルトの構成を更新できます。
- カスタムの
ClusterIssuerリソースまたは独自の TLS シークレットを設定します。以下の「ClusterIssuerリソースまたは TLS シークレットの設定」を参照してください。 - 管理クラスタの Pinniped アドオン シークレットを再展開して、Pinniped 構成を更新します。以下の「Pinniped 構成の更新」を参照してください。
注Tanzu Kubernetes Grid は、LDAP ID プロバイダについてのみ Dex を展開します。OIDC ID プロバイダを管理クラスタの作成時に構成するか、作成後の手順で構成すると、Dex は展開されません。
ClusterIssuer リソースまたは TLS シークレットの設定
カスタムの ClusterIssuer リソースを使用して TLS 証明書を生成する場合は、次の手順を実行します。
cert-managerが管理クラスタで実行されていることを確認します。デフォルトでは、このコンポーネントはすべての管理クラスタで実行されます。- 管理クラスタ内の既存の
ClusterIssuerリソースの名前を取得します。詳細については、cert-manager ドキュメントの「Issuer Configuration」を参照してください。 - 管理クラスタの Pinniped アドオン シークレットの
values.yamlセクションにあるcustom_cluster_issuerフィールドにClusterIssuer名を指定し、変更を適用します。手順については、以下の「Pinniped 構成の更新」を参照してください。このセクションの手順を完了すると、Pinniped と Dex の両方の証明書チェーンがClusterIssuerによって署名されます。
独自の TLS シークレットを直接指定する場合は、次の手順を実行します。
-
Pinniped サービスの IP アドレスまたは DNS ホスト名 (
pinniped-supervisor) を取得します。Dex サービスの LDAP ID プロバイダを使用している場合は、dexsvcを取得します。-
pinniped-supervisorサービス：-
サービスのタイプが
LoadBalancer（NSX Advanced Load Balancer、Amazon Web Services (AWS)、Azure などのロード バランサを使用する vSphere）に設定されている場合は、次を実行してサービスの外部アドレスを取得します。kubectl get service pinniped-supervisor -n pinniped-supervisor -
サービスのタイプが
NodePort（ロード バランサなしの vSphere）に設定されている場合、サービスの IP アドレスは、vSphere 制御プレーン エンドポイントと同じです。IP アドレスを取得するには、次のコマンドを実行します。kubectl get configmap cluster-info -n kube-public -o yaml
-
-
（LDAP のみ）
dexsvcサービス：-
サービスのタイプが
LoadBalancer（NSX Advanced Load Balancer、Amazon Web Services (AWS)、Azure などのロード バランサを使用する vSphere）に設定されている場合は、次を実行してサービスの外部アドレスを取得します。kubectl get service dexsvc -n tanzu-system-auth -
サービスのタイプが
NodePort（ロード バランサなしの vSphere）に設定されている場合、サービスの IP アドレスは、vSphere 制御プレーン エンドポイントと同じです。IP アドレスを取得するには、次のコマンドを実行します。kubectl get configmap cluster-info -n kube-public -o yaml
-
-
-
OIDC ID プロバイダを使用している場合は、
pinniped-supervisor名前空間にkubernetes.io/tlsシークレットを作成します。LDAP ID プロバイダを使用している場合は、同じ名前の 2 つのkubernetes.io/tlsシークレットを作成します。1 つは Pinniped サービス用としてpinniped-supervisor名前空間に作成し、もう 1 つは Dex サービス用としてtanzu-system-auth名前空間に作成します。TLS シークレットを作成するには、次を実行します。kubectl create secret generic SECRET-NAME -n SECRET-NAMESPACE --type kubernetes.io/tls --from-file tls.crt=FILENAME-1.crt --from-file tls.key=FILENAME-2.pem --from-file ca.crt=FILENAME-3.pemプレースホルダ テキストを次のように置き換えます。
SECRET-NAMEは、シークレット用に選択する名前です。たとえば、my-secretなどです。SECRET-NAMESPACEは、シークレットを作成する名前空間です。これは、Pinniped の場合はpinniped-supervisor、Dex の場合はtanzu-system-authでなければなりません。FILENAME-*は、tls.crt、tls.key、またはca.crtの名前です。Pinniped の TLS シークレットで指定する TLS 証明書には、上記の手順で取得した Pinniped サービスの IP アドレスまたは DNS ホスト名を含める必要があります。同様に、Dex の TLS 証明書には、上記で取得した Dex サービスの IP アドレスまたは DNS ホスト名を含める必要があります。ca.crtフィールドは必須で、TLS 証明書の検証に使用される CA バンドルが含まれています。
たとえば、Pinniped のシークレットは次のようになります。
apiVersion: v1 kind: Secret metadata: name: my-secret namespace: pinniped-supervisor type: kubernetes.io/tls data: tls.crt: | MIIC2DCCAcCgAwIBAgIBATANBgkqh ... tls.key: | MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... ca.crt: | MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...シークレットが正しく生成されている場合、
tls.crtをopenssl x509 -in tls.crt -textでデコードすると、[サブジェクト代替名 (Subject Alternative Name)] フィールドに IP アドレスまたは DNS ホスト名が表示されます。 -
管理クラスタの Pinniped アドオン シークレットの
values.yamlセクションにあるcustom_tls_secretフィールドにシークレット名を指定し、変更を適用します。手順については、以下の「Pinniped 構成の更新」を参照してください。 -
Pinniped サービスの DNS ホスト名を構成する場合は、管理クラスタの Pinniped アドオン シークレットの
values.yamlセクションのpinniped.supervisor_svc_external_dnsフィールドで、Pinniped スーパーバイザーに関連付けられている FQDN を指定します。pinniped.supervisor_svc_external_dnsの値はhttps://で始まる必要があります。詳細については、「自動管理パッケージの values.yaml 設定」を参照してください。次に、変更を適用します。手順については、以下の「Pinniped 構成の更新」を参照してください。たとえば、Pinniped スーパーバイザー サービスの IP アドレスに解決するには、DNS プロバイダにAレコードを作成するなどして、このホスト名の DNS を個別に構成する必要があります。このホスト名は、Pinniped スーパーバイザー用に構成する TLS 証明書でサブジェクト代替名としてリストされている必要があります。
Pinniped 構成の更新
変更を適用するには、次の手順に従って Pinniped 構成を更新します。
-
管理クラスタの Pinniped アドオン シークレットをファイルに保存し、シークレットの
values.yamlセクションで Base64 エンコード文字列をデコードします。kubectl get secret CLUSTER-NAME-pinniped-package -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 -d > FILENAME.yamlプレースホルダ テキストを次のように置き換えます。
CLUSTER-NAMEは、管理クラスタの名前です。FILENAMEは、シークレットに使用するファイルの名前です。たとえば、values.yamlです。
-
デコードされたテキストで、次のいずれかを行います。
-
上記で
ClusterIssuerリソースを準備した場合は、custom_cluster_issuerフィールドにリソースの名前を指定します。例：--- infrastructure_provider: vsphere tkg_cluster_role: management custom_cluster_issuer: "my-cluster-issuer-name" pinniped: cert_duration: 2160h cert_renew_before: 360h supervisor_svc_endpoint: https://10.168.217.220:31234 supervisor_ca_bundle_data: LS0tLS1CRUdJTiBDRVJUSUZJQ0F…… ... -
上記で独自の TLS シークレットを準備した場合は、
custom_tls_secretフィールドにシークレットの名前を指定します。例：--- infrastructure_provider: vsphere tkg_cluster_role: management custom_tls_secret: "my-tls-secret-name" pinniped: cert_duration: 2160h cert_renew_before: 360h supervisor_svc_endpoint: https://10.168.217.220:31234 supervisor_ca_bundle_data: LS0tLS1CRUdJTiBDRVJUSUZJQ0F…… ...custom_tls_secretフィールドを構成すると、custom_cluster_issuerは無視されます。Pinniped サービスの DNS ホスト名を構成する場合は、
pinniped.supervisor_svc_external_dnsフィールドで Pinniped スーパーバイザーに使用する FQDN を指定します。次に例を示します。... pinniped: cert_duration: 2160h cert_renew_before: 360h supervisor_svc_endpoint: https://0.0.0.0:31234 supervisor_ca_bundle_data: ca_bundle_data_of_supervisor_svc supervisor_svc_external_ip: 0.0.0.0 supervisor_svc_external_dns: https://pinniped.example.com ...
-
-
values.yamlセクションを再度エンコードし、Pinniped アドオン シークレットを更新します。このコマンドは、環境の OS によって異なります。例：Linux：
kubectl patch secret CLUSTER-NAME-pinniped-package -n tkg-system -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=mergemacOS：
kubectl patch secret CLUSTER-NAME-pinniped-package -n tkg-system -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge -
変更が正常に適用されたことを確認します。
-
pinnipedアプリケーションのステータスを取得します。kubectl get app CLUSTER-NAME-pinniped -n tkg-system返されたステータスが Reconcile failed の場合は、次のコマンドを実行してエラーの詳細を取得します。
kubectl get app CLUSTER-NAME-pinniped -n tkg-system -o yaml -
tanzu mc kubeconfig get --export-file ./KUBECONFIG-MC-CLUSTER-NAMEコマンドを実行して、管理クラスタの kubeconfig ファイルを生成します。次に、kubeconfig を使用して、kubectl get pods --kubeconfig ./KUBECONFIG-MC-CLUSTER-NAMEなどのコマンドを実行します。また、管理クラスタがワークロード クラスタを管理している場合は、tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --export-file ./KUBECONFIG-WORKLOAD-CLUSTER-NAMEを実行してから、既存の各クラスタに対してkubectl get pods --kubeconfig ./KUBECONFIG-WORKLOAD-CLUSTER-NAMEを実行します。
-
Dex サービス提供証明書と Dex CA 証明書の更新
LDAP ID 管理を使用するクラスタでは、次の場合に Dex 証明書を更新できます。
- Dex CA 証明書が更新されたか、有効期限が切れている場合。
- Dex CA に関連付けられているプライベート キーが侵害されている場合。
前提条件
この手順を実行する前に、次の点を確認してください。
- LDAP IDP で Pinniped アドオンが構成されていること。詳細については、「Identity Providers - LDAP」を参照してください。
kubectl get service dexsvc -n tanzu-system-authコマンドを使用して、Dex サービスのアドレスを取得していること。
Dex サービス提供証明書の更新
-
現在ワークロード クラスタのコンテキストにいる場合は、
kubectlコンテキストを管理クラスタに変更します。詳細については、「Retrieve Workload Cluster kubeconfig」を参照してください。 -
現在の Dex サービス提供証明書をダウンロードします。
openssl s_client -connect ADDRESS:PORT -showcerts </dev/null | openssl x509 -noout -text > /tmp/OLD-FILE.txtここで、
ADDRESSは、Tanzu Kubernetes Grid の Dex サービス アドレスです。OLD-FILEは、サービス提供証明書テキスト ファイルを保存するための名前（before.txtなど）です。
-
現在の Dex サービス提供証明書シークレットを削除して、
cert-managerが再作成できるようにします。kubectl delete secret -n tanzu-system-auth dex-cert-tls次に、出力例を示します。
secret "dex-cert-tls" deleted -
新しい Dex サービス提供証明書が作成されていることを確認します。
kubectl get secret -n tanzu-system-auth次に、出力例を示します。
$kubectl get secret -n tanzu-system-auth NAME TYPE DATA AGE default-token-cg8f2 kubernetes.io/service-account-token 3 6m5s dex-ca-key-pair kubernetes.io/tls 3 5m50s dex-cert-tls kubernetes.io/tls 3 2s dex-token-p96gl kubernetes.io/service-account-token 3 6m3s -
Dex ポッドを再起動します。
kubectl delete pod -n tanzu-system-auth -l app=dex次に、出力例を示します。
$ kubectl delete pod -n tanzu-system-auth -l app=dex pod DEX-POD deleted -
新しい Dex サービス提供証明書をダウンロードします。
openssl s_client -connect ADDRESS:PORT -showcerts </dev/null | openssl x509 -noout -text > /tmp/NEW-FILE.txtここで、
ADDRESSは、Tanzu Kubernetes Grid の Dex サービス アドレスです。NEW-FILEは、新しいサービス提供証明書テキスト ファイルを保存するための名前（after.txtなど）です。
-
古い証明書と新しい証明書を比較して、新しい証明書が作成されていることを確認します。
diff /tmp/OLD-FILE /tmp/NEW-FILEここで、
OLD-FILEは、古い Dex サービス提供証明書の名前です。NEW-FILEは、新しい Dex サービス提供証明書の名前です。
Dex CA 証明書の更新
-
現在の Dex CA 証明書をダウンロードします。
kubectl get secret -n tanzu-system-auth dex-cert-tls -o jsonpath={.data.ca\\.crt} | base64 -d | openssl x509 -noout -text > /tmp/OLD-FILE.txtOLD-FILEは、サービス提供証明書テキスト ファイルを保存するための名前（ca-before.txtなど）です。 -
現在の Dex サービス提供証明書をダウンロードします。
openssl s_client -connect ADDRESS:PORT -showcerts </dev/null | openssl x509 -noout -text > /tmp/OLD-FILE.txtここで、
-
ADDRESSは、Tanzu Kubernetes Grid の Dex サービス アドレスです。 -
OLD-FILEは、サービス提供証明書テキスト ファイルを保存するための名前（cert-before.txtなど）です。
-
-
現在の Dex CA データをダウンロードします。
kubectl get oidcidentityprovider upstream-oidc-identity-provider -n pinniped-supervisor -o jsonpath={.spec.tls.certificateAuthorityData} | base64 -d | openssl x509 -noout -text > /tmp/OLD-FILE.txtOLD-FILEは、サービス提供証明書テキスト ファイルを保存するための名前（ca-data-before.txtなど）です。 -
Dex CA 証明書シークレットを削除して、
cert-managerが再作成できるようにします。kubectl delete secret -n tanzu-system-auth dex-ca-key-pair次に、出力例を示します。
secret "dex-ca-key-pair" deleted -
新しい Dex CA 証明書が作成されていることを確認します。
kubectl get secret -n tanzu-system-auth次に、出力例を示します。
$ kubectl get secret -n tanzu-system-auth NAME TYPE DATA AGE default-token-cg8f2 kubernetes.io/service-account-token 3 25m dex-ca-key-pair kubernetes.io/tls 3 18s dex-cert-tls kubernetes.io/tls 3 17s dex-token-p96gl kubernetes.io/service-account-token 3 25m -
現在の Dex サービス提供証明書シークレットを削除して、
cert-managerが再作成できるようにします。kubectl delete secret -n tanzu-system-auth dex-cert-tls次に、出力例を示します。
secret "dex-cert-tls" deleted -
新しい Dex サービス提供証明書が作成されていることを確認します。
kubectl get secret -n tanzu-system-auth次に、出力例を示します。
kubectl get secret -n tanzu-system-auth NAME TYPE DATA AGE default-token-cg8f2 kubernetes.io/service-account-token 3 6m5s dex-ca-key-pair kubernetes.io/tls 3 5m50s dex-cert-tls kubernetes.io/tls 3 2s dex-token-p96gl kubernetes.io/service-account-token 3 6m3s -
Pinniped の展開後ジョブを削除します。
kubectl delete job -n pinniped-supervisor pinniped-post-deploy-job次に、出力例を示します。
job.batch "pinniped-post-deploy-job" deleted -
Pinniped アドオンを更新して変更をすばやく同期し、アドオンが変更を調整するまで数分待ちます。
kubectl patch app pinniped -n tkg-system -p '{"spec":{"syncPeriod":"30s"}}' --type mergekubectl wait app pinniped -n tkg-system --for condition=ReconcileSucceeded --timeout 5m -
新しい Dex CA 証明書をダウンロードします。
kubectl get secret -n tanzu-system-auth dex-cert-tls -o jsonpath={.data.ca\\.crt} | base64 -d | openssl x509 -noout -text > /tmp/NEW-FILE.txtここで、
NEW-FILEは、新しい Dex CA 証明書テキスト ファイルを保存するための名前（ca-after.txtなど）です。 -
新しい Dex サービス提供証明書をダウンロードします。
openssl s_client -connect ADDRESS:PORT -showcerts </dev/null | openssl x509 -noout -text > /tmp/NEW-FILE.txtここで、
ADDRESSは、Tanzu Kubernetes Grid の Dex サービス アドレスです。-
NEW-FILEは、新しい Dex サービス提供証明書テキスト ファイルを保存するための名前（after.txtなど）です。 -
新しい Dex CA データをダウンロードします。
kubectl get oidcidentityprovider upstream-oidc-identity-provider -n pinniped-supervisor -o jsonpath={.spec.tls.certificateAuthorityData} | base64 -d | openssl x509 -noout -text > /tmp/NEW-FILE.txtここで、
NEW-FILEは、新しい Dex CA データ テキスト ファイルを保存するための名前（ca-data-after.txtなど）です。 -
新旧の CA 証明書を比較して、新しい CA 証明書が作成されていることを確認します。
diff /tmp/OLD-FILE /tmp/NEW-FILEここで、
OLD-FILEは、古い Dex CA 証明書の名前です。NEW-FILEは、古い Dex CA 証明書の名前です。
-
新旧のサービス提供証明書を比較して、新しいサービス提供証明書が作成されていることを確認します。
diff /tmp/OLD-FILE /tmp/NEW-FILEここで、
OLD-FILEは、古い Dex サービス提供証明書の名前です。NEW-FILEは、古い Dex サービス提供証明書の名前です。
-
新旧の CA データを比較して、新しい CA データが作成されていることを確認します。
diff /tmp/OLD-FILE /tmp/NEW-FILEここで、
OLD-FILEは、古い Dex CA データ ファイルの名前です。NEW-FILEは、古い Dex CA データ ファイルの名前です。
