チュートリアル: ポリシー制御を管理する

このチュートリアルでは、Certificate Authority Service リソースにポリシー制御を実装する方法について説明します。

目標

このチュートリアルでは、次のポリシー制御を使用して、DNS 証明書の発行用に共有認証局（CA）プールを構成する方法について説明します。

ユーザー prod-dns-requester は、*.prod.example.com ドメインのエンドユーザーエンティティサーバーの TLS 証明書をリクエストできます。
ユーザー test-dns-requester は、*.test.example.com ドメインのエンドユーザーエンティティサーバーの TLS 証明書をリクエストできます。
ユーザー blank-check-requester は、CA プールから任意の種類の証明書をリクエストできます。

このチュートリアルでは、CA プールの証明書発行ポリシー、証明書テンプレート、条件付き IAM バインディングを使用して、このシナリオを実現します。

準備

CA Service のさまざまなポリシー管理を確認します。
証明書テンプレートの作成方法を確認します。
さまざまな証明書の発行シナリオで使用できる証明書プロファイルを確認します。
Common Expression Language（CEL）を使用して、証明書の発行にさまざまなポリシー制御を適用する方法を確認します。
証明書発行ポリシーの使用方法を確認します。
CA Service リソースの作成と管理のために IAM ポリシーを構成、変更、削除する方法を確認します。

CA プールの作成

CA プールを作成するには、次の手順に従います。

issuance-policy.yaml ファイルを使用する CA プールを作成するには、次の gcloud コマンドを使用します。
gcloud
```
gcloud privateca pools create POOL_NAME \
    --tier=ENTERPRISE
```
ここで
- --tier フラグは、CA プールのティアを指定するために使用されます。ティアの詳細については、オペレーションティアを選択するをご覧ください。
新しく作成した CA プールに Google 管理のリソースを使用して CA を作成するには、次の gcloud コマンドを使用します。
gcloud
```
gcloud privateca roots create CA_NAME \
   --pool=POOL_NAME \
   --subject="CN=Example DNS Root, O=Example LLC, C=US" \
   --validity="10Y" \
   --max-chain-length=1 \
   --auto-enable
```
ここで
- POOL_NAME は、CA プールの固有識別子です。
- --subject フラグは、証明書のサブジェクトの名前を渡すために使用されます。
- --validity フラグは、CA の有効期間を決定します。デフォルトの有効期間は 10 年です。
- --max-chain-length フラグは、CA で許可される下位 CA の最大深度を決定します。
- --auto-enable フラグを指定すると、CA が STAGED 状態ではなく ENABLED 状態になります。CA の状態について詳しくは、CA の状態をご覧ください。
注: CA プールを作成するユーザーには、デフォルトで CA Service オペレーションマネージャー（roles/privateca.caManager）ロールに関連付けられた権限が付与されます。ロールに関連付けられているプロジェクトレベルの権限は、リソースレベルで設定されたカスタムバインディングよりも優先されます。きめ細かいポリシー制御を作成する場合は、アカウントに、発行ポリシーと競合する可能性のあるプロジェクトレベルまたは組織レベルの権限がないことを確認してください。

テスト証明書のポリシー制御の構成

発行ポリシーの変更は直ちに有効になります。テスト用ポリシー制御を本番環境で使用する前に、テスト用ポリシー制御を構成することをおすすめします。このセクションでは、テスト用ポリシー制御を構成する方法について説明します。

テスト用の DNS テンプレートと本番環境の DNS テンプレートの両方で、サーバー TLS 証明書に同じ事前定義された値を使用する必要があります。YAML ファイル leaf_server_tls_predefined_values.yaml を作成し、次のエンドエンティティサーバーの TLS 構成をファイルにコピーします。

  keyUsage:
    baseKeyUsage:
      digitalSignature: true
      keyEncipherment: true
    extendedKeyUsage:
      serverAuth: true
  caOptions:
    isCa: false

テスト用 DNS 証明書のポリシー制御を構成する

このセクションでは、ユーザー test-dns-requester が *.test.example.com ドメインの DNS のエンドエンティティサーバー TLS 証明書をリクエストできるように、ポリシー制御を設定する方法について説明します。

テスト用証明書用の DNS 証明書テンプレートを作成する

