Políticas do IAM para Roteamento entre VCNs

Saiba mais sobre políticas de IAM usadas com gateways de pareamento e roteamento dinâmico.

Para obter políticas mais gerais do IAM usadas na rede, consulte Políticas do IAM para Redes.

Para políticas do serviço IAM específicas para pareamento local ou remoto usando DRGs, consulte:

Para políticas do serviço IAM específicas para pareamento local usando LPGs, consulte:

Para políticas do serviço IAM específicas para anexar DRGs e VCNs, consulte:

Controlando o Estabelecimento de Pareamentos

Com políticas do IAM, você pode controlar:

Quem pode inscrever a sua tenancy em outra região (necessária para pareamento remoto de VCNs).
Quem na sua organização tem autoridade para estabelecer pareamentos de VCNs (por exemplo, consulte as políticas do IAM em Configurando um Pareamento Local e Configurando um Pareamento Remoto). A exclusão dessas políticas de IAM não afeta os pareamentos existentes, mas apenas a capacidade de criar pareamentos futuros.
Para pareamento de VCN local por meio de um DRG mutuamente anexado na mesma tenancy e região, nenhuma política especial do serviço IAM é necessária. Se o pareamento pode ocorrer com VCNs em outra tenancy (que pode pertencer à sua organização, à Oracle ou a terceiros) exigiria instruções de política especiais para permitir o pareamento entre tenancies. Nas instruções, você pode especificar qual tenancy específica. Para pareamento de VCN local por meio de um DRG mutuamente anexado em outra tenancy, mas na mesma região, consulte Anexando a VCNs em Outras Tenancies. Para pareamento remoto de VCN (possivelmente para outra tenancy), consulte Pareamento Remoto com um DRG Legado.
Quem pode gerenciar tabelas de roteamento e listas de segurança.

Acordo Explícito Obrigatório dos Dois Lados

O pareamento e o roteamento de trânsito envolvem duas VCNs pertencentes à mesma parte ou a duas partes diferentes. As duas partes podem estar na sua empresa, mas em departamentos distintos. Ou as duas partes podem estar em empresas totalmente diferentes (por exemplo, em um modelo de provedor de serviços). Consulte Acessando Recursos de Armazenamento de Objetos em Tenancies para obter mais exemplos de políticas de tenancy cruzada.

O acordo está na forma de políticas do Oracle Cloud Infrastructure Identity and Access Management que cada parte implementa para o compartimento ou a tenancy de sua própria VCN. Se as VCNs estiverem em tenancies específicas, cada administrador deverá fornecer o OCID da tenancy e usar instruções de política especiais para permitir o pareamento. Para obter detalhes sobre as políticas do serviço IAM necessárias para estabelecer conexão com uma VCN em outra tenancy, consulte Pareamento Remoto com um DRG Atualizado.

Instruções Endorse, Admit e Define

Veja aqui uma visão geral dos verbos usados nestas instruções:

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 que contém o grupo de usuários que cruzam os limites em outra tenancy para trabalhar com os recursos dessa tenancy. Nos exemplos, referimo-nos a essa tenancy como a tenancy de origem.
Admit: Indica o tipo de capacidade em sua própria tenancy que você deseja conceder a um grupo da 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, referimo-nos a essa tenancy como a tenancy de destino.
Define: Designa um alias local 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.

Inclua uma instrução Define na mesma entidade de política que a instrução Endorse ou Admit.

As instruções Endorse e Admit funcionam juntas. Uma instrução Endorse reside na tenancy de origem enquanto uma instrução Admit reside na tenancy de destino. Sem uma instrução correspondente que especifique o acesso, uma determinada instrução Endorse ou Admit não concede acesso. As duas tenancies devem concordar com o acesso.

Importante

Além das instruções de política, você também deve se inscrever em uma região para compartilhar recursos entre regiões.

Pareamento Remoto com um DRG Legado

Um DRG pode estabelecer conexão com outro DRG (e qualquer VCN anexada) em outra região, desde que os compartimentos que contêm o solicitante e o aceitador tenham as políticas corretas em vigor. Essas políticas são:

