Limiter les actions sur les ressources GKE à l'aide de règles d'administration personnalisées

Cette page explique comment restreindre des opérations spécifiques sur les ressources Google Kubernetes Engine (GKE) dans votre organisation à l'aide de contraintes personnalisées dans le service de règles d'administration Google Cloud. Pour en savoir plus sur les règles d'administration, consultez la section Règles d'administration personnalisées.

À propos des règles et des contraintes de l'organisation

Les règles d'administration Google Cloud vous offrent un contrôle centralisé et automatisé sur les ressources de votre organisation. En tant qu'administrateur des règles d'administration, vous pouvez définir une règle d'administration, c'est-à-dire un ensemble de restrictions appelées Contraintes qui s'appliquent aux ressources Google Cloud et aux descendants de ces ressources dans la Hiérarchie des ressources Google Cloud. Vous pouvez appliquer des règles d'administration au niveau d'une organisation, d'un dossier ou d'un projet.

Les règles d'administration fournissent des contraintes prédéfinies pour divers services Google Cloud. Toutefois, si vous souhaitez exercer un contrôle plus précis et personnalisable sur les champs spécifiques restreints dans vos règles d'administration, vous pouvez également créer des contraintes personnalisées et les utiliser dans une règle d'administration personnalisée.

Ressources compatibles avec GKE

Pour GKE, vous pouvez créer des contraintes personnalisées pour les méthodes CREATE ou UPDATE sur n'importe quel champ de la ressource Cluster ou NodePool de l'API Google Kubernetes Engine v1, sauf pour les champs exclusivement de sortie et pour les champs suivants :

  • projects.locations.clusters.masterAuth.clientKey
  • projects.locations.clusters.masterAuth.password

Héritage des règles

Par défaut, les stratégies sont héritées par les descendants des ressources sur lesquelles vous les appliquez. Par exemple, si vous appliquez une stratégie au niveau d'un dossier, Google Cloud l'applique à tous les projets du dossier. Pour mieux comprendre ce comportement et savoir comment le modifier, consultez la page Règles d'évaluation hiérarchique.

Tarifs

Les règles et les contraintes d'organisation sont offertes gratuitement.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Créer une contrainte personnalisée

Pour créer une contrainte personnalisée, vous la définissez dans un fichier YAML et vous l'appliquez dans votre organisation à l'aide de Google Cloud CLI.

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

    name: organizations/ORGANIZATION_ID/customConstraints/custom.CONSTRAINT_NAME
