Capítulo 3: OCI Foundations

3.6 IAM, Limites, Cotas e Audit

O serviço Identity and Access Management (IAM) fornece recursos para o gerenciamento de identidades e o controle de acesso aos recursos que você cria e gerencia no OCI.

• Gerenciamento de Identidades

  • Envolve a administração de usuários, senhas e grupos.

• Controle de Acesso

  • Refere-se às políticas de acesso que definem e concedem autorizações, determinando quem pode acessar quais recursos e em que nível.

Toda ação realizada sobre qualquer recurso no OCI, deve ser iniciada por um usuário válido que consiga se autenticar. Este é o primeiro passo no processo de concessão de acesso. Após uma autenticação bem-sucedida, o OCI verifica se o usuário possui a autorização necessária para executar a ação solicitada.

Esse conjunto de processos, que começa com a verificação da autenticação e passa pela checagem de autorização, é gerenciado pelo serviço IAM.

Em resumo, o IAM assegura que apenas usuários autenticados e autorizados possam interagir com recursos específicos, garantindo a segurança e a integridade do seu ambiente no OCI.

Iniciaremos com uma explicação sobre o gerenciamento de identidades, abordando usuários e grupos. Em seguida, discutiremos o processo de autorização ou controle de acesso e, por último, exploraremos o que são Limites do Serviço e Cotas de Compartimento.

3.6.1 Gerenciamento de Identidades

Cada ação realizada nos recursos do OCI, que incluem os recursos do seu Tenancy, deve ser executada por um usuário nomeado e válido, independentemente de ser através do Web Console, OCI CLI ou SDK.

O gerenciamento de identidades no OCI é feito através de dois recursos:

• Contas de Usuários

  • Uma conta de usuário é uma entidade que representa uma pessoa ou um serviço que pode interagir com os recursos do OCI.

• Grupos de Usuários

  • Um grupo de usuários é uma coleção de contas de usuários que compartilham as mesmas permissões e políticas de acesso.

Iniciaremos a explicação sobre o Gerenciamento de Identidades através do usuário Administrador do Tenancy. Em seguida, abordaremos o processo de criação de usuários e grupos.

Usuário Administrador

Toda conta criada no OCI possui, por padrão, um usuário administrador. Além de ter acesso total ao Tenancy, este é o primeiro usuário do IAM criado após a ativação da conta, sendo responsável por configurar todos os demais usuários.

O usuário administrador pertence automaticamente ao grupo Administrators. Você não pode excluir esse grupo, e deve sempre haver pelo menos um usuário contido nele.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

$ oci iam group list --name "Administrators"
{
  "data": [
    {
      "compartment-id": "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "defined-tags": {},
      "description": "Administrators",
      "freeform-tags": {},
      "id": "ocid1.group.oc1..aaaaaaaaqqqqqzzzzzyyyyyyyyxxxxxx",
      "inactive-status": null,
      "lifecycle-state": "ACTIVE",
      "name": "Administrators",
      "time-created": "2024-09-16T19:11:12.670000+00:00"
    }
  ]
}

Apenas para registrar, e abordaremos isso mais adiante, o acesso total ao Tenancy para o grupo Administrators é concedido por meio de uma Policy chamada "Tenant Admin Policy". Essa Policy pode ser consultada utilizando o comando abaixo:

1
2
3
4
5
6
7
8
9

$ oci iam policy list \
> --compartment-id "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --name "Tenant Admin Policy" \
> --query 'data[].statements'
[
  [
    "ALLOW GROUP Administrators to manage all-resources IN TENANCY"
  ]
]

Criando Usuários

O comando abaixo é utilizado para criar um novo usuário com o nome de login fulano.beltrano:

1
2
3
4
5

$ oci iam user create \
> --name "fulano.beltrano" \
> --email "fbeltrano@sem-dominio.br" \
> --description "Usuário Fulano Beltrano da equipe de Redes." \
> --wait-for-state "ACTIVE"

O parâmetro --email permite especificar o endereço de e-mail do usuário, que deve ser exclusivo entre todos os usuários do Tenancy. Uma das principais funções desse endereço de e-mail é facilitar ações de recuperação de senha, por exemplo.

