Access private resources from OCI Resource Manager using Private Endpoint Management
The Private Endpoint Management feature enables access to private cloud resources on Oracle Cloud Infrastructure (OCI) or on-premises (connected to an OCI tenancy) from OCI Resource Manager.
Resource Manager is an OCI service that allows you to automate the process of provisioning your Oracle Cloud Infrastructure resources. Using Terraform, Resource Manager helps you install, configure, and manage resources through the "infrastructure-as-code" model.
- Connect to private resources in a private network (VCN) via remote-exec, including compute and DB instances, as part of Terraform apply.
- Connect to private Git servers such as GitHub and GitLab in a
private network (VCN) to retrieve terraform configurations required to configure
stack resources.
For example, you can configure a private compute instance using Terraform's remote exec functionality and access Terraform configurations in a private GitHub server.
- Remotely execute scripts from the Resource Manager during job execution without exposing resources to the public internet.
Architecture
This reference architecture describes and provides automation to deploy and leverage private endpoint access from the OCI Resource Manager and execute certain commands on compute instances hosted in a private subnet.
This reference architecture provides a Terraform based solution which creates all the necessary resources (VCN, Instance, Private Endpoint) and validates the Private Endpoint connectivity using remote execution.
The automation is embedded with the OCI Terraform provider. The code creates a VCN. In the VCN, it creates a private subnet to host the instance. The instance is created and launched under the private subnet. A set of security rules are defined on the subnet to ensure that it allows remote-exec calls via a Private Endpoint.
The automation creates Private Endpoint resources for the tenancy within the VCN private subnet. It also adds the user into a user group and defines policies on top of the user group to provide the necessary access to the VCN and Private Endpoint.
Finally, it does a remote execution on the instances that are not exposed to a public network and captures the result.
The following diagram illustrates this reference architecture.
oci-orm-private-endpoint-arch-oracle.zip
The architecture has the following components:
- Resource Manager
Resource Manager is an Oracle Cloud Infrastructure service that allows you to automate the process of provisioning your Resource Manager resources. It helps you install, configure, and manage resources using the infrastructure-as-code model.
- Private Endpoint
Private Endpoint is a feature within the OCI Resource Manager with which you can access nonpublic cloud resources in your tenancy from the Resource Manager.
- Stack actions
Stack actions are the various actions that can be performed over a stack (set of Terraform code) like apply/plan/destroy.
- Stack definition
Stack definition is a set of Terraform code and a schema definition about your infrastructure.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Policy
An Oracle Cloud Infrastructure Identity and Access Management policy specifies who can access which resources, and how. Access is granted at the group and compartment level, which means you can write a policy that gives a group a specific type of access within a specific compartment, or to the tenancy.
- Virtual cloud network (VCN) and subnet
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Private subnet
Private subnets are subdivisions you define in a VCN (for example, 10.0.0.0/24, 10.0.1.0/24, or 2001:DB8::/64). Subnets contain virtual network interface cards (VNICs), which attach to instances. Private means VNICs in the subnet cannot have public IPv4 addresses and internet communication with IPv6 endpoints will be prohibited.
Recommendations
- Compute shapes
This architecture uses an Oracle Linux OS image with an E4 flex shape with minimum resources to host the instance. If your application needs more memory or cores, you can choose a different shape.
- VCN
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.
After you create a VCN, you can change, add, and remove its CIDR blocks.
This architecture uses a VCN to host OCI VM within a private subnet along with a security rule that allows only port 22 for Egress and Ingress rules.
Considerations
Consider the following points when deploying this reference architecture.
- Availability
Ensure proper resiliency and load balancing across the resources when using this architecture for production use cases.
- Cost
Refer to the cost of OCI instances and manage the usage accordingly.
- Security
The solution allows only the ssh connection to the subnet. You can alter the update according to your requirements.
Deploy
The Terraform code for this reference architecture is available as a sample stack in Oracle Cloud Infrastructure Resource Manager. You can also download the code from GitHub, and customize it to suit your specific requirements.
- Deploy using the sample stack in Oracle Cloud Infrastructure Resource
Manager:
- Click
If you aren't already signed in, enter the tenancy and user credentials.
- Select the region where you want to deploy the stack.
- Follow the on-screen prompts and instructions to create the stack.
- After creating the stack, click Terraform Actions, and select Plan.
- Wait for the job to be completed, and review the plan.
To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.
- If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
- Click
- Deploy using the Terraform code in GitHub:
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
READMEdocument.