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
.
-
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 section Gérer les accès.Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.
- Assurez-vous de connaître votre ID d'organisation.
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.
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 parcustom.
et ne peut inclure que des lettres majuscules, minuscules ou des chiffres, comme par exemplecustom.enableGkeAutopilot
. La longueur maximale de ce champ est de 70 caractères, sans compter le préfixe, comme par exempleorganizations/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
ouNodePool
.METHOD1,METHOD2,...
: liste des méthodes RESTful pour lesquelles la contrainte est appliquée. Il peut s'agir deCREATE
, ou deCREATE
et deUPDATE
.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, utiliseztrue
oufalse
. Pour les champs de type chaîne, utilisez"STRING"
.
ACTION
: action à effectuer si la valeur decondition
est définie. Peut être défini surALLOW
ouDENY
.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.
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.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.
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, utilisezprojects/PROJECT_ID
. Pour appliquer la règle dans une organisation spécifique, utilisezorganizations/ORGANIZATION_ID
.POLICY_NAME
: nom de la nouvelle stratégie.
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.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
oufolder
.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
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.
Appliquez la contrainte :
gcloud org-policies set-custom-constraint ~/constraint-enable-autopilot.yaml
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
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.Appliquez la règle :
gcloud org-policies set-policy ~/policy-enable-autopilot.yaml
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 |
---|---|
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 |
Étapes suivantes
- En savoir plus sur les contraintes.
- Découvrez les options supplémentaires que vous pouvez utiliser pour personnaliser vos règles.
- Découvrez comment définir des règles d'administration basées sur des tags.