このセクションでは、エンドエンティティサーバーの TLS 構成を含む証明書テンプレートを作成する方法について説明します。この証明書テンプレートは、*.test.example.com ドメインの DNS SAN のみを使用するように証明書を制限します。これらの制限は、Common Expression Language（CEL）式を使用して実装されます。証明書テンプレートは、証明書リクエストで指定されているすべてのサブジェクトもドロップします。

次の gcloud コマンドを使用して、エンドエンティティサーバーの TLS 拡張機能を含む証明書テンプレートを作成し、証明書リクエストで指定された subject をドロップして、許可される SAN を制限します。
gcloud
```
gcloud privateca templates create test-server-tls-template \
  --predefined-values-file  ./leaf_server_tls_predefined_values.yaml \
  --no-copy-subject \
  --copy-sans \
  --identity-cel-expression "subject_alt_names.all(san, san.type == DNS && san.value.endsWith('.test.example.com'))"
```
ここで
- --predefined-values-file フラグは、証明書テンプレートによって設定された、事前定義された X.509 値を記述する YAML ファイルを渡すために使用されます。
- --no-copy-subject フラグは、呼び出し元から指定されたサブジェクトをすべて、証明書リクエストからドロップします。
- --copy sans フラグを指定すると、証明書リクエストから SAN 拡張機能が署名付き証明書にコピーされます。
- --identity-cel-expression フラグは、発行前に証明書内の ID に対して評価される CEL 式を渡すために使用されます。CEL 式を使用してさまざまなポリシー制御を実装する方法については、CEL の使用をご覧ください。
証明書テンプレートの作成の詳細については、証明書テンプレートを作成するをご覧ください。

DNS テスト証明書の IAM バインディングを作成する

DNS CA プールのユーザー test-dns-requester@ がテストサーバーの TLS 証明書をリクエストできるようにするには、CA プールに条件付き IAM バインディングを作成します。証明書リクエストに test-server-tls-template テンプレートへの参照が含まれている場合にのみ、ユーザー test-dns-requester@ に privateca.certificateRequester ロールを付与します。CA Service の IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。

ポリシー YAML ファイル test_dns_condition.yaml を作成し、次の TLS 構成をファイルにコピーします。
```
title: test DNS binding
description: allows user to only create DNS test certificates
expression: api.getAttribute("privateca.googleapis.com/template", "") == "PROJECT_ID/-/test-server-tls-template"
```
IAM 条件で指定されるテンプレート名は、証明書リクエスト内のテンプレート名と一致する必要があります。したがって、CEL 式の privateca.googleapis.com/template 属性でプロジェクト ID を指定する場合は、証明書をリクエストするときにプロジェクト ID も指定する必要があります。CEL 式でプロジェクト番号を指定する場合は、証明書リクエストでプロジェクト番号も指定する必要があります。
次の gcloud コマンドを使用して、test-dns-requester@ が CA プールの本番環境のテスト用 TLS 証明書のみをリクエストできるようにするポリシー制御を追加します。
gcloud
```
gcloud privateca pools add-iam-policy-binding POOL_NAME \
    --role='roles/privateca.certificateRequester' \
    --member='user:test-dns-requester@' \
    --condition-from-file=./test_dns_condition.yaml
```
ここで
- --role フラグは、メンバーに割り当てるロール名を渡すために使用されます。CA Service の IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。
- --member フラグは、バインディングを追加するメンバーを渡すために使用されます。
- condition-from-file フラグは、CEL 条件を持つファイル名を渡すために使用されます。
次の gcloud を使用して、test-dns-requester@ が「test-server-tls-template」証明書テンプレートを使用できるようにするポリシーコントロールを追加します。
gcloud
```
gcloud privateca templates add-iam-policy-binding test-server-tls-template \
    --role='roles/privateca.templateUser' \
    --member='user:test-dns-requester@'
```
ここで
- --role フラグは、メンバーに割り当てるロール名を渡すために使用されます。CA Service の IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。
- --member フラグは、バインディングを追加するメンバーを渡すために使用されます。
IAM ポリシーの構成の詳細については、IAM ポリシーを構成するをご覧ください。

本番環境の証明書のポリシー制御の構成

