Políticas do Serviço 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 em 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 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 em uma organização tem autoridade para estabelecer pareamentos de VCN (por exemplo, consulte as políticas do serviço IAM em Configurando um Pareamento Local e Configurando um Pareamento Remoto). A exclusão dessas políticas do IAM não afeta nenhum par existente, apenas a capacidade de futuros paringes a serem criados.
Para pareamento de VCN local por meio de um DRG mutuamente anexado na mesma tenancy e região, nenhuma política especial do IAM é necessária. Se o pareamento pode ocorrer com VCNs em uma tenancy diferente (que pode pertencer à sua organização, à Oracle ou a terceiros) exigiria instruções de política especiais para ativar o pareamento entre tenancies. Nas instruções, você pode especificar qual tenancy específica. Para pareamento de VCN local por meio de um DRG anexado mutuamente 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 mesma empresa, mas em departamentos diferentes. 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 é na forma de políticas do Oracle Cloud Infrastructure Identity and Access Management que cada parte implementa para o compartimento ou a tenancy da 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 IAM necessárias para estabelecer conexão com uma VCN em outra tenancy, consulte Pareamento Remoto com um DRG Submetido a Upgrade.

Instruções `Endorse`, `Admit` e `Define`

Aqui está uma visão geral dos verbos usados nestas instruções:

Endorse: Informa o conjunto geral de habilidades que um grupo na 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 na outra tenancy para trabalhar com os recursos dessa tenancy. Nos exemplos, chamamos essa tenancy de 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 concede "admitância" à tenancy. A instrução Admit identifica o grupo de usuários que requer acesso de recurso da tenancy da origem e é identificada com uma instrução Endorse correspondente. Nos exemplos, chamamos essa tenancy de 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 inicie uma conexão de qualquer DRG no compartimento do solicitante (RequestorComp). A política R pode ser anexada à tenancy (compartimento raiz) ou ao RequestorComp. Para obter informações sobre por que você a anexaria a um compartimento ou outro, consulte Noções Básicas de Políticas.
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 ao compartimento AcceptorComp.

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

A Política R e A concedem 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 saída. Juntas, essas políticas permitem que alguém em RequestorGrp estabeleça a conexão de uma RPC no compartimento do solicitante para uma RPC no compartimento do aceitador. A chamada de API para criar a conexão especifica quais duas RPCs.

Dica

A permissão concedida pela Política R talvez já esteja em vigor 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 semelhante à seguinte: 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 for escrita para abranger a tenancy completa (Allow group NetworkAdmin to manage virtual-network-family in tenancy), o solicitante já tem todas as permissões necessárias em ambos as compartimentos para estabelecer a conexão. Nesse caso, a política A não é obrigatória.

Pareamento Remoto com um DRG submetido a Upgrade

O solicitante e o aceitador devem garantir que a política necessária esteja em vigor. 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 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 necessárias estejam em vigor:

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 inicie uma conexão de qualquer LPG no compartimento do solicitante (requestorComp). A política R pode ser anexada à tenancy (compartimento raiz) ou ao requestorComp. Para obter informações sobre por que você a anexaria a um compartimento ou outro, consulte Noções Básicas de Políticas.
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 ao compartimento acceptorComp.

Dica

As instruções da Política A permitem que o solicitante liste as VCNs e LPGs em acceptorComp. As instruções são necessárias para que o solicitante use a IU da Console para selecionar de uma lista de VCNs e LPGs em acceptorComp e estabelecer a conexão. O diagrama de seguinte concentra-se apenas na primeira instrução, que é a crítica que permite 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

Talvez a permissão concedida pela Política R já esteja em vigor se o solicitante tiver permissão em outra política para gerenciar todos os componentes de Rede no RequestorComp. Por exemplo, pode haver uma política geral de Administração de Rede semelhante a 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). Além disso, se a política for gravada para abranger a tenancy completa em vez de apenas o compartimento requestorComp, o solicitante já poderá ter todas as permissões necessárias em ambos as 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)

Nesse caso de uso, as VCNs estão em diferentes tenancies (portanto, é um pareamento entre tenancies). Se as VCNs estiverem na mesma tenancy, consulte Pareamento Local usando um LPG (VCNs na Mesma Tenancy).

O solicitante e o aceitador devem garantir que a política necessária esteja em vigor:

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 IAM com um OCID designado que você fornece. Esta política permite que qualquer pessoa nesse grupo inicie uma conexão 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 Allow e Endorse 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 finalidade for conceder à requestorGrp permissão para se conectar a um LPG em qualquer tenancy, a política será semelhante a esta:
```
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
```
Assim como a política do Solicitante, essa 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 designe 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:

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

Anexando a VCNs em Outras Tenancies

"Anexos entre tenancies" são anexos de VCN especiais usados para conectar um DRG diretamente a uma VCN em outra tenancy, mas localizados na mesma região. A VCN é anexada a um DRG em uma tenancy separada. O exemplo de política a seguir detalha os requisitos mínimos de política do 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 tenant do DRG podem criar um anexo do DRG no tenant 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 podem 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 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 na tenancy do Solicitante e endossado na política do Solicitante.

Documentação do Oracle Cloud Infrastructure