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 dans l'ensemble de votre organisation pour 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 qui obligent vos équipes de développement à respecter les limites de conformité.
Aidez les propriétaires de projet et leurs équipes à travailler rapidement sans enfreindre les règles de conformité.

Google Distributed Cloud (GDC) avec air gap 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 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'octroi d'autorisations. Elle définit qui (les membres tels que les utilisateurs, les groupes ou les comptes de service) peut effectuer quelles actions (les rôles) sur quelles ressources (le champ d'application des ressources). Les autorisations accordées via des rôles IAM sont cumulatives et ne comportent pas de règles de refus.
Les règles d'administration se concentrent sur l'établissement de 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 sont prioritaires 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 de règles de service restreint (gdchrestrictedservice-policy-admin) : crée, met à jour et supprime des règles de service restreint.
Administrateur de règles de restriction par attributs (gdchrestrictbyattributes-policy-admin) : crée, met à jour et supprime des règles de contrôle des accès basées sur des attributs.

Préparer votre environnement

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

Configurer une règle

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

Règle de service restreint (GDCHRestrictedService) : limite les services que vous pouvez utiliser ou modifier dans un cluster.
Stratégie de contrôle des accès basée sur les attributs (GDCHRestrictByAttributes) : limite l'accès aux ressources d'un cluster de manière conditionnelle en fonction des attributs de l'objet 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 en limitant un service à certains projets ou en bloquant 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ègle dans un cluster pour différents services ou projets.

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

Configurez 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'administration.
API_GROUP : groupe d'API du service à restreindre, tel qu'indiqué dans le tableau des services compatibles ci-dessous.
KIND : type de ressource à restreindre, comme indiqué dans le tableau des services compatibles suivant.
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 limiter le champ d'application de la règle à des espaces de noms ou des projets spécifiques, consultez Définir le champ d'application d'une règle d'administration 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 (par exemple, le service de base de données), vous ne pouvez spécifier que les types individuels que vous souhaitez restreindre. 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 de la place de marché :

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ègle d'administration

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

Le type de stratégie GDCHRestrictByAttributes vous permet de créer des stratégies 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ègle dans un cluster pour différentes ressources ou différents projets.

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

Créez un fichier JSON de correctif pour mapper les attributs d'identité personnalisés de 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, par exemple 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 où 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'administration.
- API_GROUP : groupe d'API des ressources à restreindre, par exemple object.gdc.goog.
- KIND : type de ressource à restreindre, 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 requêtes 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 limiter le champ d'application de la règle à des espaces de noms ou des projets spécifiques, consultez Définir le champ d'application d'une règle d'administration 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ègle d'administration

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 spécifiques 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 la règle.

Pour en savoir plus sur ces paramètres, consultez la section Correspondance des règles d'administration. Par exemple, pour n'autoriser la création de bases de données que dans les espaces de noms portant l'étiquette 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"

Effectuer un rollback d'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 où la stratégie est définie et au rôle IAM correspondant au type de stratégie (par exemple, gdchrestrictedservice-policy-admin ou gdchrestrictbyattributes-policy-admin).

Supprimez une règle d'administration :

kubectl --kubeconfig CLUSTER_KUBECONFIG delete \
    POLICY_TYPE/POLICY_NAME