Gérer les contrôles de règles

Ce tutoriel vous explique comment implémenter des contrôles des règles sur les ressources Certificate Authority Service.

Objectifs

Ce tutoriel explique comment configurer un pool d'autorités de certification (CA) partagé pour l'émission de certificats DNS avec les contrôles de règles suivants :

  • L'utilisateur prod-dns-requester peut demander des certificats TLS de serveur d'entité de fin pour le domaine *.prod.example.com.
  • L'utilisateur test-dns-requester peut demander des certificats TLS de serveur d'entité de fin pour le domaine *.test.example.com.
  • L'utilisateur blank-check-requester peut demander n'importe quel type de certificat à partir du pool d'AC.

Ce tutoriel utilise la règle d'émission de certificats d'un pool d'autorités de certification, des modèles de certificats et des liaisons IAM conditionnelles pour réaliser ce scénario.

Avant de commencer

Créer un pool d'autorités de certification

Pour créer un pool d'autorités de certification, suivez les instructions ci-dessous :

  1. Pour créer un pool d'autorités de certification qui utilise le fichier issuance-policy.yaml, exécutez la commande gcloud suivante :

    gcloud

    gcloud privateca pools create POOL_NAME --location=LOCATION --tier=ENTERPRISE

    Où :

    • LOCATION est l'emplacement où vous souhaitez créer le pool d'autorités de certification. Pour obtenir la liste complète des emplacements, consultez Emplacements.
    • L'option --tier permet de spécifier le niveau du pool de CA. Pour en savoir plus sur les niveaux, consultez Sélectionner les niveaux d'opération.

  2. Pour créer une autorité de certification avec des ressources gérées par Google dans le pool d'autorités de certification nouvellement créé, utilisez la commande gcloud suivante :

    gcloud

    gcloud privateca roots create CA_NAME \
    --pool=POOL_NAME \
    --location=LOCATION \
    --subject="CN=Example DNS Root, O=Example LLC, C=US" \
    --validity="10Y" \
    --max-chain-length=1 \
    --auto-enable

    Où :

    • POOL_NAME est l'identifiant unique du pool d'autorités de certification.
    • LOCATION est l'emplacement où vous souhaitez créer le pool d'autorités de certification. Pour obtenir la liste complète des emplacements, consultez Emplacements.
    • L'option --subject permet de transmettre le nom du sujet du certificat.
    • L'option --validity détermine la période de validité de l'autorité de certification. La période de validité par défaut est de 10 ans.
    • L'indicateur --max-chain-length détermine la profondeur maximale des CA subordonnées autorisées sous une CA.
    • L'indicateur --auto-enable crée l'autorité de certification dans l'état ENABLED plutôt que dans l'état STAGED. Pour en savoir plus sur les états de l'autorité de certification, consultez États de l'autorité de certification.

Configurer les contrôles des règles pour les certificats de test

Les modifications apportées au règlement sur l'émission prennent effet immédiatement. Nous vous recommandons de configurer les contrôles des règles de test avant de les utiliser en production. Cette section explique comment configurer les contrôles des règles de test.

Pour les modèles DNS de test et de production, vous devez utiliser les mêmes valeurs prédéfinies pour les certificats TLS du serveur. Créez un fichier YAML leaf_server_tls_predefined_values.yaml et copiez-y la configuration TLS du serveur d'entité finale suivante.

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

Configurer les contrôles des règles pour les certificats DNS de test

Cette section explique comment définir des contrôles de règles pour permettre à l'utilisateur test-dns-requester de demander des certificats TLS de serveur d'entité finale pour le DNS dans le domaine *.test.example.com.

Créer un modèle de certificat DNS pour les certificats de test

Cette section explique comment créer un modèle de certificat contenant la configuration TLS du serveur d'entité finale. Ce modèle de certificat limite l'utilisation des certificats aux SAN DNS sur le domaine *.test.example.com. Ces restrictions sont implémentées à l'aide d'une expression CEL (Common Expression Language). Le modèle de certificat supprime également tout sujet spécifié dans la demande de certificat.

  1. Utilisez la commande gcloud suivante pour créer le modèle de certificat qui contient les extensions TLS du serveur d'entité finale, supprime tout subject spécifié dans la demande de certificat et limite les SAN autorisés.

    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'))"

    Où :

    • L'indicateur --predefined-values-file permet de transmettre un fichier YAML qui décrit les valeurs X.509 prédéfinies définies par le modèle de certificat.
    • L'indicateur --no-copy-subject supprime tous les sujets spécifiés par l'appelant de la demande de certificat.
    • L'indicateur --copy sans garantit que l'extension SAN de la demande de certificat est copiée dans le certificat signé.
    • L'indicateur --identity-cel-expression est utilisé pour transmettre une expression CEL qui est évaluée par rapport à l'identité du certificat avant son émission. Pour en savoir plus sur l'utilisation des expressions CEL pour implémenter différents contrôles de règles, consultez Utiliser CEL.

    Pour en savoir plus sur la création de modèles de certificat, consultez Créer un modèle de certificat.

