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

このチュートリアルでは、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 のみを使用するように証明書を制限します。これらの制限は、CEL（Common Expression Language）を使用して実装されます。証明書テンプレートは、証明書リクエストで指定されているすべてのサブジェクトもドロップします。

次の 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 のみを使用するように証明書を制限します。これらの制限は、CEL（Common Expression Language）を使用して実装されます。証明書テンプレートは、証明書リクエストで指定されているすべてのサブジェクトもドロップします。

次の 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 証明書を生成する

ユーザー 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 バインディングを削除する場合は、gcloud privateca pools remove-iam-policy-binding コマンドで IAM バインディングに関連するすべての情報を指定する必要があります。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 フラグを使用します。

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

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

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

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