Exiger des règles de plate-forme basées sur la validation continue pour tous les clusters GKE

Cette page explique comment utiliser le service de règles d'administration pour exiger que les clusters GKE utilisent une ou plusieurs règles de plate-forme basées sur la validation continue (CV). Vous spécifiez les règles de plate-forme basées sur la validation requises dans les contraintes personnalisées. Vous pouvez ensuite appliquer les contraintes personnalisées dans la règle d'organisation.

Coûts

Ce guide utilise les produits Google Cloud suivants :

  • Autorisation binaire, mais la CV est disponible gratuitement pendant la phase bêta
  • Les règles et les contraintes d'organisation sont offertes gratuitement.

Avant de commencer

  1. Activer l'autorisation binaire
  2. Configurez la validation continue (CV) avec des règles de plate-forme basées sur la vérification et au moins une règle de plate-forme basée sur la vérification pour la CV.

Rôles requis

Pour obtenir les autorisations nécessaires à la création des contraintes et à l'application des règles d'administration, demandez à votre administrateur de vous accorder le rôle IAM d'administrateur des règles d'administration (roles/orgpolicy.policyAdmin) sur votre organisation Google Cloud. Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Créer une contrainte personnalisée pour la CV

Console

  1. Dans Google Cloud Console, accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  2. Sur la page Règles de l'organisation, cliquez sur Contrainte personnalisée.

  3. Si vous y êtes invité, cliquez sur Passer à l'organisation parente. Pour en savoir plus sur les organisations, consultez la Présentation du service de règles d'organisation.

  4. Dans Détails de la contrainte, saisissez les informations suivantes dans les champs :

    1. Nom à afficher : nom à afficher pour votre contrainte, par exemple Require a Binary Authorization continuous validation policy for all GKE clusters. Vous utiliserez le nom à afficher pour rechercher la contrainte une fois qu'elle aura été enregistrée. Le champ "Nom à afficher" ne doit pas comporter plus de 200 caractères.

    2. ID de la contrainte : ID de votre contrainte, par exemple RequireBinAuthzCVPolicy.

    3. Description (facultatif) : description conviviale de la contrainte, qui sera affichée dans un message d'erreur en cas de non-respect de la règle. Le champ de description ne doit pas comporter plus de 2 000 caractères.

  5. Dans Application, procédez comme suit :

    1. Dans Types de ressources, saisissez container.googleaips.com/Cluster.

    2. Dans Méthode d'application, sélectionnez Appliquer lors de la création et de la mise à jour.

    3. Saisissez une expression dans le champ Condition. Ce champ ne doit pas comporter plus de 1000 caractères. La contrainte personnalisée est appliquée lorsque la condition est évaluée à true. La condition est une expression dans la syntaxe CEL (Common Expression Language). Vous pouvez combiner des expressions avec and (&&) et or (||) pour créer une condition complexe. CEL est un langage d'expression de type C. Pour en savoir plus sur la syntaxe et la sémantique du CEL, consultez la page https://github.com/google/cel-spec. Pour saisir la condition, procédez comme suit :

      1. Cliquez sur Modifier la condition.

      2. Saisissez une expression pour vérifier l'existence d'une règle de plate-forme de CV. La condition suivante exige qu'une liaison de règle de plate-forme de CV existe et que la règle de plate-forme ait un nom spécifique :

        resource.binaryAuthorization.policyBindings.exists(policy, policy.name == "projects/PROJECT_ID/platforms/gke/policies/POLICY_ID")
        

        Remplacez les éléments suivants :

        • PROJECT_ID : ID du projet de votre règle de plate-forme. Le projet doit appartenir à la même organisation.
        • POLICY_ID : ID de la règle de votre plate-forme.

        La condition suivante nécessite l'existence de deux liaisons de règles de plate-forme de CV, chacune ayant un nom de règle de plate-forme spécifique.

        resource.binaryAuthorization.policyBindings.exists(policy, policy.name == "projects/PROJECT_ID1/platforms/gke/policies/POLICY_ID1") && resource.binaryAuthorization.policyBindings.exists(policy, policy.name == "projects/PROJECT_ID2/platforms/gke/policies/POLICY_ID2")
        
        • PROJECT_ID1 : ID du projet de votre première règle de plate-forme. Le projet doit appartenir à la même organisation.
        • POLICY_ID1 : ID de règle de la première règle de plate-forme.
        • PROJECT_ID2 : ID du projet de votre deuxième règle de plate-forme.
        • POLICY_ID2 : ID de règle de la deuxième règle de plate-forme.

        • Cliquez sur Enregistrer.

    4. Dans Action, sélectionnez Autoriser.

  6. Pour créer votre contrainte personnalisée, cliquez sur Créer une contrainte.