Política R (implementada pelo solicitante):
```
Define group RequestorGrp as <requestorGroupOcid>
Define compartment RequestorComp as <RequestorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-from in compartment RequestorComp
```
O solicitante está em um grupo do IAM chamado RequestorGrp. Essa política permite que qualquer pessoa do grupo comece uma conexão por meio de qualquer DRG no compartimento do solicitante (RequestorComp). A Política R pode ser anexada à tenancy ( compartimento raiz) ou a RequestorComp. Para obter informações sobre o motivo pelo qual anexar a um e não ao outro, consulte Conceitos Básicos de Política.
Política A (implementada pelo aceitador):
```
Define group RequestorGrp as <requestorGroupOcid>
Define compartment AcceptorComp as <AcceptorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-to in compartment AcceptorComp
```
Essa política permite que o solicitante se conecte com qualquer RPC no compartimento do aceitador (AcceptorComp). Esta instrução reflete o acordo necessário no lado do aceitador para que o pareamento seja estabelecido. A Política A pode ser anexada à tenancy ( compartimento raiz) ou a AcceptorComp.

Esta imagem mostra as duas políticas para VCNs na mesma tenancy, mas em diferentes regiões.

A Política R e a Política A permitem o acesso a RequestorGrp. No entanto, a Política R tem um tipo de recurso chamado pareamento remoto de origem e a Política A tem um tipo de recurso chamado pareamento remoto de destino. Em conjunto, essas políticas permitem que alguém em RequestorGrp estabeleça uma conexão entre uma RPC no compartimento do solicitante e uma RPC no compartimento do aceitador. A chamada da API para criar a conexão especifica as duas RPCs.

Dica

A permissão concedida pela Política R pode já estar implementada se o solicitante tiver permissão em outra política para gerenciar todos os componentes do serviço Networking em RequestorComp. Por exemplo, pode haver uma política geral de administração de rede como esta: Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorComp. Se o solicitante estiver no grupo NetworkAdmin, ele já terá as permissões necessárias abordadas na Política R (a família de redes virtuais inclui RPCs). Além disso, se a política tiver sido elaborada para cobrir a tenancy inteira (Allow group NetworkAdmin to manage virtual-network-family in tenancy), o solicitante já terá todas as permissões necessárias em ambos os compartimentos para estabelecer a conexão. Nesse caso, a política A não é obrigatória.

Pareamento Remoto com um DRG Atualizado

Tanto o solicitante quanto o aceitador devem garantir que as políticas corretas estejam implementadas. Este exemplo mostra as políticas de identidade mínimas necessárias para criar uma conexão de pareamento remoto entre tenancies:

Política R (implementada pelo solicitante):

Define group requestorGroup as <requestorGroupOcid>
Define compartment requestorCompartment as id <requestorCompartmentOcid>
Define tenancy Acceptor as <AcceptorTenancyOcid>

Allow group requestorGroup to manage remote-peering-from in compartment requestorCompartment
Endorse group requestorGroup to manage remote-peering-to in tenancy Acceptor

Política A (implementada pelo aceitador):

Define group requestorGroup as <requestor-group-ocid>
Define tenancy Requestor as <requestorTenancyOcid>
Define compartment acceptorCompartment as id <acceptorCompartmentOcid>

Admit group requestorGroup of tenancy Requestor to manage remote-peering-to in compartment <acceptorCompartment>

Pareamento Local usando um LPG (VCNs na Mesma Tenancy)

Nesse caso de uso, as duas VCNs estão na mesma tenancy. Se eles estiverem em tenancies diferentes, consulte Pareamento Local usando um LPG (VCNs em Tenancies Diferentes).

Os administradores das VCNs do solicitante e do aceitador devem garantir que as políticas corretas estejam implementadas:

Política R (implementada pelo solicitante):
```
Define group requestorGrp as <requestorGroupOcid>
Define compartment requestorComp as <requestorCompartmentOcid>

Allow group requestorGrp to manage local-peering-from in compartment requestorComp
```
O solicitante está em um grupo do IAM chamado requestorGrp. Esta política permite que qualquer pessoa do grupo comece uma conexão por meio de qualquer LPG no compartimento do solicitante (requestorComp). A Política R pode ser anexada à tenancy ( compartimento raiz) ou a requestorComp. Para obter informações sobre o motivo pelo qual anexar a um e não ao outro, consulte Conceitos Básicos de Política.
Política A (implementada pelo aceitador):
```
Define group requestorGrp as <requestorGroupOcid>
Define compartment acceptorComp as id <acceptorCompartmentOcid>

Allow group requestorGrp to manage local-peering-to in compartment acceptorComp
Allow group requestorGrp to inspect vcns in compartment acceptorComp
Allow group requestorGrp to inspect local-peering-gateways in compartment acceptorComp
```
As instruções da política permitem que o solicitante estabeleça conexão com qualquer LPG no compartimento do aceitador (acceptorComp). Esta instrução reflete o acordo necessário no lado do aceitador para que o pareamento seja estabelecido. A Política A pode ser anexada à tenancy ( compartimento raiz) ou a acceptorComp.

