カスタム クラスタ認証局を使用する

クラスタ認証局（CA）が発行する署名証明書により、クラスタ コンポーネント間の安全な認証と暗号化が可能になります。デフォルトでは、Google Distributed Cloud で新しいクラスタを作成すると Cluster API によってクラスタ CA が作成されます。このドキュメントでは、Google Distributed Cloud で独自の認証局を使用する方法について説明します。カスタム クラスタ CA を使用すると、クラスタ証明書の発行と管理をより細かく制御できます。また、信頼、暗号化アルゴリズムのパラメータ、下位証明書の深さ、およびそれらの目的を制御することもできます。

カスタム CA を使用するには、CA 証明書ファイルと対応する秘密鍵ファイルで構成されるルート CA を指定します。次の必要なクラスタ CA ごとに CA 証明書と鍵ファイルのペアを指定します。

  • etcd CA: etcd CA 証明書は、Kubernetes API サーバーから etcd レプリカへの通信と、etcd レプリカ間の通信を保護します。

  • クラスタ CA: クラスタ CA の証明書は、Kubernetes API サーバーとすべての内部 Kubernetes API クライアント間の通信を保護します。クライアントには、kubelet、コントローラ マネージャー、スケジューラなどがあります。

  • フロントプロキシ CA: フロントプロキシ CA の証明書は、集約 API との通信を保護します。

CA ごとに一意の証明書と鍵のペアを指定することも、複数の CA に対して証明書と鍵のペアを再利用することもできます。

証明書と鍵のペアは、クラスタの作成（bmctl メソッドのみ）時と CA のローテーション時に適用します。カスタム クラスタ CA 機能は、すべてのクラスタタイプ（管理者、ユーザー、ハイブリッド、スタンドアロン）で動作します。

前提条件

次のルールに従って、各自でルート CA を準備する必要があります。

  • カスタム CA はルート CA で、自己署名証明書ファイルと秘密鍵ファイルから構成されます。

  • 証明書には、識別符号化規則（DER）形式を使用することをおすすめします（ASN.1 エンコード ルールの推奨事項 X.690 をご覧ください）。証明書ファイルには、先頭に ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑、末尾に ‑‑‑‑END CERTIFICATE‑‑‑‑‑ が付く base64 エンコード データが含まれている必要があります。

  • 秘密鍵には、公開鍵暗号標準（PKCS）#1 形式の使用をおすすめします。鍵ファイルには、先頭に ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑、末尾に ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑ が付く base64 エンコード データが含まれている必要があります。

  • クラスタの中断を最小限に抑えるため、カスタム CA の有効期限は 5 年未満にするべきではありません。有効期限を長くすることをおすすめします（10～30 年など）。

  • 証明書と鍵ファイルは、bmctl コマンドを実行する管理ワークステーション上に保存します。

  • bmctl コマンドを実行するユーザーには、ファイルを保存するディレクトリへのアクセス権が必要です。証明書と鍵に使用される既存のディレクトリにファイルを保存することをおすすめします。たとえば、ファイルはサービス アカウント キーとともに ~/baremetal/bmctl-workspace/.sa-keys に保存できます。

  • bmctl コマンドを実行するユーザーには、ファイルに対する読み取りアクセス権が必要です。

クラスタ作成時にカスタム CA を使用する

bmctl を使用してクラスタを作成する場合は、まず、クラスタ構成ファイルを更新して、クラスタの機能と設定を記述します。クラスタの作成時にカスタム クラスタ CA 機能を使用する場合、クラスタ構成ファイルでカスタム クラスタ CA を指定する方法として次の 2 つがあります。

  • CA 証明書ファイルと秘密鍵ファイルの両方のパスを指定する
  • 秘密鍵ファイルのパスのみを指定する

秘密鍵のみを指定した場合は、bmctl は同じディレクトリ内の対応する CA 証明書ファイルを検索します。証明書ファイルは、対応する秘密鍵ファイルと同じ名前にし、拡張子を .crt にする必要があります。たとえば、秘密鍵のパスが /custom-ca/cluster_ca.key の場合、bmctl は証明書のパスが /custom-ca/cluster_ca.crt であると想定します。

いずれの場合も、次の例のように、パスは構成ファイルの認証情報セクションで指定します。

例 1: 証明書と鍵のパスを指定する

次のクラスタ構成ファイルからの抜粋は、各クラスタ CA の証明書ファイルと鍵ファイルへのパスを指定する方法を示しています。この例では、CA 証明書と鍵ファイルは、サービス アカウントの JSON キーファイルと同じディレクトリにあります。

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

例 2: 秘密鍵のパスのみを指定する

クラスタ構成ファイルの以下の部分は、鍵ファイルへのパスのみを指定する方法を示しています。この例の CA 秘密鍵ファイルは、サービス アカウントの JSON キーファイルと同じディレクトリにあります。対応する CA 証明書ファイルは、/.sa-keys ディレクトリにも存在する必要があります。証明書ファイルの名前は鍵ファイルと同じですが、拡張子は .crt です。つまり、etcd CA 証明書ファイルの名前は etcd_ca.crt です。

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

