Cenário
Recentemente, durante a execução de uma demanda interna, um membro do time precisou provisionar um Private Endpoint para OCI Object Storage via Terraform. Para nossa surpresa, a documentação oficial do Terraform Registry ainda não oferece suporte para esse recurso. Isso pode acontecer quando trabalhamos com recursos recém-lançados.
Então surgiu a seguinte dúvida, é possível realizar o provisionamento via Terraform mesmo quando o recurso ainda não aparece no Terraform Registry oficial?
Ao final deste artigo, vamos descobrir se é realmente possível realizar esse tipo de provisionamento mesmo sem o suporte explícito no Terraform Registry.
O que é um Private Endpoint para Object Storage?
Lançado há alguns meses, o recurso Private Endpoints permite acesso seguro ao Object Storage a partir de redes privadas em sua virtual cloud network (VCN) ou até mesmo de ambientes on-premises. Funcionam como uma VNIC com IP privado, configurada em uma sub-rede de sua escolha.
Essa abordagem é uma alternativa ao uso de Service Gateways, evitando o tráfego por IPs públicos.
Importante: Criar um Private Endpoint em uma VCN e associá-lo a um bucket não impede automaticamente o acesso ao bucket pela internet ou de outras redes. Para restringir o acesso corretamente, você deve configurar políticas IAM para o bucket, autorizando apenas requisições que se originam de uma VCN específica ou de um bloco CIDR dentro dela.
OCI Terraform Provider
O OCI Terraform Provider é mantido pela Oracle e está disponível publicamente no repositório oficial da Oracle no GitHub e, apesar de o recurso Private Endpoint não aparecer no Terraform Registry, ele está implementado no código-fonte do provedor da Oracle como oci_objectstorage_private_endpoint especificamente no arquivo objectstorage_private_endpoint_resource.go.
Terraform Resource oci_objectstorage_private_endpoint
Ao analisar o arquivo objectstorage_private_endpoint_resource.go, encontramos a implementação interna do recurso responsável por criar Private Endpoints para o Object Storage em OCI.
Veja abaixo como estruturamos o terraform resource, separando os campos obrigatórios e opcionais para facilitar a reutilização em diferentes contextos.

Atributos obrigatórios:
- compartment_id: Identificador do compartimento onde o Private Endpoint será criado. Neste exemplo, é resolvido dinamicamente com base no nome (compartment_name).
- name: Nome do recurso de Private Endpoint. É usado para identificação na Console da OCI.
- namespace: Namespace do Object Storage. É único por tenancy e está sendo capturado dinamicamente via data source.
- subnet_id: Sub-rede onde a VNIC do endpoint será provisionada.
- prefix: Prefixo usado na resolução de nomes DNS do Private Endpoint. É obrigatório para formar o domínio privado que será resolvido via VCN.
- access_targets: Define os buckets aos quais esse endpoint terá acesso. Cada bloco precisa de:
- namespace: Namespace do bucket alvo, está sendo capturado dinamicamente via data source.
- compartment_id: Compartimento onde o bucket está localizado. Neste exemplo, é resolvido dinamicamente com base no nome (compartment_name).
- bucket: Nome do bucket.
Atributos opcionais:
- private_endpoint_ip: Permite definir um IP para o endpoint. Se omitido, a OCI alocará automaticamente um IP da subnet.
- nsg_ids: Lista de NSGs (Network Security Groups) a serem associados à VNIC. Útil para aplicar regras de firewall específicas ao endpoint.
- additional_prefixes: Permite registrar nomes DNS adicionais associados ao endpoint. Ideal quando você precisa acessar o Object Storage usando domínios personalizados.
- defined_tags: Tags definidas para controle de recursos e custo. Boa prática para organização e governança.
O bloco abaixo mostra a variável private_endpoint_config, que centraliza a definição dos parâmetros utilizados no provisionamento do Private Endpoint. Essa estrutura facilita a criação de múltiplos endpoints de forma dinâmica e reutilizável, permitindo configurar tanto os atributos obrigatórios quanto os opcionais de forma organizada e escalável.

Durante a execução do terraform plan, podemos verificar que o recurso oci_objectstorage_private_endpoint com a configuração correta e pronto para ser provisionado.

Em seguida, ao executar o terraform apply, o Private Endpoint foi provisionado com sucesso, confirmando que a estrutura definida está funcional e compatível com o provedor OCI.

Após a execução bem-sucedida do terraform apply, podemos visualizar o Private Endpoint provisionado na console da OCI, confirmando que o recurso foi criado corretamente e está pronto para uso.

Código Terraform
O módulo Terraform completo utilizado neste exemplo está disponível publicamente no GitHub, no repositório: os-private-endpoint-terraform. Este repositório contém um arquivo README.md com todas as instruções necessárias para provisionar o Private endpoint via Terraform.
Considerações Finais
Conforme questionado no início deste artigo, se é possível provisionar um recurso via Terraform mesmo que ele ainda não esteja documentado no Terraform Registry.
A resposta é: Sim, é possível, desde que o recurso já esteja implementado no código-fonte do provider oficial.
No caso do Private Endpoint, mesmo sem documentação disponível no Registry, conseguimos identificá-lo no repositório oficial da Oracle no GitHub e, a partir do código-fonte, estruturamos com sucesso a configuração Terraform para provisioná-lo.
Esse cenário mostra como o acesso ao código aberto do provider é uma poderosa ferramenta para antecipar o uso de novos recursos, contornar limitações temporárias de documentação e garantir agilidade na adoção de funcionalidades recém-lançadas.
Importante: O recurso ainda não está totalmente documentado oficialmente, então podem existir comportamentos inesperados ou bugs que ainda não foram reportados. Embora não tenhamos enfrentado problemas durante nossos testes, é importante redobrar a atenção ao utilizá-lo em ambientes de produção.