ポリシー管理をテストしたら、それらのポリシー管理を本番環境で使用できます。

本番環境 DNS 証明書のポリシー制御を構成する

このセクションでは、ユーザー prod-dns-requester が DNS .prod.example.com ドメインのエンドエンティティ TLS 証明書をリクエストできるようにポリシー制御を設定する方法について説明します。

本番環境 DNS 証明書用の証明書テンプレートを作成する

次の手順を使用して、エンドエンティティサーバーの TLS 構成を含む証明書テンプレートを作成します。この証明書テンプレートでは、*.prod.example.com ドメインの DNS SAN のみを使用するように証明書が制限されます。これらの制限は、Common Expression Language（CEL）式を使用して実装されます。証明書テンプレートは、証明書リクエストで指定されているすべてのサブジェクトもドロップします。

次の gcloud コマンドを使用して、証明書テンプレート prod-server-tls-template を作成します。

gcloud

  gcloud privateca templates create prod-server-tls-template \
    --predefined-values-file ./leaf_server_tls_predefined_values.yaml \
    --no-copy-subject \
    --copy-sans \
    --identity-cel-expression "subject_alt_names.all(san, san.type == DNS && san.value.endsWith('.prod.example.com'))"

ここで

--predefined-values-file フラグは、証明書テンプレートによって設定された、事前定義された X.509 値を記述する YAML ファイルを渡すために使用されます。
--no-copy-subject フラグは、呼び出し元から指定されたサブジェクトをすべて、証明書リクエストからドロップします。
--copy sans フラグを指定すると、証明書リクエストから SAN 拡張機能が署名付き証明書にコピーされます。
--identity-cel-expression フラグは、発行前に証明書内の ID に対して評価される CEL 式を渡すために使用されます。CEL 式の詳細については、CEL 式の使用をご覧ください。

証明書テンプレートの作成の詳細については、証明書テンプレートを作成するをご覧ください。

gcloud privateca templates create コマンドの詳細については、gcloud privateca templates create をご覧ください。

本番環境 DNS IAM バインディングを作成する

DNS CA プール内のユーザー prod-dns-requester@ が本番環境サーバー TLS 証明書をリクエストできるようにするには、CA プールに条件付き IAM バインディングを作成します。証明書リクエストに prod-server-tls-template テンプレートへの参照が含まれている場合にのみ、ユーザー prod-dns-requester@ に privateca.certificateRequester ロールを付与します。IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。

ポリシー YAML ファイル prod_dns_condition.yaml を作成し、次の TLS 構成をファイルにコピーします。

title: Production DNS binding
description: allows user to only create DNS production certificates
expression: api.getAttribute("privateca.googleapis.com/template", "") == "PROJECT_ID/-/prod-server-tls-template"

次の gcloud コマンドを使用して、prod-dns-requester@ が CA プールから本番環境サーバー TLS 証明書のみをリクエストできるようにするポリシー制御を追加します。
gcloud
```
gcloud privateca pools add-iam-policy-binding POOL_NAME \
    --role='roles/privateca.certificateRequester' \
    --member='user:prod-dns-requester@' \
    --condition-from-file=./prod_dns_condition.yaml
```
ここで
- --role フラグは、メンバーに割り当てるロール名を渡すために使用されます。CA Service の IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。
- --member フラグは、バインディングを追加するメンバーを渡すために使用されます。
- condition-from-file フラグは、CEL 条件を持つファイル名を渡すために使用されます。
gcloud privateca pools add-iam-policy-binding コマンドの詳細については、gcloud privateca pools add-iam-policy-binding をご覧ください。
prod-dns-requester@ が「prod-server-tls-template」証明書テンプレートを使用できるようにするポリシー制御を追加するには、次の gcloud コマンドを使用します。
gcloud
```
gcloud privateca templates add-iam-policy-binding prod-server-tls-template \
    --role='roles/privateca.templateUser' \
    --member='user:prod-dns-requester@'
```
ここで
- --role フラグは、メンバーに割り当てるロール名を渡すために使用されます。CA Service の IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。
- --member フラグは、バインディングを追加するメンバーを渡すために使用されます。

制限のないユーザーポリシー制御

