Configurer les autorisations de conception

Ce document décrit les bonnes pratiques pour la conception des autorisations dans un univers Google Distributed Cloud (GDC) isolé. Voici les sujets abordés :

Bien que les conceptions suivantes soient recommandées, il n'est pas obligatoire de les suivre exactement. Chaque univers GDC présente des exigences et des considérations uniques qui doivent être satisfaites au cas par cas.

Configurer un fournisseur d'identité par organisation

Un opérateur doit configurer un ou plusieurs fournisseurs d'identité par organisation. Un administrateur se connecte ensuite à un fournisseur d'identité pour gérer les services d'authentification des applications dans l'univers GDC.

Imaginons que votre entreprise comporte plusieurs services avec des organisations distinctes, et que chaque organisation se connecte au même fournisseur d'identité pour l'authentification. Dans ce cas, il vous incombe de comprendre et de vérifier la combinaison de droits dont dispose un utilisateur dans les différentes organisations. Assurez-vous qu'un utilisateur disposant de droits d'accès dans plusieurs organisations ne viole pas les exigences concernant la séparation des charges de travail dans des organisations distinctes.

Vous pouvez également être confronté à un scénario dans lequel différents ensembles d'utilisateurs utilisent différents fournisseurs d'identité pour s'authentifier au sein d'une même organisation, par exemple lorsque plusieurs équipes de fournisseurs travaillent ensemble dans une même organisation. Déterminez si la consolidation des identités utilisateur dans un seul fournisseur d'identité ou le maintien de fournisseurs d'identité distincts correspond le mieux à l'approche de votre entreprise en matière de gestion des identités.

Configurer l'authentification multifacteur pour votre fournisseur d'identité

GDC s'appuie sur votre plate-forme IAM pour l'authentification, y compris les paramètres de sécurité supplémentaires tels que l'authentification multifacteur. Il est recommandé de configurer l'authentification multifacteur avec une clé physique pour tout utilisateur susceptible d'accéder à des ressources sensibles.

Restreindre les services gérés et les services Marketplace

Vous pouvez préférer bloquer certains projets à partir de certains services, soit pour limiter la surface d'attaque potentielle dans un projet, soit pour éviter l'utilisation de services non approuvés. Par défaut, les services gérés tels que l'intelligence artificielle et le machine learning sont disponibles dans tous les projets. Contrairement aux services gérés, les services Marketplace doivent d'abord être activés pour l'organisation.

Pour refuser l'accès aux services depuis des projets, appliquez des constraints Gatekeeper à la définition de ressource personnalisée d'un service et à une liste d'espaces de noms. L'approche pour refuser l'accès avec Gatekeeper s'applique aux services gérés et Marketplace.

Gérer les fichiers kubeconfig pour plusieurs clusters

Différentes tâches opérationnelles nécessitent une connexion à différents clusters. Par exemple, vous pouvez associer un rôle IAM à un projet ou déployer une ressource Pod Kubernetes sur un cluster Kubernetes.

Lorsque vous utilisez la console GDC, vous n'avez pas besoin de savoir quel cluster sous-jacent effectue une tâche, car la console GDC abstrait les opérations de bas niveau telles que la connexion à un cluster.

Toutefois, lorsque vous utilisez les CLI gdcloud ou kubectl, vous pouvez avoir plusieurs fichiers kubeconfig pour accomplir vos tâches. Assurez-vous de vous connecter à l'aide des identifiants kubeconfig pour le cluster approprié à votre tâche.

Bonnes pratiques pour les comptes de service Kubernetes

Pour les comptes de service Kubernetes, l'autorisation est basée sur un jeton secret. Pour réduire le risque lié aux jetons de compte de service, tenez compte des bonnes pratiques suivantes :

  • Évitez de télécharger des identifiants de compte de service persistants pour les utiliser en dehors de GDC.
  • Tenez compte des chemins d'escalade Kubernetes pour les utilisateurs ou les comptes de service qui peuvent créer et modifier des pods.
  • Définissez le champ expirationSeconds sur une courte période pour la projection du jeton de compte de service de vos charges de travail.
  • Alternez régulièrement les identifiants du compte de service.

Envisager le principe du moindre privilège

Tenez compte du principe du moindre privilège lorsque vous accordez des liaisons de rôle aux utilisateurs. Conformément au principe du moindre privilège, envisagez d'attribuer uniquement les droits nécessaires pour effectuer une tâche.

Par exemple, vous attribuez le rôle d'administrateur IAM d'un projet à un utilisateur afin qu'il puisse déléguer l'autorité d'attribution de rôles dans ce projet. Cet utilisateur attribue ensuite des rôles précis aux autres développeurs du projet en fonction des services spécifiques qu'ils utilisent. Le rôle d'administrateur IAM du projet doit être limité à un responsable de confiance, car il pourrait être utilisé pour escalader les privilèges, en s'accordant ou en accordant à d'autres personnes des rôles supplémentaires dans le projet.

Effectuez régulièrement des audits pour détecter les privilèges excessifs.

Assurez-vous d'examiner les rôles accordés au sein de votre organisation et de vérifier qu'ils ne sont pas excessifs. Vous devez vous assurer que les rôles accordés sont nécessaires pour qu'un utilisateur puisse effectuer son travail, et que les combinaisons de rôles dans les projets n'entraînent pas de risque d'escalade ou d'exfiltration.

Si votre entreprise utilise plusieurs organisations, nous vous déconseillons d'attribuer des rôles à privilèges élevés à un même utilisateur dans plusieurs organisations, car cela pourrait aller à l'encontre de la raison pour laquelle vous avez séparé les organisations en premier lieu.