Para definir uma senha para o usuário, que será utilizada para acessar o OCI por meio da Web Console, é necessário primeiro obter o OCID do usuário utilizando o seguinte comando:

1
2
3
4

$ oci iam user list --name "fulano.beltrano" --query "data[].id"
[
  "ocid1.user.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
]

Com o OCID do usuário, é possível definir uma nova senha, seja para um novo acesso ou em caso de perda da senha anterior:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

$ oci iam user ui-password create-or-reset \
> --user-id "ocid1.user.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
{
  "data": {
    "inactive-status": null,
    "lifecycle-state": "ACTIVE",
    "password": "EbvyTY9r8Zl6",
    "time-created": "2025-03-28T16:44:40.393000+00:00",
    "user-id": "ocid1.user.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
  },
  "etag": "518161f35e8944e8a28c923c4a8bb7b5"
}

Observe que a senha, presente na chave "password", foi gerada automaticamente pelo OCI.

Criando Grupos

O acesso aos diversos recursos do OCI é concedido a grupos, e não a usuários individuais. Isso significa que, como administrador, você deve autorizar um grupo de usuários em vez de conceder permissões a cada usuário individual.

Um grupo é uma coleção de usuários, e um usuário pode ser membro de mais de um grupo.

Para criar um grupo de usuários, execute o comando abaixo:

1
2
3
4

$ oci iam group create \
> --name "network-users" \
> --description "Grupo de usuários que pertencem à equipe de Redes." \
> --wait-for-state "ACTIVE"

Após a criação do grupo, é possível adicionar usuários a ele. Para isso, é necessário obter o OCID tanto do grupo quanto do usuário que será adicionado.

O comando abaixo retorna o OCID do grupo group-network recém-criado:

1
2
3
4

$ oci iam group list --name "network-users" --query "data[].id"
[
  "ocid1.group.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
]

Para adicionar o usuário fulano.beltrano ao grupo network-users, utilize o seguinte comando:

1
2
3

$ oci iam group add-user \
> --group-id "ocid1.group.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --user-id "ocid1.user.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

O comando abaixo exibe a lista de usuários que são membros do grupo network-users:

1
2
3
4
5
6
7

$ oci iam group list-users \
> --group-id "ocid1.group.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --all \
> --query "data[].name"
[
  "fulano.beltrano"
]

Grupos de Usuários da Aplicação OCI PIZZA

O script scripts/capitulo-2/group.sh contido no repositório "ocipizza-iac", inclui todos os comandos necessários para a criação dos Grupos de Usuários utilizados pela aplicação OCI PIZZA.

3.6.2 Controle de Acesso

Toda interação com as APIs do OCI exige uma autorização explícita. Isso significa que, por exemplo, para que um usuário possa criar uma VCN, após se autenticar com sucesso, ele deve ter as permissões adequadas para realizar essa ação.

A concessão de acesso ou autorização no OCI é realizada por meio de dois recursos principais, que são:

• Compartimentos

  • São unidades de organização que permitem agrupar e isolar recursos, facilitando a gestão e o controle de acesso.

• Políticas de Acesso

  • São regras que definem permissões e controlam o acesso aos recursos.

Uma boa prática é iniciar o "desenho do processo de autorização" com as definições dos compartimentos. Após a criação dos compartimentos, é necessário criar as políticas de acesso para permitir que um grupo de usuários crie e gerencie os recursos contidos em cada compartimento específico.

Compartimentos

Compartimentos, ou Compartments, são uma estrutura lógica que permite organizar e isolar os recursos que você cria no OCI. Utilizar compartimentos facilita o gerenciamento desses recursos e proporciona uma camada adicional de proteção contra acessos não autorizados.

Toda conta no OCI possui um Root Compartment ou Tenancy Compartment, que é criado automaticamente após a ativação da conta. Isso se deve ao fato de que todos os recursos que você cria, deve ser colocado dentro de um compartimento. Em outras palavras, cada recurso deve pertencer a um único compartimento.

