Use Bastion service to access resources in a private subnet
Oracle Cloud Infrastructure Bastion provides private, time-bound SSH access to resources that don't have public endpoints.
Bastion is an infrastructure service that can take the place of a bastion server that you create yourself in Oracle Cloud Infrastructure (OCI). Bastions are gateways or proxies. They are logical entities that provide secured access to resources in the cloud that you cannot otherwise reach from the internet. Bastions reside in a public subnet and establish the network infrastructure needed to connect a user to a resource in a private subnet.
Integration with Oracle Cloud Infrastructure Identity and Access Management (IAM) lets you control who can manage a bastion or a session within a bastion service. Integration with Oracle Cloud Infrastructure Audit gives you a way to monitor administrative actions related to the bastion service and to bastion sessions.
Architecture
This architecture shows two ways of connecting to private subnets. One way is to connect through an intermediary target subnet, and the other way is to connect directly to the subnet that contains the protected resources.
When you create a Bastion Service, you can specify a CIDR block allowlist and a maximum session time-to-live. On bastion creation, a network path is established between the bastion VCN and the customer VCN through a reverse connection. Sessions are typically created by users or operators.
The following diagram illustrates this reference architecture.
Description of the illustration architecture-use-bastion-service.png
The architecture has the following components:
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Virtual cloud network (VCN) and subnets
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.
- Bastion Service
The bastion service exists in an OCI managed infrastructure, requiring no infrastructure management. The managed infrastructure is where the bastion public endpoint is created, allowing external clients to connect using the previously defined sessions.
- Bastion Service Backend
The Bastion Service backend stores session configuration and the SSH public keys that are used to grant access to the target systems. The target systems, when required, use the service gateway to access the Bastion Service backend.
- Private Endpoint
The private endpoint connects the Bastion Service to the target subnets. The target subnet can be a separate subnet, for a more granular control, or on the same subnet of the instances that you want to access
Recommendations
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
- 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.
Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
After you create a VCN, you can change, add, and remove its CIDR blocks.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
Use regional subnets.
Note that every bastion provisioned takes two IP addresses from the target subnet. Choose the CIDR block based on how many bastions you want to provision against a particular subnet. For example, if you have a subnet with /30 CIDR, it means that you have two usable addresses and if within that CIDR, you have a target resource, then you don't have enough addresses to provision a bastion. In this case, the bastion provisioning will fail. We would recommend the target subnet to be wider than /29.
- Security
Use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure proactively. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any mis-configuration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.
For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe and denies operations that violate any of the policies.
- OCI Bastion
TTL at the bastion level will ensure that none of the sessions created in the context of that bastion would have TTL more than the bastion. You should set the TTL to the minimum limit as per your use case. The min is 30 mins and the max is 3 hours. The TTL is also configurable at the session level.
Allow list CIDR block should be as narrow as possible as per your scenario. With this, you can restrict the IP address ranges from where the SSH connections are allowed to the private target resources.
The size of the target subnet to which a bastion is created should be thought through. Each bastion creation takes 2 IP addresses. So, it is better to have /29 range at least so that it has 6 usable IP addresses. /30 would have 2 IP addresses but if in the future you want the second instance of the bastion to point to the same subnet, you won't be able to create it. Please remember, the target subnet can either be the subnet where your target resource is present or from where other subnets in the target VCN can allow traffic from.
Security policies recommendations
- The ingress rules on the subnet which has the target resources should allow the incoming TCP traffic from just one IP address which is the private endpoint IP of the bastion.
- Specify the exact port on a destination like 22 for Linux, 3389 for windows, 33060 for MySql, and so on. Refrain from using ALL for ports.
Use specific IAM policies for admin and operator scenarios.
Considerations
- Region
Bastion is a regional service. For example, the customers would need to create a bastion in PHX to access resources in PHX. A bastion within PHX can't be used to access resources in IAD, for example.
- Performance
Bastion creation should be within the SLO (2 minutes within the request creation). Session creation/termination should be within the SLO. Port forwarding is 1 minute (break-glass scenario) and Managed SSH session is 3 minutes.(normal usage)
- Security
Traffic from bastion originates from the private endpoint on the subnet. In order to allow traffic from bastions, allow ingress and egress traffic from this private endpoint to the IPs that need to be accessed via bastions. Fine-grained policies that restrict access to a subset of instances help to ensure the right level of access levels.
- Availability
The service should provide high availability to create/terminate bastions and sessions (based on API error rate). Targeted availability is 99.9%.
- Cost
There is no cost for using OCI Bastion. Customers can create up-to five bastions per region per tenancy. Each bastion serves the target resources within a VCN.
- Usage Scenarios
If the customer wants access to private target hosts which are running OCI native images, are Linux Based and running the OCA v2 agent (with bastion plugin enabled in it), they can use Managed SSH sessions. If the customer wants access to private target resources which don't have the agent running, are Windows Based or access to databases (ATP or MySQL), they can use Port forwarding SSH sessions.