Configurer des règles d'administration

Les règles d'administration 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 configurer des règles pour l'ensemble de votre organisation.

Dans cette version de Google Distributed Cloud (GDC) air-gapped, il n'existe pas d'UI ni de CLI pour les règles d'administration. Vous devez utiliser l'API ou la CLI kubectl pour les gérer.

Avantages

La configuration des règles d'administration présente plusieurs avantages :

• Centralisez le contrôle pour configurer des restrictions sur l'utilisation des ressources de votre organisation.
• Définissez et établissez des garde-fous pour que vos équipes de développement puissent respecter les limites de conformité.
• Aidez les propriétaires de projet et leurs équipes à agir rapidement sans enfreindre la conformité.

Différences avec Identity and Access Management

Identity and Access Management se concentre sur la réponse à la question qui, et permet à l'administrateur de déterminer qui peut effectuer des actions sur des ressources spécifiques en fonction des autorisations accordées.

Les règles d'administration se concentrent sur la réponse à la question quoi et permettent à l'administrateur de définir des restrictions sur des ressources spécifiques afin de déterminer comment les configurer.

Liste des types de règles d'administration disponibles

Dans cette version de GDC, vous pouvez utiliser le type de règle suivant.

GDCHRestrictedService

Le type de règle GDCHRestrictedService vous permet de limiter les services que vous pouvez utiliser sur GDC. Lorsqu'elle est appliquée, la règle empêche l'utilisation des API auxquelles elle fait référence. Par exemple, vous pouvez utiliser ce type de règle pour limiter l'utilisation d'un service donné à certains projets. Vous pouvez également utiliser la règle pour restreindre complètement l'accès à un nouveau service GDC sur lequel vous souhaitez effectuer des tests avant d'autoriser vos équipes à l'utiliser.

Créez cette règle dans le même cluster que les ressources de service. Vous pouvez créer plusieurs instances de cette règle pour différents services ou projets.

Voici un modèle pour cette règle :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: POLICY_NAME
spec:
  match:
    MATCH_SCHEMA
  parameters:
    disabledOperations:
      - DISABLED_OPERATION

Remplacez les éléments suivants :

• POLICY_NAME : nom de la règle d'organisation.

• MATCH_SCHEMA : ressources à mettre en correspondance pour cette contrainte. Pour en savoir plus, consultez la section Définir le champ d'application d'une règle d'administration dans un cluster.

• DISABLED_OPERATION : groupes d'opérations bloqués par cette règle. Les valeurs autorisées sont CREATE et UPDATE. La valeur par défaut du champ disabledOperations est *.

La règle GDCHRestrictedService n'est compatible qu'avec les opérations UPDATE et CREATE. Pour restreindre les opérations GET, LIST et DELETE, nous vous recommandons d'utiliser IAM pour attribuer des rôles.

La règle GDCHRestrictedService n'est compatible qu'avec le sous-ensemble suivant de services disponibles sur GDC.

Vous n'avez pas besoin de spécifier tous les types pour un service donné. Vous pouvez restreindre l'utilisation d'un sous-ensemble de fonctionnalités d'un service en spécifiant uniquement les types correspondants.

Par exemple, pour limiter les mises à jour des services Marketplace, créez la règle suivante :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: no-update-to-marketplace-service
spec:
  match:
    kinds:
    - apiGroups:
      - "marketplace.gdc.goog"
      kinds:
      - MarketplaceService
  parameters:
    disabledOperations:
      - "UPDATE"

Cette règle empêche toute opération UPDATE sur n'importe quel groupe d'API marketplace.gdc.goog avec la valeur MarketplaceService pour son type. En effet, cette règle empêche quiconque de modifier un service Marketplace.

Pour désactiver complètement un service, listez CREATE et UPDATE dans le paramètre disabledOperations, et listez tous les types documentés ici.

Attribuer des rôles IAM pour gérer les règles d'administration

Chaque règle d'organisation est associée à un rôle IAM. Accordez le rôle IAM aux utilisateurs et aux groupes que vous souhaitez autoriser à gérer cette règle d'administration spécifique. Pour permettre à un utilisateur ou à un groupe de créer, de modifier ou de supprimer des règles de type GDCHRestrictedService, attribuez-lui le rôle IAM gdchrestrictedservice-policy-manager.

Définir le champ d'application d'une règle d'administration dans un cluster

Lorsque vous définissez une règle d'administration, déterminez si elle doit s'appliquer à tous les espaces de noms, à certains espaces de noms uniquement ou à tous les espaces de noms, à l'exception d'une liste donnée. Pour ce faire, utilisez une combinaison des paramètres .spec.match.excludedNamespaces, .spec.match.namespaceSelector, .spec.match.namespaces et .spec.match.scope de la définition de règle.

Consultez la section Correspondance des règles d'administration pour en savoir plus sur ces paramètres. Par exemple, pour autoriser la création de bases de données uniquement dans les espaces de noms portant le libellé owner: dba-team, créez la règle suivante :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: db-restricted-to-dbas
spec:
  match:
    scope: Namespaced
    namespaceSelector:
      matchExpressions:
      # We are restricting the use of the service in namespaces that
      # don't have the owner: dba-team label
      - key: owner
        operator: NotIn
        values:
        - dba-team
    kinds:
    - apiGroups:
      - "postgresql.dbadmin.gdc.goog"
      kinds:
      - DBCluster
      - BackupPlan
      - Import
      - Restore
    - apiGroups:
      - "oracle.dbadmin.gdc.goog"
      kinds:
      - DBCluster
      - BackupPlan
      - Import
  parameters:
    disabledOperations:
      - "UPDATE"
      - "CREATE"

Restaurer une stratégie existante

Pour arrêter d'appliquer une règle existante, supprimez-la à l'aide de la CLI kubectl. Utilisez un fichier kubeconfig qui vous donne accès au cluster dans lequel la règle est définie et au rôle IAM gdchrestrictedservice-policy-manager.

Pour supprimer une règle d'administration, exécutez la commande suivante :

kubectl --kubeconfig CLUSTER_KUBECONFIG delete \
    GDCHRestrictedService/POLICY_NAME

Remplacez les éléments suivants :

• CLUSTER_KUBECONFIG : fichier kubeconfig du cluster dans lequel réside la règle d'administration.

• POLICY_NAME : nom de la règle d'administration à supprimer.

Tester une règle en mode audit

Vous pouvez tester une règle sans l'appliquer. Testez une règle pour vous assurer qu'elle ne perturbe pas les systèmes existants avant de la déployer ou pour obtenir une estimation de la fréquence d'un comportement. Pour ajouter un test, ajoutez un enforcementAction à la définition de votre règle. Ce paramètre peut prendre trois valeurs :

• deny : la règle est appliquée. Il s'agit du paramètre par défaut.
• dryrun : l'action est autorisée, mais vous pouvez constater qu'il existe un non-respect des règles dans les journaux d'audit et dans l'état des règles. Examinez le non-respect avec kubectl --kubeconfig CLUSTER_KUBECONFIG get POLICY_TYPE/POLICY_NAME.
• warn : équivalent à dryrun, sauf que le test affiche également un avertissement en réponse à la demande qui a déclenché un non-respect des règles.

Par exemple, pour tester une règle qui désactive le Marketplace, créez la règle suivante :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: disable-marketplace-service-project-alice
Spec:
  enforcementAction: warn
  match:
    kinds:
      - apiGroups: ["marketplace.gdc.goog"]
        kinds: ["MarketplaceService"]