resourceTypes:
- container.googleapis.com/RESOURCE_NAME
methodTypes:
- METHOD1
- METHOD2
condition: "resource.OBJECT_NAME.FIELD_NAME == VALUE"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION

    Remplacez les éléments suivants :

    • ORGANIZATION_ID : ID de votre organisation (par exemple, 123456789).
    • CONSTRAINT_NAME : nom souhaité pour votre nouvelle contrainte personnalisée. Une contrainte personnalisée doit commencer par custom. et ne peut inclure que des lettres majuscules, minuscules ou des chiffres, comme par exemple custom.enableGkeAutopilot. La longueur maximale de ce champ est de 70 caractères, sans compter le préfixe, comme par exemple organizations/123456789/customConstraints/custom..
    • RESOURCE_NAME : nom (pas l'URI) de la ressource REST de l'API GKE contenant l'objet et le champ que vous souhaitez restreindre. Par exemple, Cluster ou NodePool.
    • METHOD1,METHOD2,... : liste des méthodes RESTful pour lesquelles la contrainte est appliquée. Il peut s'agir de CREATE, ou de CREATE et de UPDATE.

    • condition : condition pour la validation de la requête, écrite en CEL (Common Expression Language). Ce champ ne doit pas comporter plus de 1000 caractères. L'expression doit contenir les champs suivants et accepte les opérateurs logiques tels que && et || :

      • OBJECT_NAME : nom de l'objet d'API GKE que vous souhaitez restreindre, en format pascalCase. Par exemple, privateClusterConfig.
      • FIELD_NAME : nom du champ de l'API GKE que vous souhaitez restreindre, en format pascalCase. Par exemple, enablePrivateNodes.
      • VALUE : valeur du champ. Pour les champs booléens, utilisez true ou false. Pour les champs de type chaîne, utilisez "STRING".

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

    • DISPLAY_NAME : nom convivial de la contrainte. Ce champ ne doit pas comporter plus de 200 caractères.

    • DESCRIPTION : description conviviale de la contrainte à afficher sous forme de message d'erreur en cas de non-respect de la règle. Ce champ ne doit pas comporter plus de 2000 caractères.

  2. Appliquez la contrainte personnalisée :

    gcloud org-policies set-custom-constraint PATH_TO_FILE

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

  3. Vérifiez que la contrainte personnalisée existe :

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

    Le résultat ressemble à ce qui suit :

    CONSTRAINT                     LIST_POLICY    BOOLEAN_POLICY    ETAG
custom.enableGkeAutopilot      -              SET               COCsm5QGENiXi2E=
...

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.

  1. Créez un fichier YAML pour la règle d'administration :

    name: RESOURCE_HIERARCHY/policies/POLICY_NAME
spec:
  rules:
  - enforce: true

    Remplacez les éléments suivants :

    • RESOURCE_HIERARCHY : emplacement de la nouvelle règle (affecte le champ d'application). Utilisez la hiérarchie des ressources Google Cloud comme guide. Par exemple, si vous souhaitez appliquer la règle dans un projet spécifique, utilisez projects/PROJECT_ID. Pour appliquer la règle dans une organisation spécifique, utilisez organizations/ORGANIZATION_ID.
    • POLICY_NAME : nom de la nouvelle stratégie.

  2. Appliquez la règle :

    gcloud org-policies set-policy PATH_TO_POLICY

    Remplacez PATH_TO_POLICY 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 \
    --RESOURCE_FLAG=RESOURCE_ID

    Remplacez les éléments suivants :

    • RESOURCE_FLAG : ressource Google Cloud dans laquelle vous avez appliqué la stratégie. Par exemple, project ou folder.
    • RESOURCE_ID : ID de la ressource dans laquelle vous avez appliqué la stratégie. Par exemple, l'ID de votre dossier Google Cloud.

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

    Le résultat ressemble à ce qui suit :

    CONSTRAINT                                    LIST_POLICY    BOOLEAN_POLICY    ETAG
iam.disableWorkloadIdentityClusterCreation    -              SET               CO3UkJAGEOj1qsQB
custom.enableGkeAutopilot                     -              SET               COCsm5QGENiXi2E=
custom.enableBinAuth                          -              SET               CJfKiZUGEJju7LUD

Exemple : Créer une contrainte personnalisée et appliquer une règle

L'exemple suivant crée une contrainte et une règle personnalisées qui exigent que les nouveaux clusters d'un projet spécifique soient des clusters Autopilot.

Avant de commencer, vous devez connaître les éléments suivants :

  • ID de votre organisation
  • Un ID de projet.

Créer la contrainte

  1. Enregistrez le fichier suivant sous le nom constraint-enable-autopilot.yaml :

    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableGkeAutopilot
resourceTypes:
- container.googleapis.com/Cluster
methodTypes:
- CREATE
condition: "resource.autopilot.enabled == false"
actionType: DENY
displayName: Enable GKE Autopilot
description: All new clusters must be Autopilot clusters.

    Cela définit une contrainte qui refuse les opérations de création de cluster si le mode de cluster n'est pas Autopilot.

  2. Appliquez la contrainte :

    gcloud org-policies set-custom-constraint ~/constraint-enable-autopilot.yaml

  3. Vérifiez que la contrainte existe :

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

    Le résultat ressemble à ce qui suit :

    CUSTOM_CONSTRAINT                       ACTION_TYPE  METHOD_TYPES   RESOURCE_TYPES                     DISPLAY_NAME
custom.enableGkeAutopilot               DENY         CREATE         container.googleapis.com/Cluster   Enable GKE Autopilot
...

Créer la règle

  1. Enregistrez le fichier suivant sous le nom policy-enable-autopilot.yaml :

    name: projects/PROJECT_ID/policies/custom.enableGkeAutopilot
spec:
  rules:
  - enforce: true

    Remplacez PROJECT_ID par l'ID de votre projet.

  2. Appliquez la règle :

    gcloud org-policies set-policy ~/policy-enable-autopilot.yaml

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

    gcloud org-policies list --project=PROJECT_ID

    Le résultat ressemble à ce qui suit :

    CONSTRAINT                  LIST_POLICY    BOOLEAN_POLICY    ETAG
custom.enableGkeAutopilot   -              SET               COCsm5QGENiXi2E=

Une fois la règle appliquée, attendez environ deux minutes que Google Cloud commence à l'appliquer.

Tester la stratégie

Essayez de créer un cluster GKE standard dans le projet :

gcloud container clusters create org-policy-test \
    --project=PROJECT_ID \
    --zone=COMPUTE_ZONE \
    --num-nodes=1

Le résultat est le suivant :

Operation denied by custom org policies: ["customConstraints/custom.enableGkeAutopilot": "All new clusters must be Autopilot clusters."]

Exemples de contraintes personnalisées pour des cas d'utilisation courants

Les sections suivantes fournissent la syntaxe de certaines contraintes personnalisées qui pourraient vous être utiles :

Description Syntaxe de la contrainte
Autoriser la création de clusters uniquement lorsque l'autorisation binaire est activée 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeBinaryAuthorization
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    condition: "condition:resource.binaryAuthorization.enabled == true || resource.binaryAuthorization.evaluationMode=='PROJECT_SINGLETON_POLICY_ENFORCE'"
    action: ALLOW
    displayName: Enable GKE Binary Authorization
    description: All new clusters must enable Binary Authorization.
Ne pas désactiver la mise à niveau automatique des nœuds pour les nouveaux pools de nœuds 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableAutoUpgrade
    resourceTypes:
    - container.googleapis.com/NodePool
    methodTypes:
    - CREATE
    condition: "resource.management.autoUpgrade == true"
    actionType: ALLOW
    displayName: Enable node auto-upgrade
    description: All node pools must have node auto-upgrade enabled.
Activer la fédération d'identité de charge de travail pour GKE pour les nouveaux clusters 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableWorkloadIdentity
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    condition: "has(resource.workloadIdentityConfig.workloadPool) || resource.workloadIdentityConfig.workloadPool.size() > 0"
    actionType: ALLOW
    displayName: Enable Workload Identity on new clusters
    description: All new clusters must use Workload Identity.
Ne pas désactiver Cloud Logging sur les clusters existants 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableLogging
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - UPDATE
    condition: "resource.loggingService == 'none'"
    actionType: DENY
    displayName: Do not disable Cloud Logging
    description: You cannot disable Cloud Logging on existing GKE cluster.
Autoriser la création ou la mise à jour du pool de nœuds standard uniquement lorsque les anciens points de terminaison de métadonnées sont désactivés 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.nodeConfigMetadata
    resourceTypes:
    - container.googleapis.com/NodePool
    methodTypes:
    - CREATE
    - UPDATE
    condition: "'disable-legacy-endpoints' in resource.config.metadata && resource.config.metadata['disable-legacy-endpoints'] == 'true'"
    actionType: ALLOW
    displayName: Disable legacy metadata endpoints
    description: You can only create or update node pools if you disable legacy
    metadata endpoints.

Cet exemple de contrainte vous montre comment définir une contrainte personnalisée sur une valeur de carte. Le champ condition utilise l'opérateur d'index sur la clé de carte disable-legacy-endpoints. Si vous utilisez la syntaxe de sélection de champ standard, comme dans les exemples précédents, une erreur INVALID_CUSTOM_CONSTRAINT_CONDITION s'affiche.

Étapes suivantes