O nome do Root Compartment corresponde ao nome da conta que foi especificado durante o processo de cadastro (ocipizza). Você pode obter o seu OCID utilizando o comando abaixo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$ oci iam compartment list \
> --include-root \
> --all \
> --name "ocipizza" \
> --query 'data[*].[name,id]'
[
  [
    "ocipizza",
    "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
  ]
]

Entenda o Root ou Tenancy Compartment, como se fosse o "contêiner pai" que abriga todos os seus recursos no OCI, incluindo os recursos de outros compartimento.

A Web Console filtra a exibição dos seus recursos por compartimento dentro da região, e você deve selecionar o compartimento em que deseja trabalhar a partir de uma lista.

Os compartimento são recursos globais e, uma vez criados, estarão disponíveis em todas as regiões inscritas.

Por fim, é possível criar até seis subcompartimentos dentro de um compartimento, e a maioria dos recursos pode ser movida entre compartimentos.

Compartimentos da Aplicação OCI PIZZA

Para ilustrar melhor o uso de Compartimento, imagine diferentes grupos de profissionais de TI colaborando no desenvolvimento da aplicação OCI PIZZA. Esses grupos incluem:

• REDES

  • Grupo de pessoas responsáveis pela criação e gerenciamento dos recursos de rede no OCI.

• APLICAÇÃO

  • Grupo de pessoas responsáveis pela criação e gerenciamento de recursos de computação, bem como pela implantação da aplicação.

• DBA

  • Grupo de pessoas responsáveis pela criação e gerenciamento dos Bancos de Dados.

A separação de funções por tipo de profissional é uma prática comum que garante que cada equipe tenha acesso somente aos recursos necessários para desempenhar suas atividades. Por exemplo, os profissionais da equipe de REDES terão permissão apenas para gerenciar recursos de rede, como VCNs, sub-redes, VPNs Site-To-Site, etc.

Por outro lado, os profissionais de APLICAÇÃO terão acesso somente aos recursos de computação, como Compute Instances, Container Instances, Kubernetes Engine (OKE), etc.

Da mesma forma, os profissionais DBA terão acesso somente aos recursos de bancos de dados, como o Oracle NoSQL.

Além da separação por grupos de usuários, outra forma de organizar os recursos é através da distinção por "ambientes", como Produção (PRD), Homologação (HML) e Desenvolvimento (DEV).

Com base nessas definições, temos a seguinte estrutura de compartimento e subcompartimentos (child compartments) para o ambiente de produção (prd):

A partir do desenho, é possível observar que o grupo de usuários de redes (group-network) terá autorização para criar recursos de rede exclusivamente no compartimento cmp-network. Outros grupos de usuários, como o de aplicação (group-appl) e o de DBA (group-dba), também terão permissões restritas aos seus respectivos compartimentos (cmp-appl e cmp-database). Por fim, o grupo Administrators tem acesso total a todos os compartimentos.

Para criar um compartimento, utilize o seguinte comando:

1
2
3
4
5

$ oci iam compartment create \
> --compartment-id "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --name "cmp-prd" \
> --description "Compartimento para os recursos de produção (cmp-prd)." \
> --wait-for-state "ACTIVE"

Após a criação do compartimento, obteremos seu OCID que será utilizado na criação do próximo compartimentos, estabelecendo assim a hierarquia de compartimentos, igual ao que foi apresentado na imagem anterior.

1
2
3
4
5
6

$ oci iam compartment list \
> --name "cmp-prd" \
> --query "data[].id"
[
  "ocid1.compartment.oc1..aaaaaavvvvvvvddddddddddd"
]

Com o OCID do compartimento do ambiente de produção (prd), prosseguimos para a criação do próximo compartimento, que é o cmp-network:

1
2
3
4
5

$ oci iam compartment create \
> --compartment-id "ocid1.compartment.oc1..aaaaaavvvvvvvddddddddddd" \
> --name "cmp-network" \
> --description "Compartimento para os recursos de redes do ambiente de produção." \
> --wait-for-state "ACTIVE"

A criação dos demais compartimentos seguem a mesma lógica e não serão apresentados aqui.

O script scripts/capitulo-2/compartment.sh contido no repositório "ocipizza-iac", inclui todos os comandos para a criação dos compartimentos da aplicação OCI PIZZA.