Dica

As instruções na Política A permitem que o solicitante liste as VCNs e os LPGs em acceptorComp. As instruções são necessárias para que o solicitante use a interface do usuário da Console para selecionar as opções em uma lista de VCNs e LPGs em acceptorComp e estabelecer a conexão. O diagrama a seguir se concentra apenas na primeira instrução, que é crítica para permitir a conexão.

Esta imagem mostra as duas políticas para VCNs na mesma tenancy.

A Política R e a Política A permitem o acesso a requestorGrp. No entanto, a Política R tem um tipo de recurso chamado pareamento local de origem e a Política A tem um tipo de recurso chamado pareamento local de destino. Juntas, essas políticas permitem que alguém em requestorGrp estabeleça uma conexão entre um LPG no compartimento do solicitante e um LPG no compartimento do aceitador. A chamada da API para criar a conexão especifica os dois LPGs.

Dica

A permissão concedida pela Política R pode já estar implementada se o solicitante tiver permissão em outra política para gerenciar todos os componentes do serviço Networking em RequestorComp. Por exemplo, pode haver uma política geral de Administração de Redes como esta:

 Allow group NetworkAdmin to manage virtual-network-family in compartment requestorComp

Se o solicitante estiver no grupo NetworkAdmin, ele já terá as permissões necessárias abordadas na Política R (a família de redes virtuais inclui LPGs). E, além disso, se a política tiver sido elaborada para cobrir a tenancy inteira, em vez de apenas o compartimento requestorComp, o solicitante já terá todas as permissões necessárias em ambos os compartimentos para estabelecer a conexão. Nesse caso, a política A não é obrigatória.

Pareamento Local usando um LPG (VCNs em Tenancies Diferentes)

