Documentação do Oracle Cloud Infrastructure

Acessando Recursos Relacionados ao Cluster entre Tenancies

Saiba mais sobre as políticas do serviço IAM necessárias para permitir que uma tenancy acesse recursos relacionados ao cluster em outras tenancies.

Quando você quiser que uma tenancy acesse recursos em outras tenancies, crie políticas entre tenancies.

Se você não conhece as políticas, consulte Conceitos Básicos de Políticas e consulte:

Políticas entre Tenancies

Sua organização talvez queira compartilhar recursos relacionados ao cluster com outra organização que tenha sua própria tenancy. Pode ser outra unidade de negócios da sua empresa, um cliente da sua empresa, uma empresa que fornece serviços para sua empresa e assim por diante. Em casos como esses, você precisa de políticas entre tenancies, além das políticas necessárias de usuário e serviço descritas em Configuração de Política para Criação e Implantação de Cluster.

Endossar, Admitir e Definir instruções

Para acessar e compartilhar recursos entre duas locações, os administradores de ambas as locações precisam criar instruções de política especiais que declarem explicitamente os recursos que podem ser acessados e compartilhados. Essas instruções especiais usam as palavras Define, Endorse e Admit.

Veja aqui uma visão geral dos verbos especiais usados em instruções intertenancy:

  • Endorse: Informa o conjunto geral de habilidades que um grupo em sua própria tenancy pode executar em outras tenancies. A instrução Endorse sempre pertence à tenancy com o grupo de usuários que cruzam os limites em outra tenancy para trabalhar com os recursos dessa tenancy. Nos exemplos, essa tenancy é chamada de tenancy de origem.
  • Admit: Indica o tipo de capacidade em sua própria tenancy que você deseja conceder a um grupo de outra tenancy. A instrução Admit pertence à tenancy que está concedendo "admissão" à tenancy. A instrução Admit identifica o grupo de usuários que requer acesso a recursos da tenancy de origem e identificado com uma instrução Endorse correspondente. Nos exemplos, essa tenancy é chamada de tenancy de destino.

  • Define: Designa um alias a um OCID da tenancy para instruções de política Endorse e Admit. Uma instrução Define também é necessária na tenancy de destino para designar um alias ao OCID do grupo do serviço IAM de origem para instruções Admit.

    As instruções Define devem ser incluídas na mesma entidade de política que a instrução Endorse ou Admit.

As instruções Endorse e Admit funcionam juntas, mas residem em políticas separadas, uma em cada tenancy. Sem uma instrução correspondente que especifique o acesso, uma determinada instrução Endorse ou Admit não concede acesso. É necessário um acordo entre ambas as tenancies.

Políticas de origem

O administrador de origem cria instruções de política que endossam um grupo do serviço IAM de origem para gerenciar recursos em uma tenancy de destino.

Aqui está um exemplo de uma instrução de política ampla que endossa o grupo OKE-Admins do IAM para fazer qualquer coisa com todos os recursos relacionados ao cluster em qualquer tenancy:

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

Para permitir que o grupo do IAM de origem crie clusters na tenancy de destino, o administrador de origem também deve criar instruções de política para endossar o grupo para gerenciar redes virtuais e inspecionar compartimentos. Por exemplo:

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

Para gravar uma política que reduz o escopo do acesso da tenancy apenas à tenancy de destino, o administrador de origem deve obter o OCID da tenancy de destino do administrador de destino e incluir esse OCID em uma instrução de política. Veja um exemplo de instruções de política que endossa o grupo OKE-Admins do IAM para gerenciar recursos relacionados ao cluster somente em DestinationTenancy:

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

Políticas de destino

O administrador de destino cria instruções de política que:

  • Defina a tenancy de origem e o grupo do serviço IAM que tem permissão para acessar recursos na tenancy de destino. O administrador de origem deve fornecer os OCIDs da tenancy de origem e do grupo do serviço IAM de origem.
  • Admita o grupo do IAM de origem para acessar recursos relacionados ao cluster na tenancy de destino.

Veja aqui um exemplo de declarações de política que admitem que os OKE-Admins do grupo do IAM da tenancy de origem façam qualquer coisa com todos os recursos relacionados ao cluster na tenancy de destino:

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

Para permitir que o grupo do IAM de origem crie clusters na tenancy de destino, o administrador de destino também deve criar instruções de política para admitir que o grupo gerencie redes virtuais e inspecione compartimentos na tenancy de destino. Por exemplo:

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

Este é um exemplo de instruções de política que endossam o grupo OKE-Admins do serviço IAM na tenancy de origem para gerenciar recursos relacionados ao cluster apenas no compartimento 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

Acessando Imagens Personalizadas em outras Tenancies ao Criar ou Atualizar Pools de Nós Gerenciados

Ao usar a CLI ou a API para criar ou atualizar um pool de nós gerenciados, você especifica o OCID da imagem que o Kubernetes Engine usa para provisionar nós gerenciados no pool de nós. Se você especificar o OCID de uma imagem personalizada, a imagem personalizada poderá estar na mesma tenancy do cluster ou em outra tenancy. Se a imagem personalizada estiver em outra tenancy, deverão existir políticas para permitir o acesso à outra tenancy para ler a imagem.

Na tenancy (a tenancy de origem) que contém o cluster com o pool de nós gerenciados que você deseja que o Kubernetes Engine provisione usando uma imagem personalizada, o administrador de origem deve criar instruções de política para endossar o acesso à imagem personalizada na tenancy de destino. Por exemplo:

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'

Na tenancy que contém a imagem personalizada (a tenancy de destino), o administrador de destino deve criar instruções de política para admitir o acesso da tenancy de origem à imagem personalizada. Por exemplo:

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'