• TODO: os exemplos do livro utilizam o compartimento de produção apenas.

Políticas de Acesso

Uma Política de Acesso, Política ou Policy, é um documento que contém uma ou mais declarações destinadas a conceder acesso e autorizar, um grupo de usuários, em gerenciar determinado serviço ou recurso do OCI. A Policy permite especificar permissões em nível de compartimento ou para todo o Tenancy.

A concessão de acesso é feita a um grupo de usuários ou a um serviço, e não a um usuário específico. Além disso, todo grupo de usuários que é criado não possui nenhuma permissão de acesso, a menos que uma Policy tenha sido previamente definida. É responsabilidade do administrador do Tenancy conceder permissões ao grupo ou serviço por meio de uma ou mais policies.

Basicamente, a sintaxe geral da Policy possui o seguinte formato:

Policies sempre começam com a palavra Allow. Isso significa que as Policies que você cria apenas concedem ou autorizam acesso, não podendo negá-lo, uma vez que, por padrão, tudo já é negado.

Abaixo está o significado de cada uma das partes em destaque que compõem uma Policy:

Assunto

O elemento assunto pode especificar um Grupo de Usuários, Grupo Dinâmico ou serviços do OCI, utilizando uma das seguintes formas:

• group

  • Nome do Grupo de Usuários no qual o acesso será concedido.

• group id

  • OCID do Grupo de Usuários no qual o acesso será concedido.

• dynamic-group

  • Nome do Grupo Dinâmico no qual o acesso será concedido.

• dynamic-group id

  • OCID do Grupo Dinâmico no qual o acesso será concedido.

• service

  • Especifica o nome do serviço OCI no qual o acesso será concedido.

• any-group

  • Indica todos os Grupos de Usuários e Grupos Dinâmico do Tenancy.

Há também a sintaxe <Nome do Domínio de Identidade>/<Nome do Grupo> que pode ser utilizada para se referir a um Grupo de Usuários existente em um Domínio de Identidade que não é o Default.

Verbo

O elemento verbo especifica o tipo de acesso que será concedido em relação as operações que podem ser feitas em uma determinada API de um determinado serviço. Seus valores incluem:

• inspect

  • Concede a autorização para listar recursos.

• read

  • Inclui as permissões do verbo inspect mais a capacidade de obter metadados do recurso.

• use

  • Inclui as permissões do verbo read mais a capacidade de poder atualizar o recurso (operações de update). Em geral, esse verbo não inclui a capacidade de criar ou excluir um recurso.

• manage

  • Inclui todas as permissões para o recurso.

Sabemos que, para cada serviço disponibilizado pelo OCI, existem uma ou mais APIs disponíveis, e cada API oferece uma funcionalidade específica relacionada ao serviço.

Em termos de concessão de acesso, por exemplo, o verbo inspect para o serviço de Load Balancer, inclui a permissão nomeada LOAD_BALANCER_INSPECT que concede acesso às APIs ListLoadBalancers, ListShapes, ListPolicies e ListProtocols.

O objetivo dos verbos é simplificar o processo de concessão de diversas permissões relacionadas. Para facilitar a compreensão, abaixo está um exemplo da correlação entre um verbo e as permissões associadas às APIs do serviço Load Balancer:

No exemplo abaixo, a Policy escrita concede ao grupo network-users, acesso a todas as APIs do serviço que gerencia VCNs em todo o Tenancy:

Compreender a relação entre permissões e as APIs disponíveis por serviço facilita a elaboração de Policies mais granulares em termos de acesso. Veremos adiante que é possível, por exemplo, conceder acesso apenas às APIs AddVcnCidr e RemoveVcnCidr do verbo manage, sem conceder acesso às demais APIs, como CreateVcn, UpdateVcn ou DeleteVcn.

Tipo do Recurso

O elemento tipo do recurso refere-se a um recurso específico ou a uma família de recursos.

Por exemplo, a família de recursos virtual-network-family abrange vários recursos específicos relacionados a VCN, como vcns, subnets, route-tables, security-lists, entre outros. Nesse contexto, vcns e subnets correspondem a recursos específicos, como VCNs e Sub-rede.