In this use case, the VCNs are in different tenancies (in other words, it's a cross-tenancy peering). Se as VCNs estiverem na mesma tenancy, consulte Pareamento Local usando um LPG (VCNs na Mesma Tenancy).

Tanto o solicitante quanto o aceitador devem garantir que as políticas corretas estejam implementadas:

Política R (implementada pelo solicitante):
```
Define tenancy Acceptor as <acceptorTenancyOcid>
Define group requestorGrp as <requestorGroupOcid>
Define compartment requestorComp as id <requestorCompartmentOcid>

Allow group requestorGrp to manage local-peering-from in compartment requestorComp
Endorse group requestorGrp to manage local-peering-to in tenancy Acceptor
Endorse group requestorGrp to associate local-peering-gateways in compartment requestorComp
   with local-peering-gateways in tenancy Acceptor
```
O solicitante está em um grupo do serviço IAM com um OCID designado que você fornece. Esta política permite que qualquer pessoa desse grupo comece uma conexão por meio de qualquer LPG no compartimento do solicitante (requestorComp).

A primeira instrução é uma instrução "define" que designa um label amigável ao OCID da tenancy do aceitador. A instrução utiliza "Acceptor" como label, mas pode ser utilizado um valor da escolha do solicitante. Todas as instruções "define" em uma política devem ser as primeiras (localizadas na parte superior).

A segunda instrução permite que requestorGrp estabeleça uma conexão por meio de um LPG no compartimento do solicitante.

As instruções "Permitir" e "Endossar" são especiais e obrigatórias porque os LPGs estão em diferentes tenancies. Elas permitem que requestorGrp conectem um LPG na tenancy do solicitante a um LPG na tenancy do aceitador.

Se a intenção for conceder a requestorGrp permissão para estabelecer conexão com um LPG em qualquer tenancy, a política terá a seguinte aparência:
```
Allow group requestorGrp to manage local-peering-from in compartment requestorComp
Endorse group requestorGrp to manage local-peering-to in any-tenancy
Endorse group requestorGrp to associate local-peering-gateways in compartment requestorComp with local-peering-gateways in any-tenancy
```
De qualquer forma, a Política R deverá estar anexada à tenancy do solicitante (compartimento raiz), e não ao compartimento do solicitante. As políticas que permitem acesso cruzado às tenancies devem estar anexadas à tenancy. Para obter mais informações sobre a anexação de políticas, consulte Conceitos Básicos de Política.
Política A (implementada pelo aceitador):
```
Define tenancy Requestor as <requestorTenancyOcid>
Define group requestorGrp as <requestorGroupOcid>
Define compartment acceptorComp as id <acceptorCompartmentOcid>

Admit group requestorGrp of tenancy Requestor to manage local-peering-to in compartment acceptorComp
Admit group requestorGrp of tenancy Requestor to associate local-peering-gateways in tenancy Requestor with local-peering-gateways in compartment acceptorComp
```
Da mesma forma que a política do solicitante, esta política primeiro usa instruções "define" para designar labels amigáveis ao OCID da tenancy do solicitante e ao OCID do grupo de administradores do solicitante. Conforme mencionado anteriormente, o aceitador poderá usar outros valores para esses labels, se desejado.

A quarta e a quinta instruções permitem que requestorGrp estabeleça conexão com um LPG no compartimento do aceitador (acceptorComp). Essas instruções refletem o acordo crítico necessário para que o pareamento seja estabelecido. A palavra Admit indica que o acesso se aplica a um grupo fora da tenancy em que a política reside.

A Política A deve ser anexada à tenancy do aceitador (compartimento raiz), e não ao compartimento do aceitador.

Esta imagem mostra o local das duas políticas para VCNs em diferentes tenancies.

Anexando a VCNs na Mesma Tenancy

Se você quiser que o grupo de administradores de VCN crie e gerencie anexos de VCN e atribua tabelas de roteamento do DRG aos anexos, implemente a seguinte política:

define group VcnAdmin as <vcnAdminGroupOcid>

Allow group VcnAdmin to manage vcns in tenancy
Allow group VcnAdmin to manage drgs in tenancy

Observação

Para associar uma tabela de roteamento da VCN ao anexo, adicione esta linha adicional:

Allow group VCN-Admin to manage route-tables in tenancy

Anexando a VCNs em Outras Tenancies

"Anexos entre tenancies" são anexos especiais da VCN usados para conectar um DRG diretamente a uma VCN em outra tenancy, mas localizados na mesma região. A VCN não será anexada a um DRG em sua própria tenancy. O exemplo de política abaixo detalha os requisitos mínimos de política do serviço IAM para ambas as tenancies para permitir esse tipo de conexão.

Este exemplo de um conjunto de políticas permite o seguinte conjunto de ações:

Os administradores de DRG no locatário do DRG podem criar um anexo do DRG no locatário da VCN.
Os administradores de VCN no tenant da VCN podem associar uma tabela de roteamento da VCN ao anexo (usado quando a VCN anexada é uma VCN de trânsito). Se o administrador da VCN tiver uma política para gerenciar todos os recursos no tenant da VCN, ele já terá essa capacidade, visto que o anexo da VCN reside na tenancy da VCN.
Os administradores de VCN não têm a capacidade de alterar a associação da tabela de roteamento do DRG para o anexo do DRG.

Política R (DRG nesta tenancy)

define group vcnAdmin as <vcnAdminGroupOcid>
define group drgAdmin as <drgAdminGroupOcid>
define tenancy acceptorVCN as <acceptorTenancyOcid>

endorse group drgAdmin to manage drg-attachment in tenancy acceptorVCN
admit group vcnAdmin of tenancy acceptorVCN to manage drg in tenancy

vcnAdminGroupOcid é o OCID do grupo vcnAdmin que está na tenancy do Aceitador e endossado na política do Aceitador.

Política A (VCN nesta tenancy)

define tenancy requestorDRG as <requestorTenancyOcid>
define group drgAdmin as <drgAdminGroupOcid>
define group vcnAdmin as <vcnAdminGroupOcid>

admit group drgAdmin of tenancy requestorDRG to manage drg-attachment in tenancy
endorse group vcnAdmin to manage drg in tenancy requestorDRG

drgAdminGroupOcid é o OCID do grupo drgAdmin que está na tenancy do Solicitante e endossado na política do Solicitante.

Documentação do Oracle Cloud Infrastructure