ユーザー blank-check-requester@ が制限なしで任意の証明書をリクエストできるようにするには、条件なしで IAM バインディングを作成し、ユーザーに privateca.certificateRequester ロールを付与します。

gcloud

gcloud privateca pools add-iam-policy-binding POOL_NAME \
  --role='roles/privateca.certificateRequester' \
  --member='user:blank-check-requester@example.com'

ここで

--role フラグの値によって、ユーザーに割り当てられるロールが決まります。CA Service の IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。
--member フラグの値によって、ロールを割り当てるユーザーが決まります。

ポリシー制御のテスト

証明書発行と IAM ポリシーを実装したら、これらのポリシーを確認してテストし、期待どおりに動作することを確認する必要があります。

すべてのポリシーバインディングを取得する

CA プールに実装されているすべての IAM ポリシーを取得します。CA プールのすべての IAM ポリシーを取得するには、gcloud privateca pools get-iam-policy コマンドを使用します。

gcloud

gcloud privateca pools get-iam-policy POOL_NAME

ここで

POOL_NAME は、CA プールの固有識別子です。

gcloud privateca pools get-iam-policy コマンドの詳細については、gcloud privateca pools get-iam-policy をご覧ください。

証明書を生成する

このセクションでは、汎用証明書、テスト用 DNS 証明書、本番環境 DNS 証明書の生成について説明します。

テスト用 DNS 証明書を生成する

ユーザー test-dns-requester@ が CA プールからテスト用 DNS 証明書をリクエストできるようにするには、次の gcloud コマンドを使用します。

gcloud

gcloud privateca certificates create test-dns-1 \
    --project=PROJECT_ID \
    --issuer-location=LOCATION \
    --issuer-pool=POOL_NAME \
    --dns-san=foo.bar.test.example.com \
    --generate-key \
    --key-output-file=KEY_FILE_NAME \
    --cert-output-file=test_dns_cert.pem \
    --template=projects/PROJECT_ID/locations/LOCATION/certificateTemplates/test-server-tls-template

ここで

--issuer-location フラグは、証明書のロケーションを設定するために使用されます。ロケーションの完全なリストについては、ロケーションをご覧ください。
--issuer-pool フラグは、証明書をリクエストする CA プールを設定します。
--dns-san フラグは、1 つ以上の DNS SAN をカンマ区切りで設定するために使用されます。
--generate-key フラグは、マシン上で新しい RSA-2048 秘密鍵の生成をトリガーします。
--key-output-file フラグは、生成された秘密鍵が書き込まれるパスを設定するために使用されます（PEM 形式）。
--cert-output-file フラグは、PEM エンコードされた証明書チェーンファイルが書き込まれるパスを設定するために使用されます（end-entity から root の順に並べます）。
--template フラグは、この証明書の発行に使用する証明書テンプレートの名前を設定するために使用されます。指定したテンプレートは、発行元の CA プールと同じロケーションに存在する必要があります。証明書テンプレートの詳細については、証明書テンプレートと発行ポリシーの概要をご覧ください。

本番環境の証明書を生成する

これで、ユーザー prod-dns-requester が CA プールから本番環境の DNS 証明書をリクエストできるようになりました。--dns-san=foo.bar.prod.example.com は、指定した値を持つ DNS タイプの SAN を証明書リクエストに追加します。

gcloud

gcloud privateca certificates create prod-dns-1 \
    --project=PROJECT_ID \
    --issuer-location=LOCATION \
    --issuer-pool=POOL_NAME \
    --dns-san=foo.bar.prod.example.com \
    --generate-key \
    --key-output-file=KEY_FILE_NAME \
    --cert-output-file=prod_dns_cert.pem \
    --template=projects/PROJECT_ID/locations/LOCATION/certificateTemplates/prod-server-tls-template

ここで

