Usando Tags para Gerenciar o Acesso
Este tópico descreve como usar tags na política para definir o escopo do acesso com base nas tags aplicadas ao solicitante ou ao destino de uma chamada de autorização.
Sobre o Controle de Acesso Baseado em Tag
Usando condições e um conjunto de variáveis de tag, você pode gravar a política para definir o escopo do acesso com base nas tags que foram aplicadas a um recurso. O acesso pode ser controlado com base em uma tag que existe no recurso solicitante (grupo, grupo dinâmico ou compartimento) ou no destino da solicitação (recurso ou compartimento). O controle de acesso baseado em tag fornece mais flexibilidade às suas políticas, permitindo que você defina políticas de acesso com tags que abrangem compartimentos, grupos e recursos.
Se sua organização optar por criar políticas que usam tags para gerenciar o acesso, certifique-se de ter os controles apropriados, para controlar quem pode aplicar tags. Além disso, depois que as políticas estiverem implantadas, lembre-se de que a aplicação de tags a um grupo, usuário ou recurso tem o potencial de conceder acesso aos recursos.
Antes de criar uma política que especifique uma tag em um destino ou um solicitante, esteja ciente do seguinte:
- todos os possíveis solicitantes (usuários, grupos, grupos dinâmicos) que detêm a tag
- todos os recursos que detêm a tag
Antes de aplicar uma tag a um recurso, esteja ciente da existência de qualquer política que inclua a tag e possa afetar quem tem acesso ao recurso.
Gerenciando o Acesso por meio de Tags Aplicadas ao Recurso Solicitante
Você pode controlar o acesso com base no valor de uma tag aplicada a:
- um grupo (de usuários) que solicita acesso
- um grupo dinâmico (de instâncias) que solicita acesso
- um compartimento no qual reside um recurso em um grupo dinâmico
Usando tags em suas instruções de política para definir o escopo do acesso, você pode definir o acesso para vários grupos por meio de uma única instrução de política. Você também pode conceder e revogar o acesso aos grupos aplicando ou removendo tags, sem alterar as políticas originais.
A sintaxe básica para cada variável é mostrada na tabela a seguir. Observe que a sintaxe é a mesma para o grupo e o grupo dinâmico, mas cada uma é apresentada em uma linha distinta. Consulte Operadores Suportados para ver mais exemplos de uso.
| Tag Aplicada ao Solicitante | Sintaxe de Variável | Descrição |
|---|---|---|
|
group |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Amostra de política para o grupo de usuários:
Qualquer usuário que pertença a um grupo que tenha sido marcado com a tag Operations.Project='Prod' pode gerenciar instâncias no compartimento HR. |
As tags aplicadas aos grupos aos quais o usuário pertence são avaliadas para ver se há correspondência. |
|
dynamic group |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Amostra de política para o grupo dinâmico:
As instâncias que são membros do grupo dinâmico InstancesA e que também são membros de um grupo dinâmico marcado com a tag Operations.Project='Prod' podem gerenciar instâncias no compartimento HR. |
As tags aplicadas aos grupos dinâmicos aos quais a instância pertence são avaliadas para ver se há correspondência. |
|
compartimento |
request.principal.compartment.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Amostra de política:
As instâncias que são membros do grupo dinâmico InstancesA e que também residem em um compartimento marcado com a tag Operations.Project='Prod' podem gerenciar instâncias na tenancy. |
As tags aplicadas ao compartimento ao qual o recurso solicitante pertence são avaliadas. |
Os usuários residem no compartimento-raiz da sua tenancy; portanto, as tags devem ser aplicadas ao compartimento-raiz para que essas instruções de política funcionem.
Gerenciando o Acesso por meio de Tags Aplicadas ao Recurso de Destino
Você pode controlar o acesso com base no valor de uma tag aplicada a:
- um recurso
- um compartimento no qual reside o recurso de destino
A sintaxe básica dessas variáveis é mostrada na tabela a seguir. Consulte Operadores Suportados para obter mais exemplos de uso.
| Tag Aplicada ao Destino | Sintaxe de Variável | Descrição |
|---|---|---|
|
recurso |
target.resource.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Amostra de política:
|
A tag aplicada ao recurso de destino da solicitação é avaliada. Há limitações para as permissões que podem ser concedidas neste tipo de política. Consulte as seções a seguir neste tópico para obter detalhes. |
|
compartimento |
target.resource.compartment.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Amostra de política:
|
A tag aplicada ao compartimento de destino da solicitação é avaliada. Consulte Hierarquias de Compartimento para obter detalhes sobre como o acesso é concedido em compartimentos aninhados. |
As Permissões para Listar um Recurso Devem ser Concedidas Separadamente
As políticas que definem o escopo do acesso com base na tag aplicada ao recurso de destino não podem conceder permissões para retornar uma lista de recursos. Portanto, as permissões para a listagem de um recurso devem ser concedidas por meio de uma instrução de política adicional. Isso significa que, se você tiver definido uma política como:
allow group GroupA to manage all-resources in compartment Operations where target.resource.tag.Operations.Project= 'Prod'
GroupA não poderá listar nenhum recurso que ele de outra forma tenha permissão para gerenciar. Os membros de GroupA não conseguiriam usar a Console para interagir com esses recursos e os usuários precisariam saber o OCID do recurso que estão tentando gerenciar, o que também dificulta o uso do SDK e da CLI.
Para permitir que GroupA liste esses recursos, adicione outra instrução de política como:
allow group GroupA to inspect all-resources in compartment Operations
Essa abordagem melhora a política baseada em tag, pois permite que os usuários utilizem a Console de forma mais fácil (permitindo que eles vejam o recurso que desejam gerenciar), mas ainda limita as permissões apenas à inspeção. Os membros de GroupA não podem tomar nenhuma medida nesses recursos, a menos que eles estejam marcados com tag adequadamente. Ao usar o controle de acesso baseado em tag, lembre-se de que a flexibilidade adicionada exige essa possível expansão adicional de acesso.
Outra abordagem que você pode usar para evitar essa limitação é marcar com tag os compartimentos que contêm os recursos aos quais você deseja conceder acesso. Um exemplo de política é semelhante a este:
allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'Esta política permite que os membros de GroupA gerenciem todos os recursos na tenancy que estão em compartimentos que estão marcados com a tag Operations.Project='Prod'.
Políticas que Requerem uma Tag no Recurso de Destino Não Podem Conceder Permissões de Criação
Quando você gravar uma política para definir o escopo de acesso com base no valor de uma tag no recurso, lembre-se de que a política não pode conceder permissões de criação. Uma solicitação para criar uma instância falhará porque o recurso de destino ainda não foi criado e, portanto, não tem a tag apropriada para ser avaliada. Assim, uma política como:
allow group GroupA to manage instances in compartment Operations where target.resource.tag.Operations.Project='Prod'
permite que os membros de GroupA usem e excluam instâncias marcadas com a tag Operations.Project='Prod', mas eles não podem criar instâncias.
Operadores Suportados
Sua política que usa essas variáveis de tag pode incluir esses operadores e tipos de correspondência:
| Operador | Tipo | Exemplo | Descrição |
|---|---|---|---|
| = | String | request.principal.group.tag.MyTagNamespace.MyTag='sample'
|
Será avaliado como verdadeiro se qualquer um dos grupos ao qual o solicitante pertence estiver marcado com o valor de correspondência "sample" para MyTagNamespace.MyTag. (O valor não faz distinção entre maiúsculas e minúsculas.) |
| Padrão | request.principal.group.tag.MyTagNamespace.MyTag=/*sample/
|
Será avaliado como verdadeiro se qualquer um dos valores de MyTagNamespace.MyTag terminar com "sample". (Correspondência simples de padrão sem distinção entre maiúsculas e minúsculas.) | |
| Variável da política | request.principal.group.tag.mytagnamespace.mytag = target.resource.tag.mytagnamespace.mytag |
Avaliado como verdadeiro quando o recurso especificado mytagnamespace.mytag tem um valor que corresponde ao destino especificado mytagnamespace.tag. | |
| != | String | request.principal.group.tag.MyTagNamespace.MyTag !='sample'
|
Será avaliado como verdadeiro se nenhum dos valores de string da variável de política for igual a "sample". (Comparação simples de string sem distinção entre maiúsculas e minúsculas.) |
| Padrão | request.principal.group.tag.MyTagNamespace.MyTag !=/*sample/
|
Será avaliado como verdadeiro se nenhum dos valores de MyTagNamespace.MyTag terminar com "sample". (Correspondência simples de padrão sem distinção entre maiúsculas e minúsculas.) | |
| Variável da política | request.principal.group.tag.mytagnamespace.mytag != target.resource.tag.mytagnamespace.mytag |
Será avaliado como verdadeiro se nenhum lado for um subconjunto do outro. |
In / Not In
| Operador | Tipo | Exemplo | Descrição |
|---|---|---|---|
| in | String | request.principal.group.tag.MyTagNamespace.MyTag in ('sample', 'sample1')
|
A cláusula será avaliada como verdadeira se qualquer um dos valores de MyTagNamespace.MyTag para qualquer grupo do principal solicitante atual for igual a "sample" ou "sample1". |
| Padrão | request.principal.group.tag.MyTagNamespace.MyTag in (/*sample/, /sample1*/)
|
A cláusula será avaliada como verdadeira se qualquer um dos valores de MyTagNamespace.MyTag para qualquer grupo do principal solicitante atual terminar com "sample" ou começar com "sample1". | |
| Variável da política | request.principal.group.tag.MyTagNamespace.MyTag in (target.resource.tag.mytagnamespace.mytag, 'sample') |
A cláusula será avaliada como verdadeira se qualquer uma das seguintes condições for atendida: 1 request.principal.group.tag.MyTagNamespace.MyTag ou target.resource.tag.mytagnamespace.mytag é um subconjunto do outro. 2. Qualquer valor de string de request.principal.group.tag.MyTagNamespace.MyTag for igual a "sample". |
|
| not in | String | request.principal.group.tag.MyTagNamespace.MyTag not in ('sample', 'sample1')
|
A cláusula será avaliada como verdadeira se nenhum dos valores de MyTagNamespace.MyTag para qualquer grupo do principal solicitante atual for igual a "sample" ou "sample1". |
| Padrão | request.principal.group.tag.MyTagNamespace.MyTag not in (/*sample/, /sample1*/)
|
A cláusula será avaliada como verdadeira se nenhum dos valores de MyTagNamespace.MyTag para qualquer grupo do principal solicitante atual terminar com "sample" ou começar com "sample1". | |
| Variável da política | request.principal.group.tag.MyTagNamespace.MyTag not in (target.resource.tag.mytagnamespace.mytag, 'sample')
|
A cláusula será avaliada como verdadeira se todas as seguintes condições forem atendidas: 1. Nem request.principal.group.tag.MyTagNamespace.MyTag nem target.resource.tag.mytagnamespace.my for um subconjunto do outro. 2. Nenhum dos valores de string de request.principal.group.tag.MyTagNamespace.MyTag for igual a "sample". |
Suporte para Curingas
Você pode usar o caractere * para correlacionar todas as ocorrências de {tagNamespace}. {tagKeyDefinition} independentemente do valor. Na política, você pode colocar * entre aspas simples '*' ou entre barras /*/. Por exemplo,
allow group GroupA to use all-resources in compartment HR where target.resource.tag.HR.Project= '*'
Neste exemplo, GroupA pode usar todos os recursos no compartimento HR que estão marcados com o namespace de tag e a chave de tag: HR.Project com qualquer valor.
Limitações de Caracteres em Namespaces de Tag e Definições de Chave de Tag Usadas em Variáveis de Política
Os namespaces de tag e as definições de chave de tag suportam um conjunto mais amplo de caracteres do que o permitido em variáveis de política. Portanto, para usar namespaces de tag e definições de chave de tag em variáveis, certifique-se de que eles só incluam os caracteres suportados também pelas variáveis de política. Os caracteres suportados são:
a-z, A-Z, 0-9, _, @, -, :
Se seus namespaces de tag ou chaves de tag tiverem caracteres diferentes desses, não será possível usá-los em variáveis de política. Namespaces de tag e chaves de tag não podem ser renomeados; portanto, você terá de criar novos namespaces de tag e definições de chave de tag.
Considerações para Maiúsculas e Minúsculas
Ao trabalhar com tags em políticas, esteja ciente de que os valores de tags não fazem distinção entre maiúsculas e minúsculas. Por exemplo:
request.principal.group.tag.MyTagNamespace.MyTag='sample'
é o mesmo que
request.principal.group.tag.MyTagNamespace.MyTag='Sample'
Hierarquias de Compartimento
Quando você gravar uma condição para permitir o acesso com base na tag aplicada a um compartimento de destino, lembre-se de que essa política também permite o acesso a todos os compartimentos aninhados no compartimento marcado com tag. Todos os subcompartimentos do compartimento marcado com tag são recursos no compartimento marcado com tag e, portanto, a política concede acesso.
Por exemplo, neste cenário:
A política:
allow group GroupA to use all-resources in tenancy where target.resource.compartment.Operations.Project='ProjectA'permite que o GroupA use todos os recursos no CompartmentA, CompartmentA1 e CompartmentA1.1, mesmo que a tag seja aplicada somente ao CompartmentA.
Serviços Suportados
Todos os serviços do Oracle Cloud Infrastructure suportam as variáveis de política request.principal.compartment, request.principal.group e target.resource.compartment.tag.
Nem todos os serviços suportam a variável de política target.resource.tag. A tabela a seguir lista os serviços suportados. Se o serviço não estiver listado na tabela, é porque no momento não há suporte para ele.
Alguns serviços têm limitações. Consulte o link apropriado na tabela.
| Serviços Suportados | Mais Informações |
|---|---|
| Serviço API Gateway | Consulte Limitações do Serviço API Gateway. |
| Serviço Big Data | Consulte Limitações do Serviço Big Data. |
| Blockchain Platform | Totalmente suportado, sem limitações. |
| Serviço Block Volume | Consulte Limitações do Serviço Block Volume. |
| Certificados | Totalmente suportado, sem limitações. |
| Serviço Compute | Consulte Limitações do Serviço Compute. |
| Serviço Compute Management | Consulte Limitações do Serviço Compute Management. |
| Content Management | Consulte Limitações do Serviço Content Management. |
| Serviço Data Catalog | Consulte Limitações do Serviço Data Catalog. |
| Serviço Data Flow | Totalmente suportado, sem limitações. |
| Serviço Data Science | Consulte Limitações do Serviço Data Science. |
| Database | Consulte Limitações do Serviço Database. |
| Serviço Digital Assistant | Consulte Limitações do Serviço Digital Assistant. |
| Serviço DNS | Consulte Limitações do DNS Público. |
| Serviço Email Delivery | Totalmente suportado, sem limitações. |
| FastConnect | Totalmente suportado, sem limitações. |
| Serviço Functions | Totalmente suportado, sem limitações. |
| Health Checks | Totalmente suportado, sem limitações. |
| Serviço IAM | Os recursos suportados são: users, groups, policies, dynamic-groups, network-sources e identity-providers |
| Balanceador de Carga | Consulte Limitações do Serviço Load Balancing. |
| MySQL HeatWave | Totalmente suportado, sem limitações. |
| Rede | Consulte Limitações do Serviço Networking. |
| Serviço NoSQL Database Cloud | Consulte Limitações do Serviço Networking. |
| Serviço Notifications | Totalmente suportado, sem limitações. |
| Serviço Object Storage | Consulte Consulte Limitações do Serviço Object Storage. |
| Serviço de Cotas | Totalmente suportado, sem limitações. |
| Namespace de Tag | Consulte Limitações de Namespace de Tag. |
| Serviço Vault | Sem suporte a criptografia. |
| Serviço WAF | Consulte Limitações do Serviço WAF. |
Limitações e Políticas Adicionais Necessárias para Cenários Específicos de Target.Resource.Tag
Para alguns serviços, nem todas as permissões ou tipos de recursos são suportados. Quando não há suporte para uma permissão, isso significa que, mesmo que o recurso esteja marcado com tag e a permissão esteja incluída no verbo que concede o acesso, essa permissão não será aceita e a autorização falhará para a operação governada pela permissão. Por exemplo, o recurso do serviço Block Volume volume-backups não suporta controle de acesso baseado em tag para a permissão VOLUME_BACKUP_COPY. Portanto, essa política:
allow group TestGroup to manage volume-backups in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'não permite que os membros do grupo TestGroup executem a operação CopyVolumeBackup. Para conceder essa permissão ao TestGroup, você precisaria adicionar outra instrução de política para abrangê-la.
Além disso, alguns cenários operacionais exigem autorização para acessar vários recursos. Ao definir o escopo do acesso a tags que são aplicadas ao recurso de destino, você deve incluir uma política separada para cada recurso envolvido na operação. Além disso, em decorrência das limitações para listar recursos e outras permissões específicas do serviço, políticas adicionais (sem escopo definido pela tag) são necessárias.
Limitações do Serviço API Gateway
Além da política de controle de acesso baseada em tag esperada para recursos do serviço API Gateway, você precisará de uma política que permita gerenciar permissões para api-workrequests.
Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage api-workrequests in compartment Compartment1Limitações do Serviço Big Data
Além da política de controle de acesso baseada em tag esperada para recursos do Big Data Service, você precisará de uma política que permita gerenciar permissões para cluster-work-requests.
Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage cluster-work-requests in compartment Compartment1Limitações do ServiçoBlock Volume
| Serviço | Tipo de Recurso com Limitações | Permissões Não Suportadas com a Variável de Política target.resource.tag |
|---|---|---|
| Serviço Block Volume | backup-policy-assignments
|
BACKUP_POLICY_ASSIGNMENT_DELETE |
volume-backups
|
VOLUME_BACKUP_COPY |
Cenários que requerem política adicional:
Anexe um volume em blocos a uma instância de computação:
Para anexar um volume em blocos a uma instância de computação, além da política de controle de acesso baseado em tag para permitir o verbo use em volumes e instâncias, você precisará de algumas permissões adicionais.
Por exemplo:
allow group TestGroup to use volumes in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Essas duas políticas permitem que os membros do TestGroup usem volumes e instâncias do Compartment1, quando os recursos têm a tag apropriada. Para permitir que os membros anexem um volume em blocos a uma instância, você também precisará de políticas que concedam as permissões mostradas nas seguintes instruções:
allow group TestGroup to read instances in compartment Compartment1
allow group TestGroup to manage volume-attachments in compartment Compartment1 where any {request.permission='VOLUME_ATTACHMENT_CREATE', request.permission='VOLUME_ATTACHMENT_DELETE'}Limitações do Serviço Compute
| Serviço | Tipo de Recurso | Permissões Não Suportadas com a Variável de Política target.resource.tag |
|---|---|---|
| Computação | instance-console-connection
|
INSTANCE_CONSOLE _CONNECTION_DELETE |
instances
|
INSTANCE_POWER_ACTIONS |
Cenários que requerem política adicional:
Anexar instância de computação à sub-rede:
Para gerenciar a anexação de sub-rede de uma instância de computação, além da política de controle de acesso baseado em tag esperada para instances e subnets, mostrada aqui:
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Você precisará de permissões adicionais em vnics:
allow group TestGroup to use vnics in compartment Compartment1 where ANY{request.permission='VNIC_ATTACH', request.permission='VNIC_CREATE'}Excluir uma VNIC de uma instância de computação:
Para excluir uma VNIC de uma instância de computação, além da política de controle de acesso baseado em tag esperada para instances e subnets mostrada aqui:
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Você precisará de uma política para conceder permissões em vnics:
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}Limitações do Serviço Compute Management
| Serviço | Tipo de Recurso | Permissões Não Suportadas com a Variável de Política target.resource.tag | Observações |
|---|---|---|---|
| Serviço Compute Management | instance-pools
|
Todas as permissões | Não há suporte para o tipo de recurso instance-pools. |
auto-scaling-configurations
|
AUTO_SCALING_CONFIGURATION_UPDATE | . |
Limitações do Serviço Content Management
Além da política de controle de acesso baseada em tag esperada para recursos do Content Management, você precisará de uma política que permita gerenciar permissões para oce-work-requests.
Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage oce-requests in compartment Compartment1Limitações do Serviço Database
| Serviço | Tipo de Recurso | Permissões Não Suportadas com a Variável de Política target.resource.tag |
|---|---|---|
| Database | all
|
DATABASE_DELETE |
Atualizar Tags para o ExaData Infrastructure:
Não há suporte neste momento ao usar políticas de controle de acesso baseado em tag.
Cenários que requerem política adicional:
Excluir um Sistema de BD:
Para excluir ou atualizar um Sistema de BD, além da política de controle de acesso baseado em tag esperada para db-systems, mostrada aqui:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Você precisará de uma política que conceda permissões para db-backups, db-homes, vnics, subnets e databases. Aqui está um exemplo de política que mostra as permissões adicionais:
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_DELETE'
allow group TestGroup to manage vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}
allow group TestGroup to manage subnets in compartment Compartment1 where request.permission='SUBNET_DETACH'
allow group TestGroup to manage databases in compartment compartment1Mover um sistema de BD para outro compartimento:
Para mover um Sistema de BD para outro compartimento, além da política de controle de acesso baseado em tag esperada para db-systems mostrada aqui:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Você precisará de uma política que conceda permissões para databases, db-homes e db-backups. Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to use databases in compartment Compartment1 where request.permission='DATABASE_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_INSPECT'
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_UPDATE'Exclusão do banco de dados para o Sistema de BD do Exadata:
Para excluir um recurso de banco de dados em um Sistema de BD Exadata, você precisará da política de controle de acesso baseado em tag esperada para db-systems e databases mostrada aqui:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Você também precisará de permissões para db-homes e db-backups. Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permision='DB_HOME_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}Excluir Banco de Dados:
Não há suporte para a exclusão de um banco de dados para um sistema de BD de máquina virtual ou bare metal ao usar políticas baseadas em tag no recurso de destino.
Criação de backup do banco de dados:
Para criar um backup do banco de dados, você precisará da política de controle de acesso baseado em tag esperada para databases:
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Você também precisará de permissões para db-backups. Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_CREATE'Restauração do Banco de Dados:
Para restaurar um backup do banco de dados, você precisará da política de controle de acesso baseado em tag esperada para databases:
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Você também precisará de permissões para backups, como as mostradas aqui:
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_INSPECT', request.permission='DB_BACKUP_CONTENT_READ'}Criar associação do Data Guard:
Não há suporte para a criação de uma associação do Data Guard ao usar políticas baseadas em tag no recurso de destino.
Limitações do Serviço Data Catalog
Além da política de controle de acesso baseada em tag esperada para recursos do serviço Data Catalog, você precisará das seguintes políticas adicionais para data-catalog-family:
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'GetWorkRequest'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'ListWorkRequestErrors'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'listworkrequestlogs'Limitações do Serviço Data Science
Além da política de controle de acesso baseada em tags esperada para recursos do serviço Data Science, você precisará de uma política que permita gerenciar permissões para data-science-work-requests.
Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage data-science-work-requests in compartment Compartment1Limitações do Serviço Digital Assistant
| Serviço | Tipo de Recurso | Permissões Não Suportadas com a Variável de Política target.resource.tag |
|---|---|---|
| Serviço Digital Assistant | oda-design
|
Todas as permissões |
oda-insights
|
Todas as permissões |
Além da política de controle de acesso baseada em tag esperada para os recursos do serviço Oracle Digital Assistant, você precisará das seguintes políticas adicionais para oda-instances:
allow group TestGroup to inspect oda-instances in compartment Compartment1
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'GetWorkRequest'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'ListWorkRequestErrors'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'listworkrequestlogs'Limitações do Serviço Load Balancing
Cenários que requerem política adicional:
Atualizar Balanceador de Carga:
Para executar qualquer atualização em balanceadores de carga, além da política de controle de acesso baseado em tag esperada para load-balancers:
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Você precisará de uma política que permita a operação de API GetWorkRequest. Aqui está um exemplo de política com a permissão adicional:
allow group TestGroup to read load-balancers in compartment Compartment1 where request.operation = 'GetWorkRequest'
network-security-groupExcluir Balanceador de Carga:
Para excluir um balanceador de carga, além da política de controle de acesso baseado em tag esperada para load-balancers, subnets e network-security-group:
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use network-security-group in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Você precisará dessas permissões adicionais para vnics :
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission = 'VNIC_DETACH', request.permission = 'VNIC_DELETE', request.permission='VNIC_DISASSOCIATE_NETWORK_SECURITY_GROUP'}Limitações do Serviço Networking
| Serviço | Tipo de Recurso | Permissões Não Suportadas com a Variável de Política target.resource.tag | Observações |
|---|---|---|---|
| Rede | private-ips
|
PRIVATE_IP_UPDATE PRIVATE_IP_DELETE VNIC_UNASSIGN SUBNET_DETACH |
|
route-tables
|
UPDATE (INTERNET_GATEWAY_DETACH) | Não há suporte para a remoção de uma regra de roteamento. | |
vnics
|
VNIC_UPDATE VNIC_DELETE |
Anexar gateway de serviço ou gateway NAT a uma tabela de roteamento:
Não há suporte para a anexação de um gateway de serviço ou um gateway NAT a uma tabela de roteamento usando políticas baseadas em tag no recurso de destino.
Cenários que requerem política adicional:
Anexar DRG à VCN:
Para anexar o DRG à VCN, além da política de controle de acesso baseado em tag esperada para virtual-network-family e vcns:
allow group TestGroup to use virtual-network-family in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
Você precisará de uma política com permissões manage para drgs. Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage drgs in compartment Compartment1
Limitações do NoSQL Database Cloud Service
Os recursos suportados são: nosql-tables, nosql-rows e nosql-indexes.
Além da política de controle de acesso baseada em tag esperada para os recursos do serviço NoSQL Database Cloud, você precisará destas políticas adicionais:
allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequests'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestErrors'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestLogs'Observe que as políticas anteriores são necessárias para navegar pelos recursos do NoSQL Database Cloud na Console.
Limitações do Serviço Object Storage
| Serviço | Tipo de Recurso | Permissões Não Suportadas com a Variável de Política target.resource.tag | Observações |
|---|---|---|---|
| Serviço Object Storage | objects
|
Todas as permissões relacionadas ao acesso de objects |
Não é possível marcar objetos com tags. |
O acesso a objetos pode ser gerenciado usando as tags no bucket ao qual os objetos pertencem. Use a variável de política
target.bucket.tag. Consulte Permitir que os usuários gravem objetos em buckets do Object Storage.Limitações do DNS Público
Além da política de controle de acesso baseada em tag esperada para recursos de dns, você precisará de uma política que conceda permissões manage para dns-records. Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage dns-records in compartment Compartment1Limitações de Namespace de Tag
A política que concede a um usuário acesso a um namespace de tag com base em uma tag no namespace não permite ao usuário criar ou excluir definições de chave de tag nesse namespace de tag.
Por exemplo, a política:
allow group TestGroup to manage tag-namespaces in compartment Compartment1 where target.resource.tag.TagNS.TagKey='test'não permite que os usuários no TestGroup criem ou excluam definições de chave de tag nos namespaces de tag marcados com TagNS.TagKey='test'.
Limitações do Serviço WAF
Além da política de controle de acesso baseada em tag esperada para os recursos do serviço WAF, você precisará de uma política que permita gerenciar permissões para waas-work-request. Aqui está um exemplo de política com as permissões adicionais:
allow group TestGroup to manage waas-work-request in compartment Compartment1Exemplos Ilustrados
Exemplo com o Uso de Tags Aplicadas a um Grupo
Veja a seguir um exemplo que demonstra como usar tags aplicadas a grupos de usuários para gerenciar o acesso a recursos em um compartimento.
Suponha que existam três compartimentos: ProjectA, ProjectB e ProjectC
Para cada compartimento, há um grupo de administração configurado: A-Admins, B-Admins e C-Admins.
Cada grupo de administração tem acesso total a seus compartimentos por meio das seguintes políticas:
allow group A-Admins to manage all-resources in compartment ProjectAallow group B-Admins to manage all-resources in compartment ProjectBallow group C-Admins to manage all-resources in compartment ProjectC
Sua organização configurou o namespace de tag e a chave a seguir para marcar com tag cada grupo por sua atribuição:
- EmployeeGroup.Role
Alguns valores dessa tag são 'Admin', 'Developer', 'Test-Engineer'.
Todos os seus grupos administrativos estão marcados com a tag EmployeeGroup.Role='Admin'
Agora você deseja configurar um compartimento de Teste para compartilhamento entre os membros dos três projetos. Você deseja conceder acesso Admin a todos os três grupos admin existentes. Para fazer isso, você pode gravar uma política como:
allow any-user to manage all-resources in compartment Test where request.principal.group.tag.EmployeeGroup.Role='Admin'
Com essa política, todos os grupos administrativos existentes com a tag terão acesso ao compartimento de Teste. Além disso, quaisquer grupos novos ou existentes que você marcar com a tag EmployeeGroup.Role='Admin' no futuro terão acesso ao compartimento de Teste sem que seja necessário atualizar as instruções da política.
Exemplo com o Uso de Tags Aplicadas a um Recurso de Destino
Neste exemplo, cada um dos compartimentos do projeto da sua organização contém dois compartimentos filhos: Test e Prod. Você deseja dar aos engenheiros de teste acesso aos compartimentos de teste nos três projetos. Para fazer isso, você cria uma tag:
ResourceGroup.Role='Test'
e a aplica aos compartimentos de teste em cada um dos compartimentos do projeto.
Em seguida, você pode usar uma política como:
allow group Testers to use all-resources in tenancy where target.resource.compartment.tag.ResourceGroup.Role='Test'
para permitir que os Testadores do grupo acessem os recursos em todos os três compartimentos de teste.