Objectifs

• Comprendre les avantages du partage des ressources entre les comptes
• Découvrez les différentes techniques de partage des ressources entre les comptes

Présentation du partage des ressources

Il n'est pas rare de trouver plusieurs accès aux applications et d'utiliser la même ressource ou des parties de celle-ci. Par exemple, lorsque des applications et des environnements de calcul doivent vivre sur le même réseau d'entreprise. Un autre scénario est que les journaux de sécurité sont collectés dans la mémoire centrale. Dans une architecture de microservice, nous devons configurer des services pour accéder à des ressources externes et les utiliser. À leur tour, les ressources partagées doivent autoriser l'accès, et le réseau entre elles est configuré pour prendre en charge une telle collaboration, mais pas plus.

Voici quelques cas d'utilisation typiques du partage de ressources:

• Gestion centralisée de l'infrastructure liée à la sécurité. Surveillez la sécurité à partir d'un compte dédié et regroupez les journaux de sécurité en un seul endroit. Gérez toutes les clés de chiffrement dans les systèmes de gestion de clés centraux (KMS).
• Coordination des adresses réseau et des sous-réseaux. Les applications et les environnements de calcul doivent s'intégrer dans le même réseau et nécessiter le partage de plages d'adresses et de noms de domaine.
• Gestion centralisée des ressources pour la reprise après incident, y compris les services de sauvegarde tels que IBM Cloud Backup for Classic. Les applications et leurs services peuvent être conçus pour la haute disponibilité, mais des ressources centralisées supplémentaires peuvent être disponibles pour être réutilisées dans le pire des cas. Cela inclut la conservation de plusieurs copies de ressources disponibles dans le monde entier, par exemple stockées dans des compartiments Object Storage répliqués.
• Contrôlez les coûts en partageant des services plus coûteux dans la mesure du possible. Tous les projets de développement n'ont pas besoin que tous les services soient déployés en tant qu'instances dédiées. Souvent, il suffit de partager des instances de service au sein de comptes ou entre différents comptes. Même pour les environnements de production, les instances de service peuvent être partagées en fonction de leur facteur coût / valeur et de leur faisabilité technique. Cela peut être organisé en limitant les services disponibles dans un compte en utilisant des catalogues privés et en limitant le catalogue public, puis en fournissant de manière centralisée des instances de services restreints.
• Gestion centralisée des ressources au niveau de l'entreprise ou pour une unité commerciale. Il peut s'agir d'actifs nécessaires à l'image de marque ou à la gestion centralisée de modèles, d'images de base (machines virtuelles, conteneurs), etc. A nouveau, les catalogues privés et les Container Registry sont des services standard.
• Mettez des ressources rares à la disposition d'un plus grand nombre d'utilisateurs. Parfois, un type de ressource n'est disponible qu'en quantité limitée. En partageant, d'autres applications peuvent en bénéficier. Cela peut nécessiter une limitation de débit.

Partage des ressources de sécurité

Souvent, la sécurité est gérée au niveau de l'entreprise avec des règles applicables à l'ensemble de l'entreprise. Par conséquent, l'application est également gérée de manière centralisée. Cela reste vrai pour les charges de travail qui passent dans des environnements de cloud. Le partage des ressources est à la base de la gestion centralisée de la sécurité ainsi que de l'évaluation et de l'application de la conformité.

Le diagramme ci-dessus illustre les scénarios suivants:

1. Les instances de Object Storage et Databases for MongoDB dans Compte A et Compte B utilisent des clés de chiffrement gérées dans le compte principal de Key Protect.
2. Security and Compliance Center dans le compte principal régit les ressources dans les trois comptes (voir les lignes noires ci-dessus).
3. Les instances de IBM Cloud Activity Tracker Event Routing dans les comptes A et B dirigent les journaux d'audit vers IBM Cloud Logs dans le compte principal (voir les lignes bleues ci-dessus). Le IBM Cloud Logs est configuré pour conserver les journaux d'audit afin de répondre aux exigences de l'analyse et de l'entreprise.

Le partage peut se faire entre des comptes dans un environnement IBM Cloud Enterprise ou sans organisation d'entreprise formelle.

Partage des ressources réseau

La conception et le développement d'applications natives du cloud dans un contexte d'entreprise impliquent souvent la coordination des ressources réseau telles que les plages d'adresses et les sous-réseaux, les noms de domaine et le routage du trafic. Les différents comptes et leurs applications et environnements de calcul doivent s'adapter au réseau et à sa structure. Cela nécessite le partage des ressources réseau.

1. Le service Transit Gateway est utilisé pour interconnecter les environnements VPC et l'infrastructure classique sur les trois comptes.
2. Chaque compte possède une instance DNS Services pour gérer les noms de domaine privé. Les instances sont connectées pour partager des zones DNS.

Implémentation du partage de ressources

Comme indiqué dans l'introduction, il est courant d'accéder à des services en dehors du compte unique (cloud). Selon le niveau d'intégration, il existe différentes manières d'autoriser l'accès aux services et d'implémenter l'authentification. Les options disponibles sont présentées ci-dessous.

Autorisation de service à service

Une approche intégrée plus stricte pour un service accédant à un autre consiste à établir des autorisations de service à service(autorisations2s). Vous créez une règle IBM Cloud Identity and Access Management (IAM) qui autorise un service source à accéder à un service cible. Etant donné que l'authentification est effectuée en identifiant le service source demandant l'accès, aucune donnée d'identification sous forme de mots de passe ou de clés d'API n'est requise. L'authentification et l'autorisation sont gérées automatiquement en raison de la règle IAM créée.

Autorisations inter-comptes