Créer des liaisons IAM pour les certificats de test DNS

Pour autoriser l'utilisateur test-dns-requester@ du pool d'AC DNS à demander des certificats TLS de serveur de test, créez une liaison IAM conditionnelle sur le pool d'AC. N'accordez le rôle privateca.certificateRequester à l'utilisateur test-dns-requester@ que si la demande de certificat contient une référence au modèle test-server-tls-template. Pour en savoir plus sur les rôles et les autorisations IAM pour le service CA, consultez Contrôle des accès avec IAM.

  1. Créez un fichier YAML de stratégie test_dns_condition.yaml et copiez-y la configuration TLS suivante.

      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"

    Le nom du modèle fourni dans la condition IAM doit correspondre à celui de la demande de certificat. Par conséquent, si vous fournissez un ID de projet dans l'attribut privateca.googleapis.com/template de l'expression CEL, vous devez également fournir un ID de projet lorsque vous demandez le certificat. Si vous fournissez un numéro de projet dans l'expression CEL, vous devez également fournir un numéro de projet dans la demande de certificat.

  2. Utilisez la commande gcloud suivante pour ajouter des contrôles de règles qui permettent à test-dns-requester@ de ne demander que des certificats TLS de test de production au pool d'autorités de certification.

    gcloud

    gcloud privateca pools add-iam-policy-binding POOL_NAME \
    --location=LOCATION \
    --role='roles/privateca.certificateRequester' \
    --member='user:test-dns-requester@' \
    --condition-from-file=./test_dns_condition.yaml

    Où :

    • L'indicateur --role permet de transmettre le nom du rôle à attribuer à un membre. Pour en savoir plus sur les rôles et les autorisations IAM pour le service CA, consultez Contrôle des accès avec IAM.
    • L'option --member permet de transmettre le membre pour lequel ajouter la liaison.
    • L'indicateur condition-from-file est utilisé pour transmettre le nom du fichier avec la condition CEL.

  3. Utilisez la commande gcloud suivante pour ajouter des contrôles de règles qui permettent à test-dns-requester@ d'utiliser le modèle de certificat "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@'

    Où :

    • L'indicateur --role permet de transmettre le nom du rôle à attribuer à un membre. Pour en savoir plus sur les rôles et les autorisations IAM pour le service CA, consultez Contrôle des accès avec IAM.
    • L'option --member permet de transmettre le membre pour lequel ajouter la liaison.

    Pour en savoir plus sur la configuration des stratégies IAM, consultez Configurer des stratégies IAM.

Configurer les contrôles des règles pour les certificats de production

Une fois que vous avez testé vos contrôles des règles, vous pouvez les utiliser dans votre environnement de production.

Configurer les paramètres de règles pour les certificats DNS de production

Cette section explique comment définir des contrôles de règles pour permettre à l'utilisateur prod-dns-requester de demander des certificats TLS d'entité finale pour le domaine DNS .prod.example.com.

Créer un modèle de certificat pour les certificats DNS de production

Suivez les instructions ci-dessous pour créer un modèle de certificat contenant la configuration TLS du serveur d'entité finale. Ce modèle de certificat limite l'utilisation des certificats aux SAN DNS sur le domaine *.prod.example.com. Ces restrictions sont implémentées à l'aide d'une expression CEL (Common Expression Language). Le modèle de certificat supprime également tout sujet spécifié dans la demande de certificat.

Créez un modèle de certificat prod-server-tls-template à l'aide de la commande gcloud suivante.

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'))"

Où :

  • L'option --predefined-values-file permet de transmettre un fichier YAML qui décrit toutes les valeurs X.509 prédéfinies définies par le modèle de certificat.
  • L'option --no-copy-subject supprime tous les sujets spécifiés par l'appelant de la demande de certificat.
  • L'indicateur --copy sans garantit que l'extension SAN de la demande de certificat est copiée dans le certificat signé.
  • L'indicateur --identity-cel-expression est utilisé pour transmettre une expression CEL qui est évaluée par rapport à l'identité du certificat avant son émission. Pour en savoir plus sur les expressions CEL, consultez Utiliser des expressions CEL.

Pour en savoir plus sur la création de modèles de certificat, consultez Créer un modèle de certificat.

Pour en savoir plus sur la commande gcloud privateca templates create, consultez gcloud privateca templates create.

Créer une liaison IAM DNS de production

