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.
Bastions are gateways or proxies. They are logical entities that provide secure 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. OCI Bastion is an infrastructure service that can take the place of a bastion server that you create yourself in Oracle Cloud Infrastructure (OCI).
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 use OCI Bastion, you can specify a classless inter-domain routing (CIDR) block allowlist and a maximum session time-to-live (TTL). OCI Bastion creates a network path 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
architecture-use-bastion-service-oracle.zip
The architecture has the following components:
- OCI region
An OCI region is a localized geographic area that contains one or more data centers, hosting availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Availability domain
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 shouldn't affect the other availability domains in the region.
- Fault domain
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 virtual cloud network (VCN) is a customizable, software-defined network that you set up in an OCI region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping classless inter-domain routing (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.
- OCI Bastion
Oracle Cloud Infrastructure Bastion provides restricted and time-limited secure access to resources that don't have public endpoints and that require strict resource access controls, such as bare metal and virtual machines, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Cloud Infrastructure Kubernetes Engine (OKE), and any other resource that allows Secure Shell Protocol (SSH) access. With OCI Bastion service, you can enable access to private hosts without deploying and maintaining a jump host. In addition, you gain improved security posture with identity-based permissions and a centralized, audited, and time-bound SSH session. OCI Bastion removes the need for a public IP for bastion access, eliminating the hassle and potential attack surface when providing remote access.
- Bastion Service Backend
The Oracle Cloud Infrastructure Bastion 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 OCI Bastion backend.
- Private Endpoint
A private endpoint connects the OCI Bastion to the target subnets. The target subnet can be a separate subnet for 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.
- Cloud Guard
Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, you might want to detect OCI Object Storage buckets that have visibility set to public.
Apply Oracle Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.
You can also use the Managed List feature to apply certain configurations to detectors.
- Security Zones
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, OCI validates the operations against the policies in the recipe, and prevents operations that violate any of the policies.
- OCI Bastion
Specifying time-to-live (TTL) at the bastion level ensures that none of the sessions created in the context of that bastion have a longer TTL than the bastion itself. Set the TTL to the minimum limit for your use case. The minimum value is 30 mins and the maximum value is 3 hours. The TTL is also configurable at the session level.
The CIDR block used for an allowlist should be as narrow as possible for your scenario. This allows you to restrict the IP address ranges for SSH connections that can access the private target resources.
Consider the size of the target subnet associated with OCI Bastion and the number of bastion instances you want. Each OCI Bastion instance 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. The target subnet can either be the subnet where your target resource is located or other subnets in the target VCN.
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 such as 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
Oracle Cloud Infrastructure Bastion is a regional service. For example, must create bastion in the PHX region to access resources in the PHX region. A bastion within one region can't be used to access resources in another region.
- Performance
OCI 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 OCI 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 by using bastions. Fine-grained policies that restrict access to a subset of instances help to ensure the right level of access.
- 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. You can create up-to five bastions per region per tenancy. Each bastion serves the target resources within a VCN.
- Usage Scenarios
If you want access to private target hosts which are either running OCI native images or are Linux-based and running the OCA v2 agent (with bastion plugin enabled in it), you can use managed SSH sessions. If you want access to private target resources that either don't have the agent running, are Windows Based, or require access to databases (ATP or MySQL), you can use port-forwarding SSH sessions.