Trabalhar com um recurso específico ou uma família de recursos proporciona a flexibilidade de definir exatamente quais recursos terão acesso concedido.

Há também o tipo all-resources, que pode ser usado para fazer referência a todos os recursos do Tenancy.

Local

O elemento local especifica o Compartimento ou Tenancy no qual a Policy concede acesso. Em outras palavras, ele define o escopo do acesso, que pode ser um compartimento específico ou todo o Tenancy.

Os seguintes valores que podem ser usados para o elemento local são:

• tenancy

  • Abrange todos os recursos do Tenancy.

• compartment

  • Usado para especificar o nome do compartimento onde a policy será aplicada. Se houver subcompartimentos abaixo do compartimento especificado, a policy se aplicará a todos os compartimentos a partir do nível mais alto da hierarquia.

• compartment id

  • Usado para especificar o OCID do compartimento onde a policy será aplicada.

Valores válidos para o elemento local também podem incluír um compartimento específico dentro de uma hierarquia de compartimentos:

Para compartment id, é possível utilizar apenas um valor OCID de um compartimento específico. Não é permitido fazer referência a uma hierarquia de compartimentos.

Condição

O elemento condição e é opcional e pode ser usado para restringir o escopo das permissões concedidas em uma política.

Uma condição é escrita utilizando a cláusula where, seguida de uma comparação que pode ser simples (uma única condição) ou que pode abranger múltiplas condições.

O exemplo abaixo demonstra a utilização de uma condição simples que usa o operador de negação != para excluír somente a permissão VCN_DELETE do grupo network-users. Com isso, os usuários desse grupo podem criar VCNs, listar ou atualizar suas informações, mas não têm permissão para excluir uma VCN.

Além de request.permission é possível utilizar request.operation para fazer referência a uma operação específica da API:

As condições podem ser agrupadas entre chaves na forma { condição-1, condição-2 } para avaliação. Para criar um OR lógico entre um conjunto de condições, utilize a palavra any. Para estabelecer um AND lógico entre um conjunto de condições, utilize all.

A policy de exemplo abaixo utiliza o operador any para criar um OR lógico, limitando o acesso do grupo network-users às operações de APIs AddVcnCidr ou RemoveVcnCidr.

Uma política de acesso pode ser criada da seguinte forma, utilizando o OCI CLI:

1
2
3
4
5
6
7
8
9

$ oci iam policy create \
> --compartment-id "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --name "network-users-policy" \
> --description "Políticas de Acesso para o Grupo network-users." \
> --statements "[
> 'Allow group network-users to manage virtual-network-family in compartment cmp-prd:cmp-network',
> 'Allow group network-users to manage virtual-network-family in compartment cmp-hml:cmp-network',
> 'Allow group network-users to manage virtual-network-family in compartment cmp-dev:cmp-network']" \
> --wait-for-state "ACTIVE"

As Políticas de Acesso da Aplicação OCI PIZZA

O script scripts/capitulo-2/policy.sh contido no repositório "ocipizza-iac", inclui todas as políticas de acesso utilizadas pela aplicação OCI PIZZA.

3.6.3 Grupos Dinâmicos

Os Grupos Dinâmicos são um tipo especial de grupo projetado para agrupar recursos, em vez de usuários.

A finalidade dos Grupos dinâmicos é conceder acesso às APIs do OCI a uma instância de computação ou recurso, que podem incluir não apenas servidores virtuais, mas também servidores que fazem parte de um cluster Kubernetes (OKE) ou um Container Instances, por exemplo.

Uma vez que o Grupos Dinâmicos foi criado, também é necessário criar uma política de acesso para autorizar esse grupo a interagir com uma ou mais APIs do OCI. É importante destacar que os Grupos Dinâmicos inclui como membro um recurso específico, e o acesso concedido a esse recurso, conforme definido na política de acesso, permitirá que ele crie e gerencie outros recursos no OCI.

A definição de um recurso que faz parte do Grupo Dinâmico é feita através de um conjunto de regras de correspondência que especificam recursos através do uso das seguintes variáveis:

• instance.compartment.id

  • Especifica o compartimento onde a instância de computação reside.

• instance.id

  • Especifica o OCID da instância de computação.

• tag.<tagnamespace>.<tagkey>.value

  • Especifica o namespace da tag e a chave da tag que podem fazer referência a uma ou mais instâncias de computação no qual incluem as informações da tag especificada.

• tag.<tagnamespace>.<tagkey>.value='<tagvalue>'

  • Especifica além do namespace da tag e a chave da tag, é possível fazer referência ao valor que uma tag específica possui.

• resource.compartment.id

  • Especifica o compartimento onde o recurso reside.

• resource.id

  • Especifica o OCID do recurso.

• resource.type

  • Especifica o tipo do recurso.

Os operadores lógicos any (OR) e all (AND) podem ser utilizados para criar regras de correspondência em um Grupo Dinâmico.

Por exemplo, a imagem abaixo ilustra uma regra de correspondência de um Grupo Dinâmico instances-dyngrp, que incluem as instâncias de computação de um compartimento específico (instance.compartment.id) ou (OR lógico), uma única instância (instance.id):

A partir do Grupo Dinâmico que foi definido, podemos escrever uma policy que concede acesso total aos objetos do serviço Object Storage dentro do compartimento especificado:

Em resumo, neste exemplo, a definição do Grupo Dinâmico e da policy associada permitem que qualquer instância de computação dentro do compartimento especificado, ou a instância identificada pelo seu OCID, manipule objetos do serviço Object Storage que estão armazenados no compartimento cmp-prd:cmp-appl.

Para criar um Grupo Dinâmico através do OCI CLI, utilize como exemplo o seguinte comando:

1
2
3
4
5
6
7

$ oci iam dynamic-group create \
> --name "instances-dyngrp" \
> --description "Grupo dinâmico das instâncias de computação que usam o Object Storage." \
> --matching-rule "any {
> instance.compartment.id = 'ocid1.compartment.oc1..aaaaaavvvvvvvddddddddddd', 
> instance.id = 'ocid1.instance.oc1.sa-saopaulo-1.acccccvvvbbbbbbbbbbb'}" \
> --wait-for-state "ACTIVE"

Grupos Dinâmicos da Aplicação OCI PIZZA

O script scripts/capitulo-2/dynamic-group.sh contido no repositório "ocipizza-iac", inclui os Grupos Dinâmicos utilizadas pela aplicação OCI PIZZA.

3.6.4 Limites e Cotas

Limites

Após a ativação da sua conta, o OCI estabelece um conjunto de limites para os recursos que você pode criar. Esses limites referem-se à quantidade máxima de recursos permitidos em seu Tenancy, e cada recurso ou serviço possui um limite específico.

Por exemplo, o OCI estabelece um limite inicial de criação de até seis Container Instances em todo o Tenancy, para contas que utilizam o modelo de cobrança Pay As You Go ou Trial (contas para avaliação). Em contrapartida, para contas que operam sob o modelo Oracle Universal Credits, o limite inicial é de até dois mil Container Instances.

Para consultar o limite de um serviço específico utilizando o OCI CLI, é necessário, primeiramente, ter em mãos o "Nome do Serviço", conforme demonstrado no comando a seguir:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

$ oci limits service list \
> --compartment-id "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --all \
> --query 'data[*].{"Descrição do Serviço": description, "Nome do Serviço": name}' \
> --output table
+---------------------------------------+-----------------------------+
| Descrição do Serviço                  | Nome do Serviço             |
+---------------------------------------+-----------------------------+
| Application Dependency Management     | adm                         |
| Access Governance                     | agcs                        |
| AI Anomaly Detection                  | ai-anomaly-detection        |
| AI Document                           | ai-document                 |
| AI Forecasting                        | ai-forecasting              |
| Generative AI                         | ai-generative               |
| AI Language                           | ai-language                 |
| AI Speech                             | ai-speech                   |
| AI Vision                             | ai-vision                   |
| Analytics                             | analytics                   |
| Announcements                         | announcements               |
| API Gateway                           | api-gateway                 |
| Application Performance Monitoring    | apm                         |
| Application Configuration             | app-configuration           |
| Account Tracking and Automation Tools | atat                        |
| Auto Scaling                          | auto-scaling                |
| Autonomous Recovery Service           | autonomous-recovery-service |
| Big Data                              | big-data                    |

