このドキュメントでは、Certificate Authority Service（CAS）を使用して証明書をリクエストする手順について説明します。
Google Distributed Cloud（GDC）エアギャップ内で信頼を確立し、通信を保護するには、Certificate Authority Service から ACME 対応または無効の証明書をリクエストします。
このドキュメントは、プロジェクト内で証明書のライフサイクルを管理するアプリケーション デベロッパーやデータ サイエンティストなど、アプリケーション オペレーター グループ内のユーザーを対象としています。詳細については、 GDC エアギャップ ドキュメントの対象読者をご覧ください。
始める前に
証明書をリクエストする前に、必要な権限をリクエストして環境を準備する必要があります。
IAM ロールをリクエストする
証明書リクエストを作成、表示、削除するには、組織 IAM 管理者に連絡して、認証局のプロジェクト名前空間で CA Service 証明書リクエスタ （certificate-authority-service-certificate-requester）ロールを付与してもらいます。
環境を準備する
gdcloud CLI をまだダウンロードしてインストールしていない場合は、ダウンロードしてインストールします。
kubeconfig ファイルを生成 して
kubectlアクセスを構成します。
ACME モードが有効になっている CA を使用して証明書をリクエストする
認証局が ACME モードでホストされている場合、準備が完了すると、ステータスに ACME サーバー URL が出力されます。
Distributed Cloud 環境から CA ACME サーバー URL を収集します。
kubectl get certificateauthorities CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -r '.status.acme.uri'
次のように置き換えます。
CA_NAME: CA の名前。ルート CA またはサブ CA を指定できます。USER_PROJECT_NAMESPACE: ユーザー プロジェクトが存在する名前空間の名前
ACME モードが無効になっている CA を使用して証明書をリクエストする
ACME モードが無効になっている証明書リクエストを作成するには、CertificateRequest リソースを作成して、Distributed Cloud エアギャップ インスタンスに適用する必要があります。これには次の 2 つの方法があります。
CertificateResourceを作成し、リソースに CSR を含めます。- GDC で自動生成された秘密鍵を使用して
CertificateResourceを作成し、証明書の構成をカスタム値として指定します。
CSR を使用して証明書をリクエストする
CertificateRequestリソースを作成し、cert-request.yamlという名前の YAML ファイルとして保存します。秘密鍵を使用して証明書署名リクエスト（CSR）を作成し、リソースに追加します。必要に応じて、テンプレートの名前を
certificateTemplateフィールドに入力して、事前構成された X.509 パラメータのセットで証明書を発行できます。apiVersion: pki.security.gdc.goog/v1 kind: CertificateRequest metadata: name: CERT_REQ_NAME namespace: USER_PROJECT_NAMESPACE spec: certificateAuthorityRef: name: CA_NAME namespace: USER_PROJECT_NAMESPACE csr: CSR certificateTemplate: TEMPLATE_NAME signedCertificateSecret: SECRET_NAME notBefore: VALIDITY_START_TIME notAfter: VALIDITY_END_TIME subjectOverride: SUBJECT_OVERRIDE次の変数を置き換えます。
変数 説明 CERT_REQ_NAME CertificateRequestリソースの名前USER_PROJECT_NAMESPACE ユーザー プロジェクトが存在する名前空間の名前 CA_NAME CA の名前。ルート CA またはサブ CA を指定できます。 CSR CA を使用して署名する証明書署名リクエスト SECRET_NAME 秘密鍵と 署名付き CA 証明書を保持する Kubernetes Secret の名前 次の省略可能な変数を置き換えます。
変数 説明 TEMPLATE_NAME 使用する事前定義された証明書テンプレートの名前。使用可能なテンプレートの一覧と競合の詳細については、 事前定義された証明書テンプレートをご覧ください。 VALIDITY_START_TIME 証明書が有効と見なされる時刻。この値 は YYYY-MM-DDTHH:MM:SSZ形式（例:2025-10-19T21:45:30Z）にする必要があります。設定しない場合、証明書は発行後 すぐに有効になります。VALIDITY_END_TIME 証明書の有効期限が切れる時刻。この値は YYYY-MM-DDTHH:MM:SSZ形式（例:2026-01-17T18:25:40Z）にする必要があります。設定しない場合、証明書は開始時刻から 90 日後に期限切れになります。SUBJECT_OVERRIDE 発行された証明書で使用するカスタムのサブジェクト。 CSR のサブジェクト情報をオーバーライドします。この値は、ASN.1 DER エンコードされた X.509 サブジェクトとして指定します。 カスタム リソースを Distributed Cloud インスタンスに適用します。
kubectl apply -f cert-request.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIGMANAGEMENT_API_SERVER_KUBECONFIGは、Management API サーバーの kubeconfig ファイルのパスに置き換えます。証明書リクエストの準備状況を確認します。
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificaterequest.pki.security.gdc.goog/CERT_REQ_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'次のように置き換えます。
MANAGEMENT_API_SERVER_KUBECONFIG: Management API サーバーの kubeconfig ファイルのパスUSER_PROJECT_NAMESPACE: ユーザー プロジェクトが存在する名前空間の名前CERT_REQ_NAME:CertificateRequestリソースの名前
出力は次のようになります。
{ "lastTransitionTime": "2025-01-27T12:22:59Z", "message": "Certificate is issued", "observedGeneration": 1, "reason": "Issued", "status": "True", "type": "Ready" }証明書の Secret 名を取得します。
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificaterequest.pki.security.gdc.goog/CERT_REQ_NAME -ojson | jq -r '.spec.signedCertificateSecret'次のように置き換えます。
MANAGEMENT_API_SERVER_KUBECONFIG: Management API サーバーの kubeconfig ファイルのパスUSER_PROJECT_NAMESPACE: ユーザー プロジェクトが存在する名前空間の名前CERT_REQ_NAME:CertificateRequestリソースの名前
出力には、署名付き証明書を含む
SECRET_NAMEが表示されます。test-jwk-1
自動生成された鍵を使用して証明書をリクエストする
CertificateRequestリソースを作成し、cert-request.yamlという名前の YAML ファイルとして保存します。証明書に選択した値を入力します。必要に応じて、テンプレートの名前を
certificateTemplateフィールドに入力して、事前構成された X.509 パラメータのセットで証明書を発行できます。apiVersion: pki.security.gdc.goog/v1 kind: CertificateRequest metadata: name: CERT_REQ_NAME namespace: USER_PROJECT_NAMESPACE spec: certificateAuthorityRef: name: CA_NAME namespace: USER_PROJECT_NAMESPACE certificateConfig: subjectConfig: commonName: COMMON_NAME organization: ORGANIZATION locality: LOCALITY state: STATE country: COUNTRY dnsNames: - DNS_NAMES ipAddresses: - IP_ADDRESSES rfc822Names: - RFC822NAMES uris: - URIS certificateTemplate: TEMPLATE_NAME signedCertificateSecret: SECRET_NAME notBefore: VALIDITY_START_TIME notAfter: VALIDITY_END_TIME subjectOverride: SUBJECT_OVERRIDE次の変数を置き換えます。
変数 説明 CERT_REQ_NAME CertificateRequestリソースの名前USER_PROJECT_NAMESPACE ユーザー プロジェクトが存在する名前空間の名前 CA_NAME CA の名前。ルート CA またはサブ CA を指定できます。 SECRET_NAME 秘密鍵と 署名付き CA 証明書を保持する Kubernetes Secret の名前 次の省略可能な変数を置き換えます。
CertificateRequestリソースのspec.certificateConfig.subjectConfigブロックから少なくとも 1 つのフィールドを含める必要があります。変数 説明 COMMON_NAME 証明書の共通名 ORGANIZATION 証明書で使用する組織 LOCALITY 証明書の地域 STATE 証明書で使用する都道府県 COUNTRY 証明書の国 DNS_NAMES 証明書に設定する dNSName subjectAltNamesのリストIP_ADDRESS 証明書に設定する ipAddress subjectAltNamesのリストRFC822_NAMES 証明書に設定する rfc822Name subjectAltNamesのリストURIS 証明書に設定する uniformResourceIdentifier subjectAltNamesのリストTEMPLATE_NAME 使用する事前定義された証明書テンプレートの名前。使用可能なテンプレートの一覧と競合の詳細については、 事前定義された証明書テンプレートをご覧ください。 VALIDITY_START_TIME 証明書が有効と見なされる時刻。この値 は YYYY-MM-DDTHH:MM:SSZ形式（例:2025-10-19T21:45:30Z）にする必要があります。設定しない場合、証明書は発行後 すぐに有効になります。VALIDITY_END_TIME 証明書の有効期限が切れる時刻。この値は YYYY-MM-DDTHH:MM:SSZ形式（例:2026-01-17T18:25:40Z）にする必要があります。設定しない場合、証明書は開始時刻から 90 日後に期限切れになります。SUBJECT_OVERRIDE 発行された証明書で使用するカスタムのサブジェクト。 CSR のサブジェクト情報をオーバーライドします。この値は、ASN.1 DER エンコードされた X.509 サブジェクトとして指定します。 カスタム リソースを Distributed Cloud インスタンスに適用します。
kubectl apply -f cert-request.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIGMANAGEMENT_API_SERVER_KUBECONFIGは、Management API サーバーの kubeconfig ファイルのパスに置き換えます。証明書リクエストの準備状況を確認します。
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificaterequest.pki.security.gdc.goog/CERT_REQ_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'次のように置き換えます。
MANAGEMENT_API_SERVER_KUBECONFIG: Management API サーバーの kubeconfig ファイルのパスUSER_PROJECT_NAMESPACE: ユーザー プロジェクトが存在する名前空間の名前CERT_REQ_NAME:CertificateRequestリソースの名前
出力は次のようになります。
{ "lastTransitionTime": "2025-01-27T12:22:59Z", "message": "Certificate is issued", "observedGeneration": 1, "reason": "Issued", "status": "True", "type": "Ready" }証明書の Secret 名を取得します。
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificaterequest.pki.security.gdc.goog/CERT_REQ_NAME -ojson | jq -r '.spec.signedCertificateSecret'次のように置き換えます。
MANAGEMENT_API_SERVER_KUBECONFIG: Management API サーバーの kubeconfig ファイルのパスUSER_PROJECT_NAMESPACE: ユーザー プロジェクトが存在する名前空間の名前CERT_REQ_NAME:CertificateRequestリソースの名前
出力には、署名付き証明書を含む
SECRET_NAMEが表示されます。test-jwk-1
証明書リクエストを一覧表示する
certificaterequests パラメータを使用して、すべての CertificateRequest リソースを一覧表示します。
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificaterequest.pki.security.gdc.goog
次のように置き換えます。
MANAGEMENT_API_SERVER_KUBECONFIG: Management API サーバーの kubeconfig ファイルのパスUSER_PROJECT_NAMESPACE: ユーザー プロジェクトが存在する名前空間の名前
次に、agtest-project 名前空間を使用するコマンドの例を示します。
kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig -n agtest-project get certificaterequest.pki.security.gdc.goog
想定される出力は次のようになります。
NAME READY AGE
test-externalca-subca-cert-req-with-csr True 17h
test-externalca-subca-cert-req-with-csr-override True 17h
証明書を削除する
証明書を削除するには、対応する CertificateRequest カスタム リソースを削除する必要があります。この操作を行うと、CAS データベースからリソースが削除されます。
削除する
CertificateRequestの名前を確認します。証明書リクエストを 一覧表示すると、名前を見つけやすくなります。CertificateRequestリソースを削除します。kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE delete certificaterequest.pki.security.gdc.goog/CERT_REQ_NAME次のように置き換えます。
MANAGEMENT_API_SERVER_KUBECONFIG: Management API サーバーの kubeconfig ファイルのパスUSER_PROJECT_NAMESPACE: ユーザー プロジェクトが存在する名前空間の名前CERT_REQ_NAME:CertificateRequestリソースの名前
証明書リクエストの上限とクリーンアップ
システムの安定性を維持し、リソースの使用率が高くなるのを防ぐため、CAS では CertificateRequest カスタム リソースの数に上限が適用され、オプションの自動クリーンアップ機能が提供されています。
証明書リクエストの割り当て
CAS では、組織あたりの CertificateRequest カスタム リソースの数に割り当てが適用され、デフォルトの上限は 5,000 です。この上限を超えると、CAS と Management API サーバーのパフォーマンスが低下する可能性があります。
CertificateRequest リソースの合計数が割り当てに近づくと（上限の 80% と 90% など）、新しいリクエストを作成するときにコマンド出力に警告が表示されます。割り当てに達した後に CertificateRequest を作成しようとすると、リクエストは拒否されます。
次のようなエラー メッセージが表示されることがあります。
Error from server (Forbidden): error when creating "cert-request.yaml":
admission webhook "certificaterequests.pki.security.gdc.goog" denied the
request: the number of certificate requests has exceeded the per organization
limit of {LIMIT}. Please refer to the guide PLATAUTH-G2102 for troubleshooting
this issue
このエラーが発生した場合は、古い
リソースや不要なCertificateRequestリソースを削除する必要があります。割り当てを調整するには、組織内のインフラストラクチャ オペレーター グループのメンバーにお問い合わせください。
runbook
PLATAUTH-G2102の手順に沿って、割り当てをオーバーライドできます。
自動クリーンアップ
自動クリーンアップを有効にして、期限切れの CertificateRequest リソースを削除できます。この機能を使用すると、構成可能な猶予期間後にリソースが削除されるため、リソースを解放できます。猶予期間は、証明書の有効期限が切れてから CertificateRequest リソースが削除されるまでの期間を定義します。
自動クリーンアップはデフォルトで無効になっています。組織内のインフラストラクチャ オペレーター グループのメンバーは、runbook PLATAUTH-G2103の手順に沿って、この機能を有効にして猶予期間を構成できます。 猶予期間が設定されていない場合、またはゼロに設定されている場合、この機能は無効のままになります。