gcloud

  1. Créez un fichier YAML pour la contrainte personnalisée :

    name: organizations/ORGANIZATION_ID/customConstraints/custom.CONSTRAINT_ID
    resource_types: container.googleapis.com/Cluster
    method_types:
      - CREATE
      - UPDATE
    condition: >-
      CONDITION
    action_type: ACTION
    display_name: DISPLAY_NAME
    description: DESCRIPTION
    

    Remplacez les éléments suivants :

    • ORGANIZATION_ID : ID de votre organisation, par exemple 123456789.
    • CONSTRAINT_ID : ID de contrainte, par exemple RequireBinAuthzCVPolicy.
    • CONDITION : saisissez une expression pour vérifier l'existence d'une règle de plate-forme de CV. Ce champ ne doit pas comporter plus de 1000 caractères. La contrainte personnalisée est appliquée lorsque la condition est évaluée à true. La condition est une expression dans la syntaxe CEL (Common Expression Language). Vous pouvez combiner des expressions avec and (&&) et or (||) pour créer une condition complexe. CEL est un langage d'expression de type C. Pour en savoir plus sur la syntaxe et la sémantique du CEL, consultez la page https://github.com/google/cel-spec. La condition suivante nécessite qu'une liaison de règle de plate-forme de CV existe et que la règle de plate-forme ait un nom spécifique :

      resource.binaryAuthorization.policyBindings.exists(policy, policy.name == "projects/PROJECT_ID/platforms/gke/policies/POLICY_ID")
      

      Remplacez les éléments suivants :

      • PROJECT_ID : ID du projet de votre règle de plate-forme. Le projet doit appartenir à la même organisation.
      • POLICY_ID : ID de la règle de votre plate-forme.

      La condition suivante nécessite l'existence de deux liaisons de règles de plate-forme de CV, chacune ayant un nom de règle de plate-forme spécifique.

      resource.binaryAuthorization.policyBindings.exists(policy, policy.name == "projects/PROJECT_ID1/platforms/gke/policies/POLICY_ID1") && resource.binaryAuthorization.policyBindings.exists(policy, policy.name == "projects/PROJECT_ID2/platforms/gke/policies/POLICY_ID2")
      
      • PROJECT_ID1 : ID du projet de votre première règle de plate-forme. Le projet doit appartenir à la même organisation.
      • POLICY_ID1 : ID de règle de la première règle de plate-forme.
      • PROJECT_ID2 : ID du projet de votre deuxième règle de plate-forme.
      • POLICY_ID2 : ID de règle de la deuxième règle de plate-forme.

      • ACTION : action à effectuer si la condition est remplie. Peut être défini sur ALLOW ou DENY.

      • DISPLAY_NAME : nom convivial de la contrainte, par exemple Require a Binary Authorization continuous validation policy for all GKE clusters. Le champ "Nom à afficher" ne doit pas comporter plus de 200 caractères.

      • DESCRIPTION : description conviviale de la contrainte, qui sera affichée dans un message d'erreur en cas de non-respect de la règle. Le champ de description ne doit pas comporter plus de 2 000 caractères.

    • Appliquez la contrainte personnalisée :

      gcloud org-policies set-custom-constraint CUSTOM_CONSTRAINT_PATH
      

      Remplacez CUSTOM_CONSTRAINT_PATH par le chemin d'accès de votre définition de contrainte personnalisée.

    • Vérifiez que la contrainte personnalisée existe :

      gcloud org-policies list-custom-constraints \
          --organization=ORGANIZATION_ID
      

      Le résultat ressemble à ce qui suit :

      CUSTOM_CONSTRAINT: custom.RequireBinAuthzCVPolicy
      ACTION_TYPE: ALLOW
      METHOD_TYPES: CREATE,UPDATE
      RESOURCE_TYPES: container.googleapis.com/Cluster
      DISPLAY_NAME: This cluster requires the continuous validation policy: projects/my-project/platforms/gke/policies/my-policy
      