Uma vez que você tenha o nome do serviço, é possível consultar os limites associados a ele:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

$ oci limits value list \
> --compartment-id "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --all \
> --service-name "vpn"
{
  "data": [
    {
      "availability-domain": null,
      "name": "cpe-count",
      "scope-type": "REGION",
      "value": 10
    },
    {
      "availability-domain": null,
      "name": "ipsec-connection-count",
      "scope-type": "REGION",
      "value": 4
    }
  ]
}

Neste caso, para o serviço de VPN que foi consultado, existem dois limites aplicáveis:

• cpe-count

  • Este limite indica que você pode ter até dez Customer Premises Equipment (CPE) em uma região específica. O CPE é um dispositivo que conecta sua rede local à rede do OCI, permitindo a comunicação entre os dois ambientes.

• ipsec-connection-count

  • Este limite especifica que você pode ter até quatro conexões IPSec em uma região. As conexões IPSec são usadas para estabelecer uma conexão segura entre sua rede local e o OCI, utilizando criptografia para proteger os dados transmitidos.

Solicitando Aumento dos Limites

Para solicitar aumento de limites para qualquer serviço do OCI, utilize a opção "Request a limit increase" da Web Console conforme demonstrado na figura abaixo:

Após isso, você será direcionado para um assistente virtual, onde deverá clicar no botão "Limit Increase" em duas telas consecutivas:

Um formulário será exibido, onde você deverá selecionar a categoria do serviço (Service Category), o recurso ou item relacionado ao serviço (Resource), o novo limite desejado para a região (sa-saopaulo-1 Region Limit), e fornecer uma justificativa (Reason for request). Em seguida, basta clicar no botão "Create Support Request":

Essa ação criará uma solicitação para a equipe do OCI, que, após análise, irá efetivar o novo valor solicitado. Toda a comunicação será realizada por meio do e-mail cadastrado do usuário que está solicitando o aumento do limite.

Cotas

Cotas ou Cotas de Compartimento são utilizadas para controlar a quantidade de recursos que podem ser criados dentro de um compartimento. As cotas de compartimento são semelhantes aos limites do serviço, mas a principal diferença é que os limites do serviço são estabelecidos pela Oracle, enquanto as cotas de compartimento são definidas pelos administradores do Tenancy ou por qualquer outro usuário que possua privilégios adequados.

De forma prática, você pode definir, por meio de cotas, o número máximo de Container Instances que podem ser criadas no compartimento cmp-appl, por exemplo. Isso permite um controle eficaz sobre a utilização dos recursos dentro de um compartimento.

Para definir cotas, utiliza-se uma linguagem declarativa própria, semelhante à utilizada nas políticas de acesso. Essa linguagem inclui três tipos de instruções que podem ser usadas. São elas:

• zero

  • Redefine todos os limites de cota de um recurso para zero.

• unset

  • Redefine as cotas de volta para os limites do serviço padrão.

• set

  • Define um número máximo de recursos que podem ser criados.

Por exemplo, o seguinte comando pode ser utilizado para restringir a criação de até oito Container Instances com processadores do tipo E4 nas regiões sa-saopaulo-1 ou sa-vinhedo-1:

1
2
3
4
5
6
7
8

$ oci limits quota create \
> --compartment-id ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --name "container-instance-quota" \
> --description "Cotas para os serviços Compute Instances e Container Instances." \
> --statements "[
> 'zero compute-core quota in tenancy', 
> 'set compute-core quota standard-e4-core-count to 8 in tenancy where any {request.region = sa-saopaulo-1, request.region = sa-vinhedo-1}']" \
> --wait-for-state "ACTIVE"

Observe que, para aplicar a cota de forma eficaz, inicialmente zeramos o limite utilizando a instrução zero. Em seguida, com a instrução set, definimos o valor do limite para um item específico, que neste caso é a CPU do tipo E4, identificada como standard-e4-core-count, pertencente à família do serviço compute-core.

