Accès aux ressources liées au cluster dans des locations

Découvrez les stratégies IAM requises pour permettre à une location d'accéder aux ressources liées au cluster dans d'autres locations.

Lorsque vous voulez qu'une location accède aux ressources d'autres locations, vous devez créer des stratégies inter-locations.

Si vous ne connaissez pas encore les stratégies, reportez-vous à Gestion des domaines d'identité et reportez-vous aux sections suivantes :

Stratégies inter-locations

Votre organisation peut partager des ressources liées au cluster avec une autre organisation qui possède sa propre location. Il peut s'agir d'une autre unité opérationnelle de votre société, d'un client, d'une société qui fournit des services à la vôtre, etc. Vous avez alors besoin de stratégies colocatives en plus des stratégies utilisateur et de service requises décrites dans Configuration de stratégies pour la création et le déploiement de clusters.

Instructions Endorse, Admit et Define

Pour accéder aux ressources et les partager entre deux locations, les administrateurs des deux locations doivent créer des instructions de stratégie spéciales qui indiquent explicitement les ressources accessibles et pouvant être partagées. Ces instructions spéciales utilisent les mots Define, Endorse et Admit.

Voici un aperçu des verbes spéciaux utilisés dans les instructions inter-locations :

Endorse : présente l'ensemble général des actions qu'un groupe de votre location peut effectuer dans d'autres locations. L'instruction Endorse appartient toujours à la location du groupe d'utilisateurs qui accède à une autre location pour en utiliser les ressources. Dans les exemples, cette location est appelée la location source.
Admit : indique le type de capacité dans votre location que vous voulez accorder à un groupe d'une autre location. L'instruction Admit appartient à la location octroyant l'"admission". L'instruction Admit identifie le groupe d'utilisateurs nécessitant un accès aux ressources à partir de la location source, ce groupe étant identifié par une instruction Endorse correspondante. Dans les exemples, cette location est appelée la location de destination.
Define : affecte un alias à un OCID de location pour les instructions de stratégie Endorse et Admit. Une instruction Define est également requise dans la location de destination afin d'affecter un alias à l'OCID de groupe IAM source pour les instructions Admit.

Les instructions Define doivent être incluses dans la même entité de stratégie que l'instruction Endorse ou Admit.

Les instructions Endorse et Admit sont utilisées conjointement, mais résident dans des stratégies distinctes, une dans chaque location. Sans instruction correspondante définissant l'accès, une instruction Endorse ou Admit particulière n'accorde aucun accès. L'accord des deux locations est requis.

Stratégies source

L'administrateur source crée des instructions de stratégie qui approuvent un groupe IAM source pour gérer des ressources dans une location de destination.

Voici un exemple d'instruction de stratégie générale approuvant le groupe IAM OKE-Admins pour qu'il puisse faire n'importe quoi avec toutes les ressources liées au cluster dans n'importe quelle location :

Endorse group OKE-Admins to manage cluster-family in any-tenancy

Pour permettre au groupe IAM source de créer des clusters dans la location de destination, l'administrateur source doit également créer des instructions de stratégie afin d'approuver le groupe pour la gestion des réseaux virtuels et l'inspection des compartiments. Par exemple :

Endorse group OKE-Admins to manage virtual-network-family in any-tenancy
Endorse group OKE-Admins to inspect compartments in any-tenancy

Pour écrire une stratégie qui réduit la portée de l'accès à la location uniquement à la location de destination, l'administrateur source doit obtenir l'OCID de la location de destination auprès de l'administrateur de destination et inclure cet OCID dans une instruction de stratégie. Voici un exemple d'instructions de stratégie approuvant le groupe IAM OKE-Admins pour qu'il puisse gérer les ressources liées au cluster dans DestinationTenancy uniquement :

Define tenancy DestinationTenancy as ocid1.tenancy.oc1..<unique_ID>
Endorse group OKE-Admins to manage cluster-family in tenancy DestinationTenancy

Stratégies de destination

L'administrateur de destination crée des instructions de stratégie qui :

Définissez la location source et le groupe IAM autorisé à accéder aux ressources de la location de destination. L'administrateur source doit fournir les OCID de la location source et du groupe IAM source.
Admettez le groupe IAM source pour accéder aux ressources liées au cluster dans la location de destination.

Voici un exemple d'instructions de stratégie admettant le groupe IAM OKE-Admins de la location source pour qu'il puisse tout faire avec toutes les ressources liées au cluster de la location de destination :

Define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
Define group OKE-Admins as ocid1.group.oc1..<unique_ID>
Admit group OKE-Admins of tenancy SourceTenancy to manage cluster-family in tenancy

Pour permettre au groupe IAM source de créer des clusters dans la location de destination, l'administrateur de destination doit également créer des instructions de stratégie afin d'admettre le groupe pour gérer les réseaux virtuels et inspecter les compartiments dans la location de destination. Par exemple :

Admit group OKE-Admins of tenancy SourceTenancy to manage virtual-network-family in tenancy
Admit group OKE-Admins of tenancy SourceTenancy to inspect compartments in tenancy

Voici un exemple d'instructions de stratégie approuvant le groupe IAM OKE-Admins dans la location source pour qu'il puisse gérer les ressources liées au cluster uniquement dans le compartiment SharedOKEClusters :

Define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
Define group OKE-Admins as ocid1.group.oc1..<unique_ID>
Admit group OKE-Admins of tenancy SourceTenancy to manage cluster-family in compartment SharedOKEClusters

Accès aux images personnalisées dans d'autres locations lors de la création ou de la mise à jour de pools de noeuds gérés

Lorsque vous utilisez l'interface de ligne de commande ou l'API pour créer ou mettre à jour un pool de noeuds gérés, vous indiquez l'OCID de l'image utilisée par Kubernetes Engine pour provisionner les noeuds gérés dans le pool de noeuds. Si vous indiquez l'OCID d'une image personnalisée, celle-ci peut se trouver dans la même location que le cluster ou dans une autre location. Si l'image personnalisée se trouve dans une autre location, des stratégies doivent exister pour permettre à l'autre location d'accéder à la lecture de l'image.

Dans la location (location source) contenant le cluster avec le pool de noeuds gérés que le moteur Kubernetes doit provisionner à l'aide d'une image personnalisée, l'administrateur source doit créer des instructions de stratégie pour approuver l'accès à l'image personnalisée dans la location de destination. Par exemple :

Define tenancy image-tenancy as ocid1.tenancy.oc1...<unique_ID>
Endorse any-user to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} in tenancy image-tenancy where request.principal.type = 'nodepool'

Dans la location contenant l'image personnalisée (la location de destination), l'administrateur de destination doit créer des instructions de stratégie pour admettre l'accès de la location source à l'image personnalisée. Par exemple :

Define tenancy nodepool-tenancy as ocid1.tenancy.oc1...<unique_ID>
Admit any-user of tenancy nodepool-tenancy to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} where request.principal.type = 'nodepool'