IAM prend en charge l'établissement d'autorisations de service à service entre un service source dans un autre compte IBM Cloud et une cible dans le compte en cours. Par conséquent, il permet de partager des ressources entre des comptes en créant une règle d'autorisation IAM. Ces règles peuvent être créées de différentes manières, notamment dans la console du navigateur, comme illustré ci-dessous, à l'aide de l'interface de ligne de commande ou en exécutant le code Terraform.

Dans les exemples suivants, une instance Object Storage spécifique dans le compte source se voit attribuer le rôle Reader pour l'instance Key Protect identifiée dans le compte en cours.

L'exemple suivant illustre le code Terraform permettant de créer une ressource avec la même règle d'autorisation IAM:

resource "ibm_iam_authorization_policy" "cross_account_policy" {
  source_service_account      = data.ibm_iam_account_settings.account_a_settings.account_id
  source_service_name         = "cloud-object-storage"
  source_resource_instance_id = data.ibm_resource_instance.cos_resource_instance.guid

  target_service_name         = "kms"
  target_resource_instance_id = data.ibm_resource_instance.kms_resource_instance.guid

  roles                       = ["Reader"]
  description                 = "read access on Key Protect in Main Account for Account A"
}

La même règle d'autorisation peut être créée à l'aide de l'interface de ligne de commande IBM Cloud avec la commande iam service-policy-create:

ibmcloud iam authorization-policy-create cloud-object-storage kms Reader --source-service-account source_account_id --source-service-instance-id cos_instance_id --target-service-instance-id kms_instance_id

La console, le fournisseur Terraform et l'interface de ligne de commande utilisent tous l'API de gestion des règles IAM pour créer la règle.

A l'étape suivante, avec la règle d'autorisation en place, un compartiment de stockage chiffré à l'aide d'une clé racine Key Protect peut ensuite être créé. Voici le code Terraform utilisant la ressource ibm_cos_bucket. L'attribut key_protect contient le CRN de la clé racine.

resource "ibm_cos_bucket" "cos_bucket" {
  bucket_name          = "cos-bucket"
  resource_instance_id = data.ibm_resource_instance.cos_resource_instance.id
  region_location      = var.region
  key_protect          = data.ibm_kms_key.central_kms_root_key.id
  storage_class        = "smart"
}

Vous trouverez d'autres exemples dans le GitHub cross-account-resource-sharing.

Autorisations de service à service standard

Une dépendance à un service de gestion de clés (KMS) tel que Key Protect et Hyper Protect Crypto Services est typique pour les solutions basées sur le cloud. Une instance KMS contient les clés racine pour le chiffrement géré par le client. La plupart des services prennent en charge les clés de chiffrement contrôlées par le client. A la place de cloud-object-storage (Object Storage) dans l'exemple ci-dessus, de nombreux autres services peuvent utiliser une instance KMS partagée entre les comptes.

Les autres services (cibles) typiques pour l'autorisation de service à service et les candidats pour le partage de ressources sont les suivants:

• Object Storage: plusieurs services nécessitent ou peuvent stocker des données et des fichiers journaux dans un compartiment de stockage. Cela inclut l'archivage des journaux d'accès et des données de surveillance. D'autres services doivent accéder aux compartiments pour effectuer l'analyse des données. Et encore une autre catégorie de services a besoin d'un accès pour s'abonner aux notifications de changement afin de déclencher l'exécution d'actions.
• Event Notifications: pour envoyer des informations sur les événements aux abonnés, les instances de service doivent accéder à une instance Event Notifications.
• Secrets Manager: ce service stocke et fournit à d'autres services des clés d'API IAM, des certificats SSL/TLS et d'autres secrets. Par conséquent, les services dépendants (source) doivent accéder à Secrets Manager.
• Cloud Internet Services (CIS): gère les noms de domaine et d'autres données réseau et peut donc être utilisé pour, par exemple, la validation de certificat.
• IBM Cloud Logs Routing et IBM Cloud Activity Tracker Event Routing: nécessite un accès de service à des cibles comme IBM Cloud Logs.

Notez que la liste ci-dessus n'est pas complète.

Summary

L'accès à des ressources dans des comptes différents, même le partage de ressources est une pratique courante. Il existe plusieurs cas d'utilisation dans lesquels les utilisateurs bénéficient du partage des ressources. Ils ont été abordés dans la vue d'ensemble. Une combinaison d'identité utilisateur et de mot de passe ou une clé d'API permettant d'accéder à une ressource sert souvent d'authentification. L'accès peut être limité à un ensemble de privilèges, par exemple, autoriser uniquement l'accès en lecture ou d'autres actions restreintes. Parfois, ces types de données d'identification peuvent être créés et gérés par la ressource d'accès, comme une application ou un environnement de calcul ("liaison de service"). Une intégration encore plus étroite qui ne nécessite pas de données d'identification est le concept d'autorisation de service à service IBM Cloud. La ressource d'accès (source) et la ressource d'accès (cible) sont identifiées par leurs propriétés (authentification) et un rôle d'accès est affecté (autorisation). Une telle relation peut même être établie au-delà des frontières des comptes. Cela permet une configuration simple, mais néanmoins sécurisée, du partage des ressources entre comptes.

Vous trouverez des exemples de code expliquant comment configurer le partage de ressources pour certains de ces services dans le référentiel GitHub cross-account-resource-sharing.

Ressources connexes

Le document suivant fournit des détails sur certains scénarios inter-comptes:

• Les clés d'APIIBM Cloud d'un utilisateur peuvent avoir une portée sur plusieurs comptes

Articles de blogue relatifs au partage de ressources entre plusieurs comptes:

• Configuration multicompte Terraform pour IBM Cloud
• Tips and Tricks for Using IBM Cloud CLI: IBMCLOUD_HOME qui peut être utilisé pour utiliser plusieurs comptes à partir de l'interface de ligne de commande.