例 3: CA 証明書と鍵ファイルの 1 つのペアを再利用する

クラスタ構成ファイルの以下の部分は、鍵ファイルへのパスのみを指定する方法を示しています。この例では、すべてのクラスタ CA に対して 1 つの証明書と鍵のペアが使用されます。CA 証明書ファイルと秘密鍵ファイルはどちらも /custom-ca ディレクトリにあります。命名規則では、CA 証明書のファイル名は custom_ca.crt になります。

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

CA ローテーション時にカスタム CA を使用する

CA をローテーションする場合は、カスタム クラスタ CA 証明書のパスと秘密鍵ファイルのパスを指定できます。その方法は、クラスタの作成時にカスタム クラスタ CA を指定する場合と同様の選択肢があります。bmctl update credentials certificate-authorities rotate コマンドの実行では、次の選択肢があります。

  • カスタム CA 証明書ファイルと秘密鍵ファイルの両方のパスを指定する。
  • カスタム CA の秘密鍵ファイルのパスのみを指定する。対応する CA 証明書ファイルは、同じディレクトリに配置し、鍵ファイルと同じ名前にする必要があります。ただし、ファイルの拡張子は .crt にします。
  • 複数のクラスタ CA に同じ証明書と鍵のパスを指定して、CA 証明書と鍵のペアを再利用する。
  • カスタム CA のパスの引数を省略する。CA をローテーションするときにカスタム CA パスを指定しないと、Google Distributed Cloud は標準のクラスタ CA を作成して使用します。

例 1: CA 証明書と秘密鍵のパスを指定する

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

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

  • CLUSTER_NAME: CA をローテーションするクラスタの名前。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。自己管理クラスタの場合、このファイルは、クラスタの kubeconfig ファイルです。
  • CLUSTER_CA_CERT_PATH: クラスタ CA 証明書ファイルのパス。
  • CLUSTER_CA_KEY_PATH: クラスタ CA 秘密鍵ファイルのパス。
  • ETCD_CA_CERT_PATH: etcd CA 証明書ファイルのパス。
  • ETCD_CA_KEY_PATH: etcd CA 秘密鍵ファイルのパス。
  • FRONT_PROXY_CA_CERT_PATH: フロントプロキシ証明書ファイルのパス。
  • FRONT_PROXY_CA_KEY_PATH: フロントプロキシ秘密鍵ファイルのパス。

例 2: 秘密鍵のパスのみを指定する

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

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

  • CLUSTER_NAME: CA をローテーションするクラスタの名前。
  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。自己管理クラスタの場合、このファイルは、クラスタの kubeconfig ファイルです。
  • CLUSTER_CA_KEY_PATH: クラスタ CA 秘密鍵ファイルのパス。
  • ETCD_CA_KEY_PATH: etcd CA 秘密鍵ファイルのパス。
  • FRONT_PROXY_CA_KEY_PATH: フロントプロキシ秘密鍵ファイルのパス。

中間 CA

バージョン 1.29 のクラスタでは、プレビュー機能として中間 CA の使用がサポートされています。この機能は、サポートされているすべてのプロダクト バージョンで同じリリース ステージにあるわけではありません。

カスタム CA のルート CA 要件と同様に、中間 CA を使用するには、3 セットの CA を準備する必要があります。各 CA は、CA 証明書ファイルと対応する秘密鍵ファイルで構成されます。次の必要なクラスタ CA ごとに CA 証明書と鍵ファイルのペアを指定します。

  • etcd CA
  • クラスタ CA
  • フロント プロキシ CA

ルート CA と同様に、CA ごとに一意の証明書と鍵のペアを指定することも、CA 構成で同じファイルパスを指定して複数の CA で証明書と鍵のペアを再利用することもできます。

中間 CA を使用する場合は、CA 証明書ファイルに証明書チェーン全体（中間 CA からルート CA までの証明書を含む）を含める必要があります。証明書は、署名された順序の逆の順序でリストされます。最後の中間 CA 証明書が最上位に表示され、ルート CA 証明書が最下位に表示されます。

次の例（ルート CA から一番下）では、順序は次のとおりです。

  • ルート CA が Intermediate-A の CA 証明書に署名する
  • Intermediate-A CA が Intermediate-B の CA 証明書に署名する
  • チェーンは、Intermediate-X CA によって署名された最後の Intermediate-Y CA 証明書まで続きます。
-----BEGIN CERTIFICATE-----
<Intermediate-Y CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-X CA CERT CONTENT>
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
<Intermediate-B CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-A CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CA CERT CONTENT>
-----END CERTIFICATE-----

この例で続けた場合、カスタム CA と同じ方法で、Intermediate-Y CA 証明書に関連付けられた秘密鍵を CA 証明書チェーンに従って渡す必要があります。

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

クラスタが中間 CA を使用しているかどうか確認するには、クラスタの CA Secret の証明書数を確認します。

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l