Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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 afin de bénéficier des avantages suivants :

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 les règles de conformité.

Google Distributed Cloud (GDC) air-gapped ne fournit pas d'interface utilisateur de console ni de CLI dédiée pour créer et gérer des règles d'administration. Vous devez utiliser l'API Kubernetes ou la CLI kubectl.

Différences avec Identity and Access Management

La gestion de l'authentification et des accès (IAM) et les règles d'administration remplissent des fonctions d'accès et de gouvernance complémentaires :

IAM se concentre sur l'attribution d'autorisations. Il définit qui (membres tels que des utilisateurs, des groupes ou des comptes de service) peut effectuer quelles actions (rôles) sur quelles ressources (champ d'application des ressources). Les autorisations accordées par le biais des rôles IAM sont cumulatives et ne comportent pas de règles de refus.
Les règles d'administration visent à établir des garde-fous. Elles permettent aux administrateurs de configurer des restrictions programmatiques sur les ressources de l'ensemble de l'organisation, par exemple en désactivant des services spécifiques ou en limitant les modifications de ressources en fonction des attributs du sujet à l'aide du contrôle des accès basé sur les attributs (ABAC). Les règles d'administration prévalent pour bloquer les opérations, même si un membre détient un rôle IAM.

Avant de commencer

Avant de configurer des règles d'administration, vous devez demander les autorisations nécessaires et préparer votre environnement.

Demander des rôles IAM

Contactez l'administrateur IAM de votre organisation pour demander les rôles IAM suivants en fonction des tâches que vous devez effectuer :

Administrateur des règles de service restreint (gdchrestrictedservice-policy-admin) : créez, modifiez et supprimez des règles de service restreint.
Administrateur des règles "Restreindre par attributs" (gdchrestrictbyattributes-policy-admin) : permet de créer, de modifier et de supprimer des règles de contrôle des accès basées sur les attributs.

Préparer votre environnement

Téléchargez et installez la CLI gdcloud, si ce n'est pas déjà fait.
Installez la kubectl CLI.
Générez un fichier kubeconfig pour configurer l'accès à CLI kubectl.

Configurer une règle

Vous pouvez configurer deux types de règles d'administration dans GDC :

Règles relatives aux services restreints (GDCHRestrictedService) : limitent les services que vous pouvez utiliser ou modifier dans un cluster.
Règle de contrôle des accès basé sur les attributs (GDCHRestrictByAttributes) : limite l'accès aux ressources d'un cluster en fonction des attributs du sujet mappés à partir de votre fournisseur d'identité.

Configurer une règle de service restreint

Le type de règle GDCHRestrictedService vous permet de limiter les services que vous pouvez utiliser ou modifier dans un cluster en bloquant des API spécifiques. Par exemple, vous pouvez limiter un service à certains projets ou bloquer l'accès à un nouveau service pendant que vous le testez. Créez cette règle dans le même cluster que les ressources de service. Vous pouvez créer plusieurs instances de règles dans un cluster pour différents services ou projets.

GDCHRestrictedService accepte les opérations CREATE, UPDATE et DELETE. Pour restreindre les opérations de lecture GET et LIST, utilisez des liaisons de rôle IAM pour accorder et révoquer l'accès.

Configurer une règle de service restreint :

Définissez le fichier manifeste de la règle :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: POLICY_NAME
spec:
  match:
    kinds:
      - apiGroups:
          - "API_GROUP"
        kinds:
          - "KIND"
  parameters:
    disabledOperations:
      - DISABLED_OPERATION

Remplacez les éléments suivants :

POLICY_NAME : nom de la règle d'organisation.
API_GROUP : groupe d'API du service à limiter, tel qu'indiqué dans le tableau des services compatibles ci-dessous.
KIND : type de ressource à restreindre, tel qu'indiqué dans le tableau des services compatibles ci-dessous.
DISABLED_OPERATION : groupes d'opérations bloqués par cette règle. Les valeurs autorisées sont CREATE, UPDATE et DELETE. La valeur par défaut du champ disabledOperations est *. Pour désactiver complètement un service, listez CREATE, UPDATE et DELETE (et spécifiez tous ses types).

Par défaut, la règle s'applique à tous les espaces de noms du cluster. Pour définir le champ d'application de la règle sur des espaces de noms ou des projets spécifiques, consultez Définir le champ d'application d'une règle d'organisation dans un cluster.

La règle GDCHRestrictedService est compatible avec le sous-ensemble de services suivant sur GDC :

Service	Groupe d'API	kinds
Marketplace	`marketplace.gdc.goog`	`MarketplaceService`
Vertex AI Workbench	`aiplatform.gdc.goog`	`Notebook`
Service de base de données : Postgres	`postgresql.dbadmin.gdc.goog`	`DBCluster` `BackupPlan` `Import` `Restore`
Transfer Appliance	`system.gpc.gke.io`	`TransferApplianceRequest`
Sauvegarde	`backup.gdc.goog`	`BackupRepositoryManager`
Conteneur Dataproc pour Spark (service Marketplace)	`sparkoperator.k8s.io`	`SparkApplication`

Si un service répertorie plusieurs types dans le tableau (comme "Service de base de données"), vous ne pouvez spécifier que les types individuels que vous souhaitez limiter. Par exemple, vous pouvez bloquer les opérations Restore tout en continuant à autoriser les opérations DBCluster.

L'exemple suivant limite les mises à jour aux services Marketplace :

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"

Appliquez la règle à l'aide de la CLI kubectl :
```
kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f POLICY_NAME.yaml
```
Remplacez les éléments suivants :
- CLUSTER_KUBECONFIG : fichier kubeconfig du cluster auquel vous souhaitez appliquer la règle
- POLICY_NAME : nom du fichier de règles de l'organisation

Configurer une stratégie de contrôle des accès basée sur les attributs

Le type de règle GDCHRestrictByAttributes vous permet de créer des règles ABAC pour restreindre l'accès aux ressources de manière conditionnelle en fonction des attributs du sujet. Par exemple, vous pouvez utiliser ce type de stratégie pour limiter les opérations d'écriture ou de modification sur les buckets de stockage afin que seuls les utilisateurs ou les comptes de service disposant d'attributs d'identité spécifiques (tels que citizenship=USA ou citizenship=UK) puissent les effectuer.

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

Configurer une règle de contrôle des accès basée sur les attributs :

Créez un fichier JSON de correctif pour mapper les attributs d'identité personnalisés pour votre ressource IdentityProviderConfig :
```
cat <<EOF > attributeMapping-patch.json
{
  "CUSTOM_ATTRIBUTE": "assertion[\"CUSTOM_ATTRIBUTE\"]"
}
EOF
```
Remplacez CUSTOM_ATTRIBUTE par le nom de l'attribut d'identité à mapper, tel que citizenship.
Appliquez le correctif à la ressource IdentityProviderConfig dans l'espace de noms platform :
```
kubectl --kubeconfig CLUSTER_KUBECONFIG patch \
    IdentityProviderConfig IDENTITY_PROVIDER_CONFIG_NAME \
    -n platform --type=json \
    -p '[{"op":"add","path":"/spec/oidc/attributeMapping", "value": '"$(cat attributeMapping-patch.json)"'}]'
```
Remplacez les éléments suivants :
- CLUSTER_KUBECONFIG : fichier kubeconfig du cluster dans lequel réside le fournisseur d'identité
- IDENTITY_PROVIDER_CONFIG_NAME : nom de la ressource IdentityProviderConfig
Définissez le fichier manifeste de la règle :
```
apiVersion: constraints.global.gatekeeper.sh/v1beta1
kind: GDCHRestrictByAttributes
metadata:
  name: POLICY_NAME
spec:
  match:
    kinds:
      - apiGroups:
          - "API_GROUP"
        kinds:
          - "KIND"
  parameters:
    attributes:
      - CUSTOM_ATTRIBUTE
    attributeValues:
      - ALLOWED_ATTRIBUTE_VALUE
```
Remplacez les éléments suivants :
- POLICY_NAME : nom de la règle d'organisation.
- API_GROUP : groupe d'API des ressources à restreindre, par exemple object.gdc.goog.
- KIND : type de ressource à limiter, par exemple Bucket.
- CUSTOM_ATTRIBUTE : attribut de sujet personnalisé mappé à partir du fournisseur d'identité, tel que citizenship.
- ALLOWED_ATTRIBUTE_VALUE : valeur autorisée pour l'attribut personnalisé, par exemple USA. Les demandes provenant de sujets dont l'attribut ne correspond pas à l'une des valeurs autorisées sont refusées.
Par défaut, la règle s'applique à tous les espaces de noms du cluster. Pour définir le champ d'application de la règle sur des espaces de noms ou des projets spécifiques, consultez Définir le champ d'application d'une règle d'organisation dans un cluster.

L'exemple suivant limite la modification des ressources Bucket dans l'espace de noms project-foo aux sujets disposant de l'attribut citizenship=USA ou citizenship=UK :
```
apiVersion: constraints.global.gatekeeper.sh/v1beta1
kind: GDCHRestrictByAttributes
metadata:
  name: restrict-by-citizenship
spec:
  match:
    scope: Namespaced
    kinds:
      - apiGroups:
          - "object.gdc.goog"
        kinds:
          - Bucket
    namespaces:
      - project-foo
  parameters:
    attributes:
      - "citizenship"
    attributeValues:
      - "USA"
      - "UK"
```
Appliquez la règle à l'aide de la CLI kubectl :
```
kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f POLICY_NAME.yaml
```
Remplacez les éléments suivants :
- CLUSTER_KUBECONFIG : fichier kubeconfig du cluster auquel vous souhaitez appliquer la règle
- POLICY_NAME : nom du fichier de règles de l'organisation

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
  parameters:
    disabledOperations:
      - "UPDATE"
      - "CREATE"
      - "DELETE"

Restaurer une stratégie existante

Pour arrêter d'appliquer une règle existante, supprimez-la à l'aide de CLI kubectl. Utilisez un fichier kubeconfig qui vous donne accès au cluster où la règle est définie et au rôle IAM correspondant au type de règle (par exemple, gdchrestrictedservice-policy-admin ou gdchrestrictbyattributes-policy-admin).

Supprimer une règle d'administration :

kubectl --kubeconfig CLUSTER_KUBECONFIG delete \
    POLICY_TYPE/POLICY_NAME