Configurer les autorisations de conception

Ce document décrit les bonnes pratiques à suivre pour concevoir 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 comme prescrit. Chaque univers GDC a 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.

Il est possible 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 d'auditer la combinaison de privilèges dont dispose un utilisateur dans les différentes organisations. Assurez-vous qu'un utilisateur disposant de privilèges dans plusieurs organisations ne viole pas les exigences de séparation des charges de travail dans des organisations distinctes.

Vous pouvez également avoir 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 convient 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 Marketplace

Vous pouvez choisir de bloquer certains projets à partir de certains services, afin de limiter la surface d'attaque potentielle dans un projet ou d'é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 n'importe quel projet. 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 à partir de projets, appliquez des contraintes Gatekeeper à la définition de ressource personnalisée d'un service et à une liste d'espaces de noms. L'approche visant à 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 effectuez des tâches telles que l'association d'un rôle IAM à un projet et le déploiement d'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 l'CLI de ligne de commande gdcloud ou kubectl, vous pouvez avoir plusieurs fichiers kubeconfig pour effectuer vos tâches. Assurez-vous que vous vous connectiez à l'aide des identifiants kubeconfig pour le cluster approprié à votre tâche.

Bonnes pratiques concernant 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 une utilisation en dehors de GDC.
  • Tenez compte des chemins d'escalade Kubernetes pour les utilisateurs ou les comptes de service qui ont la possibilité de créer et de 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.
  • Faites régulièrement pivoter les identifiants des comptes de service.

Envisager le principe du moindre privilège

Tenez compte du principe du moindre privilège (PoLP, Principle of Least Privilege) lorsque vous accordez des liaisons de rôle à des utilisateurs. Conformément au PoLP, envisagez d'attribuer uniquement les privilèges nécessaires pour effectuer une tâche.

Par exemple, vous accordez le rôle d'administrateur IAM de projet à un utilisateur dans un seul projet, afin qu'il délègue l'autorité d'accorder des rôles dans ce projet. Cet utilisateur accorde ensuite des rôles précis à d'autres développeurs du projet en fonction des services spécifiques qu'ils utilisent. Le rôle d'administrateur IAM de projet doit être limité à un responsable de confiance, car il peut être utilisé pour escalader les privilèges, en s'accordant à soi-même ou à d'autres personnes des rôles supplémentaires dans le projet.

Auditer régulièrement les privilèges excessifs

Veillez à examiner les rôles accordés au sein de votre organisation et à les auditer par rapport aux privilèges excessifs. Vous devez vous assurer que les rôles accordés sont nécessaires à un utilisateur individuel pour 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 à un utilisateur individuel des rôles très privilégiés dans plusieurs organisations, car cela pourrait enfreindre la raison pour laquelle les organisations sont séparées en premier lieu.