Cotas da Aplicação OCI PIZZA

O script scripts/capitulo-2/quotas.sh contido no repositório "ocipizza-iac", contém as cotas utilizadas pela aplicação OCI PIZZA.

3.6.5 Gerenciamento de Regiões

Um Tenancy dentro do modelo de cobrança Pay As You Go ou Free Tier é restrito a uma única região. Isso significa que, para utilizar outra região, você precisará solicitar uma inscrição para essa nova região.

O comando abaixo solicita a inscrição na região "Sudeste do Brasil (Vinhedo)":

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$ oci iam region-subscription create \
> --tenancy-id "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --region-key "VCP"
{
  "data": {
    "is-home-region": false,
    "region-key": "VCP",
    "region-name": "sa-vinhedo-1",
    "status": "IN_PROGRESS"
  }
}

Observe que a região é especificada por meio de sua chave, que neste caso é VCP.

Após alguns minutos, você poderá verificar que a região solicitada já está disponível para uso (STATUS: READY):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$ oci iam region-subscription list \
> --tenancy-id "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --all \
> --query 'data[*].{"Nome da Região": "region-name", "Chave da Região": "region-key", "Status": status}' \
> --output table
+-----------------+----------------+--------+
| Chave da Região | Nome da Região | Status |
+-----------------+----------------+--------+
| GRU             | sa-saopaulo-1  | READY  |
| VCP             | sa-vinhedo-1   | READY  |
+-----------------+----------------+--------+

3.6.6 Serviço Audit

O Serviço Audit registra automaticamente todas as chamadas e ações realizadas nas APIs do OCI, proporcionando um histórico detalhado das operações executadas em sua conta.

Os eventos de log registrados pelo Serviço Audit incluem todas as chamadas feitas as APIs do OCI, seja através do Web Console, OCI CLI, SDK ou qualquer outra forma personalizada de interação com as APIs REST do OCI. Esses dados de eventos podem ser utilizados para realizar diagnósticos e monitorar atividades relacionadas à criação, exclusão ou modificação de qualquer recurso em seu Tenancy.

Para ilustrar melhor o uso do Audit, imagine que você deseja descobrir quem excluiu uma determinada VCN do seu Tenancy. Como o Serviço Audit fornece informações sobre as interações realizadas com as APIs do OCI, o primeiro passo é identificar o nome da ação que o Serviço de Redes utiliza para excluir uma VCN.

Os nomes das ações disponíveis para operações relacionadas a uma VCN podem ser encontrados diretamente na documentação "API Reference and Endpoints":

A maneira mais simples de visualizar os eventos registrados pelo Serviço Audit é através do Web Console. Para isso, acesse o "menu de hambúrguer" e navegue até "Identity & Security > Audit".

Depois de identificar o nome da ação (DeleteVcn), insira-o no campo Keywords do serviço Audit. Como o serviço registra todas as interações com as APIs, você encontrará uma vasta quantidade de registros a serem analisados. Para este exemplo, vamos filtrar apenas as ocorrências do método HTTP DELETE, definindo um intervalo de datas e horários de início e fim mais restrito:

Para cada resultado exibido, há um conjunto de informações que permite identificar o usuário que realizou a ação DeleteVcn:

É possível também obter os eventos pelo OCI CLI porém como já mencionado aqui, para consultas simples é mais fácil e prático consultar os dados pela Web Console.

O comando abaixo lista todos os eventos dentro do intervalo de tempo especificado pelos parâmetros --start-time e --end-time:

1
2
3
4
5

$ oci audit event list \
> --compartment-id "ocid1.tenancy.oc1..aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" \
> --start-time "2025-04-04T10:00Z" \
> --end-time "2025-04-04T11:00Z" \
> --all

Para o comando exibido, existe a opção --stream-output, que redireciona todo o resultado para o stdout. Como normalmente há uma grande quantidade de informações e eventos, essa opção é útil para direcionar o fluxo de dados para um stream, que pode, por exemplo, encaminhar as informações para um Serviço Analytics usado para processar e visualizar os dados de forma mais eficaz.