Pour autoriser l'utilisateur prod-dns-requester@ du pool d'autorités de certification DNS à demander des certificats TLS de serveur de production, créez une liaison IAM conditionnelle sur le pool d'autorités de certification. N'attribuez le rôle privateca.certificateRequester à l'utilisateur prod-dns-requester@ que si la demande de certificat contient une référence au modèle prod-server-tls-template. Pour en savoir plus sur les rôles et les autorisations IAM, consultez Contrôle des accès avec IAM.

  1. Créez un fichier YAML de stratégie prod_dns_condition.yaml et copiez-y la configuration TLS suivante.

    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"

  2. Utilisez la commande gcloud suivante pour ajouter des contrôles de règles qui permettent à prod-dns-requester@ de ne demander que les certificats TLS du serveur de production à partir du pool d'autorités de certification.

    gcloud

    gcloud privateca pools add-iam-policy-binding POOL_NAME \
    --location=LOCATION \
    --role='roles/privateca.certificateRequester' \
    --member='user:prod-dns-requester@' \
    --condition-from-file=./prod_dns_condition.yaml

    Où :

    • L'indicateur --role permet de transmettre le nom du rôle à attribuer à un membre. Pour en savoir plus sur les rôles et les autorisations IAM pour le service CA, consultez Contrôle des accès avec IAM.
    • L'option --member permet de transmettre le membre pour lequel ajouter la liaison.
    • L'indicateur condition-from-file est utilisé pour transmettre le nom du fichier avec la condition CEL.

    Pour en savoir plus sur la commande gcloud privateca pools add-iam-policy-binding, consultez gcloud privateca pools add-iam-policy-binding.

  3. Pour ajouter des contrôles de stratégie qui permettent à prod-dns-requester@ d'utiliser le modèle de certificat "prod-server-tls-template", utilisez la commande gcloud suivante :

    gcloud

    gcloud privateca templates add-iam-policy-binding prod-server-tls-template \
    --role='roles/privateca.templateUser' \
    --member='user:prod-dns-requester@'

    Où :

    • L'indicateur --role permet de transmettre le nom du rôle à attribuer à un membre. Pour en savoir plus sur les rôles et les autorisations IAM pour le service CA, consultez Contrôle des accès avec IAM.
    • L'option --member permet de transmettre le membre pour lequel ajouter la liaison.

Contrôles des règles utilisateur sans restriction

Pour autoriser l'utilisateur blank-check-requester@ à demander n'importe quel certificat sans aucune limite, créez une liaison IAM sans conditionnelle, en attribuant à l'utilisateur le rôle privateca.certificateRequester.

gcloud

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

Où :

  • La valeur du flag --role détermine le rôle attribué à l'utilisateur. Pour en savoir plus sur les rôles et les autorisations IAM pour le service CA, consultez Contrôle des accès avec IAM.
  • La valeur du signalement --member détermine l'utilisateur auquel le rôle est attribué.

Remplacez les éléments suivants :

  • POOL_NAME : identifiant unique du pool d'autorités de certification.
  • LOCATION : emplacement du pool d'autorités de certification. Pour obtenir la liste complète des emplacements, consultez la section Emplacements.

Tester les contrôles des règles

Une fois que vous avez implémenté vos règles IAM et d'émission de certificats, il est important de les examiner et de les tester pour vous assurer qu'elles fonctionnent comme prévu.

Récupérer toutes les liaisons de stratégie

Récupérez toutes les stratégies IAM implémentées dans votre pool d'autorités de certification. Pour récupérer toutes les stratégies IAM du pool d'autorités de certification, utilisez la commande gcloud privateca pools get-iam-policy :

gcloud

gcloud privateca pools get-iam-policy POOL_NAME --location=LOCATION

Remplacez les éléments suivants :

  • POOL_NAME : identifiant unique du pool d'autorités de certification.
  • LOCATION : emplacement du pool d'autorités de certification. Pour obtenir la liste complète des emplacements, consultez la section Emplacements.

Pour en savoir plus sur la commande gcloud privateca pools get-iam-policy, consultez gcloud privateca pools get-iam-policy.

Générer des certificats

Cette section fournit des informations sur la génération de certificats à usage général, ainsi que de certificats DNS de test et de production.

Générer des certificats DNS de test

Pour autoriser l'utilisateur test-dns-requester@ à demander des certificats DNS de test à partir du pool d'AC, utilisez la commande gcloud suivante :

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