Pour appliquer la contrainte personnalisée que vous avez créée, créez une règle d'organisation.

Utiliser une règle d'organisation pour appliquer la contrainte personnalisée

Pour appliquer la nouvelle contrainte personnalisée, créez une règle d'administration qui fait référence à la contrainte, puis appliquez-la.

Console

Pour appliquer la contrainte, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  2. Sélectionnez l'outil de sélection de projets, puis l'organisation.

  3. Recherchez et sélectionnez votre contrainte dans la liste.

  4. Sur la page Détails de la règle de cette contrainte, cliquez sur Gérer la règle.

  5. Sur la page Modifier la règle, sélectionnez Remplacer la règle parente.

  6. Cliquez sur Ajouter une règle.

  7. Dans Application, sélectionnez Activé.

  8. Facultatif : Cliquez sur Tester les modifications pour simuler l'effet de cette règle d'administration. Pour en savoir plus, consultez la section Tester les modifications apportées aux règles d'administration à l'aide de Policy Simulator.

  9. Pour finaliser et appliquer la règle d'administration, cliquez sur Définir la règle.

gcloud

  1. Créez un fichier de définition de règle YAML :

    name: organizations/ORGANIZATION_ID/policies/custom.CONSTRAINT_ID
    spec:
      rules:
      - enforce: true
    

    Remplacez les éléments suivants :

    • ORGANIZATION_ID : ID de l'organisation
    • CONSTRAINT_ID : ID de la contrainte
  2. Appliquez la règle :

    gcloud org-policies set-policy ORG_POLICY_PATH
    

    Remplacez ORG_POLICY_PATH par le chemin d'accès à votre fichier de définition de règle.

  3. Vérifiez que la règle existe :

    gcloud org-policies list \
        --organization=ORGANIZATION_ID
    

    Remplacez ORGANIZATION_ID par l'ID de l'organisation.

    Pour obtenir la liste des arguments, consultez la page gcloud org-policies list.

    Le résultat ressemble à ce qui suit :

    CONSTRAINT: custom.RequireBinAuthzCVPolicy
    LIST_POLICY: -
    BOOLEAN_POLICY: SET
    ETAG: CN622LIGEIDXnpMB-
    

La prise en compte de la règle peut prendre jusqu'à 15 minutes.

Pour appliquer plusieurs contraintes aux règles de plate-forme basées sur les vérifications de la CV, procédez comme suit :

  • Créez une contrainte personnalisée pour chaque règle basée sur les vérifications de la CV.
  • Mettez à jour la règle d'organisation avec chaque contrainte personnalisée, comme décrit dans cette section.

Supprimer la contrainte personnalisée

Vous pouvez supprimer une contrainte personnalisée à l'aide de la console Google Cloud ou de Google Cloud CLI.

Console

  1. Dans la console Google Cloud, accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  2. Cliquez sur le sélecteur de projets en haut de la page.

  3. Dans l'outil de sélection de projets, sélectionnez votre organisation.

  4. Recherchez et sélectionnez votre contrainte dans la liste.

  5. Dans Détails de la contrainte, cliquez sur Supprimer.

  6. Pour confirmer que vous souhaitez supprimer la contrainte, cliquez sur Supprimer.

gcloud

Pour supprimer une contrainte personnalisée, utilisez la commande gcloud CLI org-policies delete-custom-constraint :

gcloud org-policies delete-custom-constraint custom.CONSTRAINT_ID \
  --organization=ORGANIZATION_ID

Remplacez les éléments suivants :

  • ORGANIZATION_ID : ID de votre organisation (par exemple, 123456789).

  • CONSTRAINT_NAME : nom de votre contrainte personnalisée.

Le résultat ressemble à ce qui suit :

Deleted custom constraint [organizations/123456789/customConstraints/CONSTRAINT_NAME]

Si vous supprimez une contrainte personnalisée, toutes les règles créées à l'aide de cette contrainte continuent d'exister, mais sont ignorées. Vous ne pouvez pas créer une autre contrainte personnalisée portant le même nom qu'une contrainte personnalisée supprimée.

Étape suivante