--issuer-location フラグは、証明書のロケーションを設定するために使用されます。ロケーションの完全なリストについては、ロケーションをご覧ください。
--issuer-pool フラグは、証明書をリクエストする CA プールを設定します。
--dns-san フラグは、1 つ以上の DNS SAN をカンマ区切りで設定するために使用されます。
--generate-key フラグは、マシン上で新しい RSA-2048 秘密鍵の生成をトリガーします。
--key-output-file フラグは、生成された秘密鍵が書き込まれるパスを設定するために使用されます（PEM 形式）。
--cert-output-file フラグは、PEM エンコードされた証明書チェーンファイルが書き込まれるパスを設定するために使用されます（end-entity から root の順に並べます）。
--template フラグは、この証明書の発行に使用する証明書テンプレートの名前を設定するために使用されます。指定したテンプレートは、発行元の CA プールと同じロケーションに存在する必要があります。証明書テンプレートの詳細については、証明書テンプレートと発行ポリシーの概要をご覧ください。

汎用証明書を生成する

ユーザー blank-check-requester@ は、gcloud privateca certificates create コマンドを使用して CA プールから任意の証明書をリクエストできます。

CA プールから証明書をリクエストするには、CA サービスによって作成された公開鍵 / 秘密鍵を使用できます。証明書のリクエストの詳細については、証明書をリクエストし発行済み証明書を表示するをご覧ください。

クリーンアップ

このセクションでは、CA プールの IAM ポリシーを削除する方法について説明します。

特定の IAM バインディングを削除する

blank-check-requester ユーザーの CA プールに対する IAM 条件付きバインディングを削除するには、次の gcloud コマンドを使用します。

gcloud

gcloud privateca pools remove-iam-policy-binding POOL_NAME \
    --role='roles/privateca.certificateRequester' \
    --member='user:blank-check-requester@'

ここで

--role フラグの値によって、ユーザーに割り当てられるロールが決まります。CA Service の IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。
--member フラグの値によって、ロールを割り当てるユーザーが決まります。

特定の IAM バインディングを削除する場合は、IAM バインディングに関連するすべての情報を gcloud privateca pools remove-iam-policy-binding コマンドで指定する必要があります。1 つのロールとメンバーに、異なる条件を持つ IAM バインディングが複数存在することがあります。異なるバインディングを誤って削除しないように、IAM バインディングに関連する詳細をすべて指定することが重要です。

gcloud privateca pools remove-iam-policy-binding コマンドの詳細については、gcloud privateca pools remove-iam-policy-binding をご覧ください。

すべての IAM 条件付きバインディングを削除する

IAM バインディングを削除するには、gcloud privateca pools remove-iam-policy-binding コマンドを使用します。IAM 条件付きバインディングを削除する場合は、バインディングに関するすべての情報を指定する必要があります。1 つのユーザーとロールに複数の条件付きバインディングを設定できます。条件付きバインディングをすべて削除するには、gcloud コマンドで --all フラグを使用します。

次の gcloud コマンドを使用して、prod-code-signing-requester ユーザーのすべてのバインディングを削除します。

gcloud

gcloud privateca pools remove-iam-policy-binding POOL_NAME \
    --role='roles/privateca.certificateRequester' \
    --member='user:prod-code-signing-requester@' \
    --all

ここで

--role フラグの値によって、ユーザーに割り当てられるロールが決まります。CA Service の IAM ロールと権限の詳細については、IAM を使用したアクセス制御をご覧ください。
--member フラグの値によって、ロールを割り当てるユーザーが決まります。

チュートリアル: ポリシー制御を管理する

目標

準備

CA プールの作成

gcloud

gcloud

テスト証明書のポリシー制御の構成

テスト用 DNS 証明書のポリシー制御を構成する

テスト用証明書用の DNS 証明書テンプレートを作成する

gcloud

DNS テスト証明書の IAM バインディングを作成する

gcloud

gcloud

本番環境の証明書のポリシー制御の構成

本番環境 DNS 証明書のポリシー制御を構成する

本番環境 DNS 証明書用の証明書テンプレートを作成する

gcloud

本番環境 DNS IAM バインディングを作成する

gcloud

gcloud

制限のないユーザー ポリシー制御

gcloud

ポリシー制御のテスト

すべてのポリシー バインディングを取得する

gcloud

証明書を生成する

テスト用 DNS 証明書を生成する

gcloud

本番環境の証明書を生成する

gcloud

汎用証明書を生成する

クリーンアップ

特定の IAM バインディングを削除する

gcloud

すべての IAM 条件付きバインディングを削除する

gcloud

制限のないユーザーポリシー制御

すべてのポリシーバインディングを取得する