Où :

  • L'option --dns-san permet de définir un ou plusieurs SAN DNS séparés par une virgule.
  • L'indicateur --generate-key déclenche la génération d'une nouvelle clé privée RSA-2048 sur votre machine.
  • L'indicateur --key-output-file permet de définir le chemin d'accès où la clé privée générée est écrite (au format PEM).
  • L'indicateur --cert-output-file permet de définir le chemin d'accès au fichier de chaîne de certificats encodé au format PEM (ordonné de l'entité finale à la racine).
  • L'indicateur --template permet de définir le nom du modèle de certificat que vous souhaitez utiliser pour émettre ce certificat. Le modèle spécifié doit se trouver au même emplacement que le pool d'autorités de certification émettrices. Pour en savoir plus sur les modèles de certificat, consultez Présentation des modèles de certificat et des règles d'émission.

Remplacez les éléments suivants :

  • PROJECT_ID : identifiant unique du projet.
  • LOCATION : emplacement du pool d'autorités de certification à partir duquel le certificat est demandé. Pour obtenir la liste complète des emplacements, consultez Emplacements.
  • POOL_NAME : identifiant unique du pool d'autorités de certification.

Générer des certificats de production

L'utilisateur prod-dns-requester peut désormais demander des certificats DNS de production à partir du pool d'AC. --dns-san=foo.bar.prod.example.com ajoute un SAN de type DNS avec la valeur spécifiée à la demande de certificat.

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

Où :

  • L'option --issuer-location permet de définir l'emplacement du certificat. Pour obtenir la liste complète des emplacements, consultez Emplacements.
  • L'indicateur --issuer-pool définit le pool d'autorités de certification à partir duquel le certificat est demandé.
  • L'option --dns-san permet de définir un ou plusieurs SAN DNS séparés par une virgule.
  • L'indicateur --generate-key déclenche la génération d'une nouvelle clé privée RSA-2048 sur votre machine.
  • L'indicateur --key-output-file permet de définir le chemin d'accès où la clé privée générée est écrite (au format PEM).
  • L'indicateur --cert-output-file permet de définir le chemin d'accès au fichier de chaîne de certificats encodé au format PEM (ordonné de l'entité finale à la racine).
  • L'option --template permet de définir le nom du modèle de certificat à utiliser pour émettre ce certificat. Le modèle spécifié doit se trouver au même emplacement que le pool d'autorités de certification émettrices. Pour en savoir plus sur les modèles de certificat, consultez Présentation des modèles de certificat et des règles d'émission.

Générer des certificats à usage général

L'utilisateur blank-check-requester@ peut demander n'importe quel certificat du pool d'AC à l'aide de la commande gcloud privateca certificates create.

Pour demander un certificat à partir d'un pool d'autorités de certification, vous pouvez utiliser une clé publique/privée créée par CA Service. Pour en savoir plus sur la demande de certificats, consultez Demander un certificat et afficher les certificats émis.

Effectuer un nettoyage

Cette section explique comment supprimer des règles IAM pour un pool d'AC.

Supprimer une liaison IAM spécifique

Pour supprimer les liaisons conditionnelles IAM sur le pool d'AC pour l'utilisateur blank-check-requester, utilisez la commande gcloud suivante :

gcloud

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

Où :

  • La valeur du flag --role détermine le rôle attribué à l'utilisateur. Pour en savoir plus sur les rôles et les autorisations IAM pour le service CA, consultez Contrôle des accès avec IAM.
  • La valeur du flag --member détermine l'utilisateur auquel le rôle est attribué.

Lorsque vous supprimez une liaison IAM spécifique, vous devez fournir toutes les informations associées à la liaison IAM dans la commande gcloud privateca pools remove-iam-policy-binding. Un rôle et un membre peuvent avoir plusieurs liaisons IAM avec des conditions différentes. Il est important de fournir tous les détails concernant la liaison IAM pour éviter de supprimer accidentellement une autre liaison.

Pour en savoir plus sur la commande gcloud privateca pools remove-iam-policy-binding, consultez gcloud privateca pools remove-iam-policy-binding.

Supprimer toutes les liaisons conditionnelles IAM

Pour supprimer une liaison IAM, vous pouvez utiliser la commande gcloud privateca pools remove-iam-policy-binding. Lorsque vous supprimez une liaison conditionnelle IAM, vous devez fournir toutes les informations sur la liaison. Un utilisateur et un rôle peuvent avoir plusieurs liaisons conditionnelles. Pour supprimer toutes les liaisons conditionnelles, utilisez l'option --all dans votre commande gcloud.

Utilisez la commande gcloud suivante pour supprimer toutes les liaisons pour l'utilisateur prod-code-signing-requester.

gcloud

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

Où :

  • La valeur du flag --role détermine le rôle attribué à l'utilisateur. Pour en savoir plus sur les rôles et les autorisations IAM pour le service CA, consultez Contrôle des accès avec IAM.
  • La valeur du flag --member détermine l'utilisateur auquel le rôle est attribué.