Oracle Cloud Bastion Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, Identity, and Compliance

by

Category

Security, Identity, and Compliance

1. Introduction

Oracle Cloud Infrastructure (OCI) Bastion is a managed service that lets you securely access resources that live in private subnets—without giving those resources public IP addresses and without running your own jump host.

In simple terms: Bastion is a secure, temporary “door” into your private network. You create a Bastion resource in OCI, then create time-bound sessions that allow SSH access (or SSH port forwarding) to private targets such as compute instances or private endpoints. Access is controlled by OCI Identity and Access Management (IAM) policies and by network allowlists.

Technically, Bastion is an OCI-managed SSH bastion/jump capability where you: – Create a Bastion associated with a VCN subnet (often a dedicated “bastion subnet”). – Create sessions (managed SSH or port forwarding) with a defined time-to-live (TTL). – Use standard SSH tooling from your workstation to connect through OCI’s bastion endpoint to the private target.

The main problem it solves is a classic one in cloud networking: operations teams need administrative access to private workloads, but security teams don’t want public IP exposure, permanently open inbound ports, or unmanaged jump servers that become high-risk choke points.

2. What is Bastion?

Official purpose (OCI scope): OCI Bastion provides restricted, time-bound, audited access to resources in private networks using SSH-based sessions—without requiring public IP addresses on target resources and without requiring you to manage a bastion host yourself.

Core capabilities

OCI Bastion commonly provides: – Managed SSH access to private compute instances (SSH to a private IP through a Bastion session). – SSH port forwarding sessions to reach private endpoints (databases, internal web apps, APIs, admin ports) via an SSH tunnel. – Time-limited sessions (TTL) to reduce standing access. – Client IP allowlisting so only approved source IP ranges can initiate Bastion sessions. – IAM-based control for who can create/delete bastions and sessions. – Audit visibility through OCI logging/governance features (not a full keystroke recorder; see limitations).

Major components

  • Bastion (resource): The OCI object you create that represents the bastion capability for a network location. It is associated with:
  • A compartment
  • A region
  • A target subnet in a VCN
  • A client CIDR allowlist
  • A maximum session TTL
  • Bastion session: A short-lived access grant. Common session types include:
  • Managed SSH session (for SSH to a target compute instance)
  • Port forwarding session (for tunneling traffic to a private IP:port)

Service type

  • Managed cloud service under Oracle Cloud’s Security, Identity, and Compliance portfolio.
  • You operate it through the OCI Console, CLI, SDKs, and APIs, but you do not manage the underlying bastion hosts.

Scope: regional, tenancy, compartment

  • Regional: Bastion is created in a specific OCI region and associated with network resources in that region.
  • Tenancy + compartment scoped: You create bastions and sessions in compartments, controlled by IAM policies.

How it fits into the Oracle Cloud ecosystem

Bastion is designed to work with: – Networking: VCN, subnets, route tables, security lists, Network Security Groups (NSGs), DRG/VCN peering. – Compute: Instances in private subnets (Linux/Unix commonly for SSH; Windows can be reached via port forwarding for RDP if you run an SSH tunnel, with appropriate security controls). – Identity & governance: IAM policies, compartments, tagging, and Audit events. – Operations: Monitoring and logging around session creation and access events (verify exact telemetry options in official docs for your region and tenant configuration).

If you are unsure about any feature availability or session types in your region, verify in official docs: – https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm

3. Why use Bastion?

Business reasons

  • Reduce breach risk by eliminating public IPs on admin targets and minimizing open inbound ports.
  • Lower operational burden vs. building and patching your own jump hosts.
  • Better governance with centralized access control via IAM policies and compartment boundaries.

Technical reasons

  • Private-only architecture: Keep workloads in private subnets and still retain operational access.
  • Standard SSH tooling: No proprietary agent required on targets for basic SSH scenarios; most teams can use existing SSH clients and automation patterns.
  • Controlled ingress: Client CIDR allowlisting prevents session use from unknown networks.

Operational reasons

  • Temporary access by design: Session TTL and lifecycle encourage “just-in-time” administrative access.
  • Repeatable workflows: Teams can standardize “break-glass” and normal access procedures using Bastion sessions.
  • Fewer moving parts: No need for a self-managed bastion VM, autoscaling, patching, hardening, HA design, or SSH daemon tuning.

Security/compliance reasons

  • Least privilege: Use fine-grained IAM policies so only specific groups can create sessions for specific compartments.
  • Auditability: Session creation/management events are recorded via OCI governance capabilities (review in your tenancy).
  • Reduced attack surface: Targets remain private; no direct inbound exposure to the public internet.

Scalability/performance reasons

  • Bastion offloads the “jump host” function to Oracle-managed infrastructure.
  • Session model scales better than distributing static SSH access across many public endpoints.

When teams should choose Bastion

Choose Bastion when you need: – Admin access to private compute instances – Connectivity to private services through SSH port forwarding (e.g., DB admin) – A managed alternative to jump boxes – Clear IAM governance boundaries and short-lived access

When teams should not choose it

Bastion may not be the best fit when: – You need full, always-on site-to-site connectivity: consider VPN Connect or FastConnect. – You need non-SSH-native session recording or advanced privileged access management (PAM) features: consider specialized PAM tools (verify requirements). – Your environment prohibits SSH entirely or requires application-layer gateways only.

4. Where is Bastion used?

Industries

  • Finance, healthcare, public sector, and regulated industries where private network access and auditability matter.
  • SaaS and fintech companies enforcing “no public IP” rules for production.

Team types

  • Platform engineering teams standardizing secure access patterns
  • SRE/operations teams needing reliable break-glass access
  • Security teams enforcing network isolation
  • DevOps engineers managing private compute fleets and CI/CD runners

Workloads and architectures

  • Private compute instances hosting APIs, microservices, batch jobs
  • Private database tiers (accessed via SSH port forwarding)
  • Hub-and-spoke VCN designs with shared services networks
  • Hybrid architectures where workloads are private and administrative access must be controlled

Real-world deployment contexts

  • Production: Strong fit—when paired with strict IAM, short TTL, IP allowlisting, and NSGs.
  • Dev/test: Also helpful, but teams sometimes loosen allowlists; avoid turning Bastion into an “always open” backdoor.

5. Top Use Cases and Scenarios

Below are realistic, common Bastion scenarios in Oracle Cloud.

1) SSH into a private Linux instance (no public IP)

  • Problem: Admins need SSH access but security forbids public IPs.
  • Why Bastion fits: Managed SSH sessions let you connect to the instance’s private IP through a controlled session.
  • Example: An ops engineer connects to 10.0.2.10 in a private subnet to install patches.

2) Emergency “break-glass” access during outage

  • Problem: A production service is failing and needs immediate instance-level inspection.
  • Why Bastion fits: You can create a short-lived session with tight TTL and controlled source IP.
  • Example: On-call SRE creates a 30-minute session to check logs and restart a service.

3) Port-forward to a private database for administration

  • Problem: Database endpoints are private; DBAs need SQL*Plus/GUI access.
  • Why Bastion fits: Port forwarding sessions provide a secure SSH tunnel to a private IP:port.
  • Example: DBA forwards local port 11521 to 10.0.3.15:1521 to run maintenance.

4) Access a private internal web UI (admin console)

  • Problem: Admin UIs should not be internet-exposed but must be reachable occasionally.
  • Why Bastion fits: Use port forwarding to access the web UI locally.
  • Example: Engineer forwards localhost:18080 to 10.0.2.50:8080 to access an internal dashboard.

5) Vendor or contractor access without opening permanent network paths

  • Problem: Third parties need temporary access; VPN accounts are heavy and risky.
  • Why Bastion fits: Create a time-bound session, limit it to vendor IP ranges, and restrict IAM permissions.
  • Example: Contractor gets a 2-hour session to a single instance for diagnostics.

6) Reduce reliance on shared SSH keys and long-lived access

  • Problem: Long-lived SSH keys become unmanaged and hard to rotate.
  • Why Bastion fits: Sessions are temporary; you can align access to IAM and session TTL policies.
  • Example: Team moves from permanent jump box access to per-ticket Bastion sessions.

7) Access private instances in peered VCNs (hub-and-spoke)

  • Problem: Private workloads in spoke VCNs should not have public IPs.
  • Why Bastion fits: Bastion in a shared services subnet can reach targets through VCN peering/DRG routing (if configured).
  • Example: Platform team hosts Bastion in shared VCN; app teams connect to spoke subnets.

8) Secure access to CI/CD runners or build agents in private subnets

  • Problem: Build agents need to stay private but occasionally require manual inspection.
  • Why Bastion fits: Managed access without changing the network to public.
  • Example: DevOps engineer SSHs to a private runner to check disk usage.

9) Controlled access for security scanning tools

  • Problem: Security team needs to run scans against private hosts.
  • Why Bastion fits: Port forwarding can enable controlled connectivity to internal ports.
  • Example: Scanner connects via tunnel to test a private service endpoint.

10) Migration and cutover phases

  • Problem: During migration, teams need frequent access but don’t want to create long-lived public ingress rules.
  • Why Bastion fits: Bastion provides temporary access while networks stabilize.
  • Example: During app cutover, engineers connect to multiple private instances via Bastion sessions.

6. Core Features

Note: Feature names and availability can evolve by region. Verify in official docs for your tenancy/region: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm

Bastion resource associated with a target subnet

  • What it does: Anchors Bastion to a subnet in your VCN.
  • Why it matters: Defines the network path Bastion uses to reach private targets.
  • Practical benefit: Clean separation—use a dedicated “bastion subnet” with strict NSGs.
  • Caveat: You must correctly allow traffic from the bastion subnet to targets (NSGs/security lists).

Session-based access with TTL (time-bound)

  • What it does: Sessions expire automatically after a defined TTL.
  • Why it matters: Reduces standing privileged access.
  • Practical benefit: Helps enforce just-in-time access policies.
  • Caveat: Long maintenance tasks may need longer TTL; avoid setting maximum TTL too high.

Client CIDR allowlist

  • What it does: Restricts which source IP ranges can initiate Bastion sessions.
  • Why it matters: Stops access from unknown networks.
  • Practical benefit: Aligns with corporate egress IPs or secure admin networks.
  • Caveat: Remote users behind changing IPs can be blocked; plan a secure egress strategy (corporate VPN, ZTNA, fixed egress NAT).

Managed SSH session (private instance access)

  • What it does: Provides a managed path to SSH into a private compute instance.
  • Why it matters: Removes need for public IPs and self-managed jump hosts.
  • Practical benefit: Use normal SSH clients; access is governed by IAM and short TTL.
  • Caveat: You still need OS-level access (user account, authorized keys) on the instance.

SSH port forwarding session (private endpoint access)

  • What it does: Creates an SSH tunnel to forward a local port to a private IP:port.
  • Why it matters: Enables access to private services (DB, web UI, admin ports) without exposing them publicly.
  • Practical benefit: Works with many TCP services; you keep services private.
  • Caveat: You must manage local port collisions and ensure NSGs allow traffic from the bastion subnet.

IAM integration (who can manage bastions/sessions)

  • What it does: Uses OCI IAM policies to authorize actions (create bastion, create session, list sessions, delete).
  • Why it matters: Central security control with compartment scoping.
  • Practical benefit: Separate duties: network admins create bastions; app teams create sessions.
  • Caveat: Mis-scoped policies can unintentionally grant broad access.

Auditing via OCI governance tooling

  • What it does: Session creation and management operations are visible as OCI control-plane events.
  • Why it matters: Supports investigations and compliance needs.
  • Practical benefit: Helps answer “who created a session, when, and to what target.”
  • Caveat: This is not the same as recording every command executed on the target host.

7. Architecture and How It Works

High-level service architecture

At a high level: 1. An admin user (or automation) authenticates to OCI and is authorized via IAM to create a Bastion session. 2. The user creates a Bastion session specifying target details (managed SSH to an instance, or port forwarding to a private IP:port). 3. The user’s SSH client connects to the Bastion service endpoint using the session identifier and SSH key. 4. The Bastion service connects to the target inside the VCN using the network path defined by the associated subnet. 5. Traffic is proxied/tunneled through the session until TTL expires or the session is terminated.

Control flow vs data flow

  • Control plane: Creating bastions and sessions via OCI Console/CLI/API. These actions are governed by IAM and audited.
  • Data plane: The actual SSH traffic (or port-forwarded TCP traffic) flows through the Bastion session between your client and the private target.

Integrations with related services

  • VCN/Subnets/NSGs: Define reachability between bastion subnet and private targets.
  • IAM/Compartments: Control who can create and manage sessions.
  • Audit: Track bastion/session operations (control plane).
  • Vault (optional): Centralize sensitive material management (for example, where you store SSH keys); exact integration patterns are customer-managed.

Dependency services

  • OCI Networking (VCN, subnet routing)
  • OCI IAM
  • Target resources (Compute instances, private endpoints)

Security/authentication model

  • OCI IAM controls who can create sessions.
  • SSH keys authenticate the user to the Bastion session endpoint.
  • OS-level authentication still applies when you SSH into a compute instance (user account permissions, authorized keys, sudo rules).

Networking model (what you must configure)

  • Bastion is associated with a subnet. Your target resources must allow inbound traffic from that subnet (or from an NSG associated with the Bastion path, depending on your design).
  • Targets typically live in private subnets with no public IP.
  • You do not open inbound internet access to the target; you open only VCN-internal paths (e.g., bastion subnet → target subnet on port 22).

Monitoring/logging/governance considerations

  • Use Audit for bastion/session lifecycle events.
  • Use instance OS logs (syslog, auth logs) to track actual SSH logins and commands (command tracking typically requires OS-level tooling; Bastion itself is not a full PAM recorder).
  • Consider standard OCI governance practices:
  • compartments
  • tagging
  • least privilege IAM
  • standardized TTL

Simple architecture diagram

flowchart LR
  U[Admin workstation\nSSH client] -->|Create session (IAM)| OCI[OCI Bastion Control Plane]
  U -->|SSH to session endpoint| B[OCI Bastion Session]
  B -->|VCN internal traffic| T[Private Compute Instance\n10.x.x.x]

Production-style architecture diagram

flowchart TB
  subgraph Internet["Admin Networks"]
    A1[Corp Admin Laptop]
    A2[Corp VPN / Fixed Egress NAT]
  end

  subgraph OCI["Oracle Cloud (OCI) Region"]
    subgraph IAM["Identity & Governance"]
      I1[OCI IAM Policies]
      I2[OCI Audit]
      I3[Compartments & Tags]
    end

    subgraph VCN["VCN 10.0.0.0/16"]
      subgraph SubB["Bastion Subnet (private)\n10.0.0.0/24"]
        NSGB[NSG: bastion-subnet rules]
      end
      subgraph SubApp["App Subnet (private)\n10.0.2.0/24"]
        NSGAPP[NSG: app instances]
        C1[Compute Instance\n(no public IP)]
        S1[Private Service\nDB/Web/Admin Port]
      end
    end

    BAST[OCI Bastion Resource]
    SESS[OCI Bastion Sessions\n(Managed SSH / Port Forward)]
  end

  A1 --> A2 -->|Allowed source CIDR| SESS
  I1 --> BAST
  I1 --> SESS
  SESS -->|VCN routing + NSGs| C1
  SESS -->|TCP forward| S1
  SESS --> I2
  BAST --> I2

8. Prerequisites

Tenancy and account requirements

  • An active Oracle Cloud tenancy with permissions to use OCI Networking and Bastion.
  • A compartment where you can create networking and Bastion resources.

Permissions / IAM roles

At minimum, you need IAM policies that allow you to: – manage bastions – manage bastion sessions – read networking resources – (for the lab) manage compute instances and VCN resources

Example (conceptual) policy statements (adapt to your compartment structure and least privilege model; verify exact policy verbs/resources in docs): – Allow a group to manage bastions in a compartment – Allow a group to manage bastion sessions in a compartment – Allow a group to use subnets in a compartment – Allow a group to manage instances in a compartment

Policy syntax can be tenancy-specific; verify here: – https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/policyreference.htm

Billing requirements

  • Bastion may incur charges depending on your usage and region. See pricing section.

Tools

  • OCI Console access (web browser)
  • An SSH client:
  • macOS/Linux: ssh (OpenSSH)
  • Windows: Windows Terminal + OpenSSH (or PuTTY with SSH tunneling support)
  • Optional: OCI CLI (helpful but not required for this lab)
  • https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm

Region availability

  • OCI services vary by region. Confirm Bastion availability in your target region:
  • Verify in official docs and your Console service list.

Quotas/limits

  • Bastion and session limits apply (per tenancy/region/compartment). Check service limits:
  • https://docs.oracle.com/en-us/iaas/Content/General/Concepts/servicelimits.htm

Prerequisite services

  • VCN and subnets
  • A private compute instance to access (for the lab)

9. Pricing / Cost

OCI pricing changes over time and can be region-dependent. Do not rely on informal blogs for pricing. Use official sources: – OCI pricing list (Security category): https://www.oracle.com/cloud/price-list/ – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html

Pricing dimensions (typical model)

OCI Bastion costs are generally driven by: – Bastion session usage (for example, number of sessions and session duration in hours) – Potentially other dimensions depending on current OCI pricing structure for Bastion (SKU definitions can change)

Because exact SKUs and rates can vary, verify the Bastion line items in the official price list for your region.

Free tier

Oracle Cloud Free Tier offerings evolve and may differ by region. If Bastion is included in a free allowance, it will be stated in the official free tier documentation or pricing pages. Verify in official docs: – https://www.oracle.com/cloud/free/

Direct cost drivers

  • Long session durations: Keeping sessions open for hours increases cost if billing is session-hour based.
  • High session count: Many parallel sessions or frequent sessions can increase usage.
  • Operational habits: “Always-on” tunnels (port forwarding) can become a hidden cost if left running.

Indirect/hidden costs

Even if Bastion itself is relatively low cost, the architecture around it can add cost: – Compute instances you manage (targets) – NAT Gateway (if you add it for outbound patching from private instances) – Logging costs if you enable extensive log ingestion/retention (varies by service) – Data transfer: Consider network egress charges if your session traffic results in cross-region or internet egress (typical bastion-to-target traffic stays within a region/VCN, but confirm your routing and endpoints)

Network/data transfer implications

  • Bastion is about access, not bulk transfer. If you use Bastion to move large files repeatedly (e.g., SCP over the tunnel), you may:
  • Increase session time (higher cost)
  • Increase network utilization
  • Encounter operational limits Consider object storage pre-authenticated requests or artifact repositories for large transfers instead.

How to optimize cost

  • Prefer short TTL aligned to actual tasks (e.g., 30–120 minutes).
  • Avoid leaving port-forwarding tunnels running unattended.
  • Use automation to create sessions only when needed (CI/CD, ticket-based workflows).
  • Consolidate bastion design sensibly (don’t proliferate bastions per app unless required by network segmentation).

Example low-cost starter estimate (no fabricated prices)

A minimal lab typically uses: – 1 Bastion resource – 1 short managed SSH session (e.g., 30–60 minutes) – 1 always-free compute instance (if eligible) Your cost depends on the current Bastion session-hour price and any paid compute/networking. Use: – https://www.oracle.com/cloud/costestimator.html

Example production cost considerations

In production, cost typically grows with: – Number of admin users and parallel sessions – TTL defaults and operational discipline – Frequency of access (daily maintenance vs occasional break-glass) A common cost-control approach is to implement: – strict TTL defaults – privileged access workflows (approval-based) – periodic reporting from Audit + IAM

10. Step-by-Step Hands-On Tutorial

This lab builds a private compute instance (no public IP) and uses OCI Bastion to SSH into it safely.

Objective

  • Create a private Linux compute instance in Oracle Cloud (no public IP).
  • Create an OCI Bastion associated with a dedicated subnet.
  • Create a Managed SSH session and connect to the instance using standard SSH.

Lab Overview

You will create: 1. A VCN with two private subnets: – bastion-subnet (for Bastion association) – app-subnet (for the private compute instance) 2. NSGs (recommended) to control traffic: – Allow bastion-subnet -> app-subnet on TCP/22 3. A compute instance in app-subnet without a public IP 4. A Bastion resource in the compartment, associated with bastion-subnet 5. A managed SSH session and an SSH connection from your workstation

Expected outcome: You can run uname -a on a private instance that has no public IP.

Step 1: Prepare an SSH key pair (local workstation)

You will use this key for: – the compute instance (so your user can log in) – the Bastion session (so you can authenticate to Bastion)

On macOS/Linux:

ssh-keygen -t ed25519 -f ~/.ssh/oci_bastion_lab -C "oci-bastion-lab"

This creates: – Private key: ~/.ssh/oci_bastion_lab – Public key: ~/.ssh/oci_bastion_lab.pub

Expected outcome: Key files exist locally.

Verification:

ls -l ~/.ssh/oci_bastion_lab ~/.ssh/oci_bastion_lab.pub

On Windows (PowerShell):

ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\oci_bastion_lab -C "oci-bastion-lab"

Step 2: Create network foundations (VCN + subnets)

In the OCI Console: 1. Go to Networking → Virtual Cloud Networks 2. Click Create VCN 3. Choose VCN with Internet Connectivity only if you need outbound internet later. For this lab, you can also use VCN with custom CIDR and keep everything private. 4. Use a simple CIDR like 10.0.0.0/16

Create two private subnets: – bastion-subnet: 10.0.0.0/24 (Private subnet, no public IP assignment) – app-subnet: 10.0.2.0/24 (Private subnet, no public IP assignment)

Expected outcome: VCN exists with two private subnets.

Verification: – In the VCN details, confirm both subnets exist and show Private.

Notes (important): – You do not need an Internet Gateway for Bastion to work with private targets. – Your instance does not need outbound access for the SSH connectivity itself.

Step 3: Create NSGs and security rules (recommended)

You want the private instance to accept SSH only from the bastion network path.

  1. Go to Networking → Network Security Groups
  2. Create NSG: nsg-app-ssh
  3. Add an ingress rule to nsg-app-ssh: – Source type: CIDR – Source CIDR: 10.0.0.0/24 (the bastion-subnet CIDR) – IP protocol: TCP – Destination port: 22

Attach nsg-app-ssh to your compute instance in a later step.

Expected outcome: An NSG exists that allows SSH from the bastion subnet to app instances.

Verification: – Review NSG rules and confirm TCP/22 ingress from 10.0.0.0/24.

Common mistake: Allowing SSH from 0.0.0.0/0. That defeats the point of private access.

Step 4: Create a private compute instance (no public IP)

  1. Go to Compute → Instances → Create instance
  2. Choose: – Image: Oracle Linux (or another Linux you prefer) – Shape: pick an eligible low-cost/always-free shape if available in your region (varies)
  3. Networking: – VCN: your lab VCN – Subnet: app-subnet – Do not assign a public IPv4 address
  4. Add your SSH public key from ~/.ssh/oci_bastion_lab.pub
  5. Add NSG: – Attach nsg-app-ssh

After provisioning, note: – The instance private IP (e.g., 10.0.2.10) – The default OS user (commonly opc on Oracle Linux images; verify in the instance details)

Expected outcome: A running instance with only a private IP.

Verification: – Instance details show Public IP: None – Private IP is present – Instance state is Running

Step 5: Create a Bastion resource

  1. Go to Security (or Identity & Security) → Bastion
  2. Click Create bastion
  3. Configure: – Name: bastion-lab – Compartment: your lab compartment – Target VCN: choose your VCN – Target subnet: bastion-subnet – Client CIDR allowlist: add your current public IP as /32
    • Example: 203.0.113.10/32
    • Find your IP using an external “what is my IP” tool, or your corporate egress IP documentation.
    • Maximum session TTL: choose a lab-friendly limit (e.g., 1–3 hours)

Expected outcome: Bastion resource becomes Active.

Verification: – Bastion state shows Active – Client CIDR allowlist contains your IP range

Common mistakes: – Using the wrong client IP (especially if you are behind a corporate proxy/VPN that changes egress). – Setting a very wide allowlist for convenience.

Step 6: Create a Managed SSH session to the private instance

  1. Open your Bastion resource
  2. Go to Sessions → Create session
  3. Choose session type: Managed SSH session
  4. Provide: – Target resource: select your compute instance (or specify its private IP, depending on UI) – Target private IP: your instance private IP (if prompted) – SSH username: e.g., opc (depends on your image; verify) – SSH public key: paste contents of ~/.ssh/oci_bastion_lab.pub – Session TTL: e.g., 30–60 minutes for the lab

Create the session and wait until it is Active.

Expected outcome: Session is active and shows connection instructions (host name, session OCID, port).

Verification: – Session lifecycle state is Active – You can see: – Bastion service host (e.g., host.bastion.<region>.oci.oraclecloud.com) – Session identifier (often the session OCID) – Port 22

Step 7: Connect to the private instance using SSH (ProxyCommand)

From your workstation terminal, use the pattern recommended by OCI Bastion for managed SSH sessions.

Replace: – <region> with your region identifier (as shown in the session details) – <session_ocid> with the Bastion session OCID – <private_ip> with your instance private IP (e.g., 10.0.2.10) – <os_user> with the instance OS user (e.g., opc)

ssh -i ~/.ssh/oci_bastion_lab \
  -o ProxyCommand="ssh -i ~/.ssh/oci_bastion_lab -W %h:%p -p 22 <session_ocid>@host.bastion.<region>.oci.oraclecloud.com" \
  <os_user>@<private_ip>

Expected outcome: You get an interactive shell on the private instance.

Verification commands on the instance:

hostname
uname -a
ip a | head

If you can run these commands, you have successfully accessed a private instance without a public IP using Bastion.

Validation

Use this checklist: – [ ] Compute instance has no public IP – [ ] Bastion is Active – [ ] Session is Active – [ ] NSG rule allows TCP/22 from bastion-subnet CIDR to app instance – [ ] SSH connection succeeds and you can run uname -a

Troubleshooting

Common errors and fixes:

1) Permission denied (publickey) – Causes: – Wrong SSH private key used locally – Public key not installed on instance (instance metadata) – Wrong OS username (e.g., opc vs ubuntu) – Fix: – Confirm you used the same keypair for the instance and Bastion session. – Verify the correct default username for your chosen image in instance docs.

2) Session won’t become Active / connection times out – Causes: – Client CIDR allowlist does not include your real egress IP – Corporate VPN changed your public IP after session creation – Fix: – Update Bastion client CIDR allowlist to include the correct egress IP range. – Prefer fixed egress via corporate NAT or VPN.

3) SSH hangs after connecting to Bastion – Causes: – Network rules block Bastion subnet → app instance on port 22 – Target instance firewall blocks SSH – Fix: – Ensure NSG/security list allows inbound TCP/22 from the bastion-subnet CIDR. – On the instance, verify sshd is running (requires console access if you can’t SSH).

4) Wrong private IP used – Fix: – Copy the private IP from the instance details page.

5) TTL expired – Fix: – Create a new session with sufficient TTL for your task.

Cleanup

To avoid ongoing charges: 1. Delete the Bastion session(s) 2. Delete the Bastion resource 3. Terminate the compute instance 4. Delete NSGs (if created only for the lab) 5. Delete the VCN (and subnets)

Expected outcome: All lab resources are removed and billing stops (except any retained logs/storage you configured elsewhere).

11. Best Practices

Architecture best practices

  • Use a dedicated bastion subnet (private) separate from app subnets.
  • Use NSGs for precise control:
  • Allow SSH to targets only from the bastion subnet CIDR (or a dedicated NSG strategy).
  • For hub-and-spoke designs, centralize Bastion in a shared services VCN only if routing/segmentation rules support it cleanly.

IAM/security best practices

  • Apply least privilege:
  • Only a small group can create bastions.
  • A broader ops group may be allowed to create sessions, but only in specific compartments.
  • Use separate compartments for prod vs non-prod bastions.
  • Enforce short TTL defaults and restrict maximum TTL.

Cost best practices

  • Use shorter session TTLs.
  • Avoid leaving tunnels open.
  • Review Audit events and session usage periodically.

Performance best practices

  • Bastion is not intended for bulk data transfer. Use proper artifact repositories or object storage for large files.

Reliability best practices

  • Define a documented “break-glass” runbook:
  • Who can create sessions
  • TTL limits
  • How access is reviewed
  • Ensure bastion subnet has correct routing to all target subnets (especially with peering/DRG).

Operations best practices

  • Standardize naming:
  • bastion-<env>-<region>-<vcn>
  • session-<ticket>-<target>
  • Tag bastion/session resources for:
  • environment, cost center, owner, ticket/reference
  • Use OS-level logging (auth logs) on targets and centralize them.

Governance/tagging/naming best practices

  • Mandatory tags for production:
  • Owner, Environment, CostCenter, DataSensitivity
  • Enforce via organizational standards and policy (where applicable).

12. Security Considerations

Identity and access model

  • Bastion management is controlled by OCI IAM policies.
  • Session usage is controlled by:
  • IAM authorization to create sessions
  • Bastion client CIDR allowlist
  • Session TTL
  • Target network rules (NSG/security list)

Key principle: Bastion controls path access; the target OS still controls login authorization.

Encryption

  • SSH provides encrypted transport between your client and the Bastion endpoint.
  • Port forwarding over SSH is encrypted end-to-end within the tunnel.

Network exposure

  • Avoid public IPs on targets.
  • Keep inbound rules minimal:
  • targets: allow SSH only from bastion subnet (not from the internet)
  • Ensure security lists/NSGs do not accidentally allow broad lateral movement from bastion subnet.

Secrets handling

  • Treat SSH private keys as secrets:
  • Store securely (OS keychain, enterprise vault, secret manager)
  • Use passphrases where practical
  • Rotate keys and remove old keys from instance authorized_keys
  • Avoid pasting private keys into tickets/chat.

Audit/logging

  • Use OCI Audit for session and bastion lifecycle events.
  • Use instance OS logs for:
  • SSH login events
  • sudo actions
  • application logs For stronger compliance, consider additional OS-level telemetry and centralized logging.

Compliance considerations

Bastion supports common compliance goals: – Reducing public exposure – Time-bound administrative access – IAM-based access control and auditing But compliance requires end-to-end controls: – user identity lifecycle – key management – host hardening – log retention and review

Common security mistakes

  • Allowlisting 0.0.0.0/0 in Bastion client CIDRs “for convenience”
  • Overly broad IAM policies (e.g., letting all developers create sessions in production)
  • Leaving SSH keys unrotated and widely shared
  • Allowing bastion subnet broad access to many ports/subnets unnecessarily

Secure deployment recommendations

  • Restrict Bastion client CIDRs to known admin egress IPs.
  • Enforce short TTL and ticket-based session creation for production.
  • Pair Bastion with:
  • strict NSGs
  • OS hardening and MFA for IAM users
  • centralized audit/log review processes

13. Limitations and Gotchas

Because OCI services evolve, confirm details in official docs. Common limitations/gotchas include:

  • Session TTL constraints: Maximum TTL is configurable but bounded; long tasks may be interrupted when TTL expires.
  • Not a full PAM replacement: Bastion controls access paths; it typically does not provide full session recording of commands.
  • Client IP allowlisting operational friction: Remote admins with changing egress IPs will fail to connect unless you design a stable admin egress.
  • Target OS access still required: Bastion doesn’t replace Linux user management, sudo policies, or SSH hardening.
  • Network rules still matter: If NSGs/security lists don’t allow bastion subnet to reach targets, sessions will fail.
  • Service limits: Quotas exist for number of bastions/sessions; check OCI service limits page.
  • Cross-network reachability: For peered VCNs/DRG/hybrid networks, you must ensure routing and security rules permit the bastion subnet to reach targets.

14. Comparison with Alternatives

Bastion is one way to access private resources. Alternatives exist depending on security and operational requirements.

Option Best For Strengths Weaknesses When to Choose
OCI Bastion Controlled SSH/port-forward access to private resources Managed service, no jump host to patch, TTL sessions, IAM governance SSH-centric, not full PAM/session recording Default choice for secure admin access to private OCI resources
Self-managed jump box (Compute instance with public IP) Simple environments, custom tooling Full control, can add tooling, can be used for many protocols You must harden/patch/monitor; public exposure risk; HA is your problem Only when you need custom behavior and accept operational/security overhead
OCI VPN Connect / FastConnect Persistent hybrid connectivity Private connectivity from on-prem; can remove need for bastion for some access More setup, cost, and networking complexity When you need enterprise-grade network connectivity, not just admin access
OCI Cloud Shell + private access patterns Quick admin from OCI console context No local setup for CLI/SSH tooling Egress IP constraints and governance considerations; may not fit strict allowlisting For dev/test or controlled environments—verify policies and IP allowlisting needs
AWS Systems Manager Session Manager (other cloud) Agent-based access without inbound ports Strong governance, no inbound SSH Different cloud; requires SSM agent and IAM If you are on AWS and want agent-based access
Azure Bastion (other cloud) Browser-based RDP/SSH via Azure portal No public IP on VMs, portal access Different cloud; pricing model differs If you are on Azure
GCP IAP TCP forwarding (other cloud) Access to private VMs via Google identity-aware proxy Identity-based access Different cloud; setup constraints If you are on GCP
Teleport / HashiCorp Boundary (self-managed or SaaS) Enterprise PAM and access workflows Rich access policies, session recording options More complexity, cost, operations When you need advanced PAM features beyond a basic bastion

15. Real-World Example

Enterprise example: regulated financial services production access

  • Problem: Production workloads must not have public IPs; auditors require controlled admin access and traceability.
  • Proposed architecture:
  • Hub-and-spoke VCNs
  • Dedicated bastion subnet in shared services VCN
  • NSGs allow bastion subnet to reach only TCP/22 on approved admin hosts, and specific DB ports where needed
  • IAM policies restrict session creation to SRE group; max TTL enforced
  • Audit events exported to a central SIEM; OS auth logs centralized
  • Why Bastion was chosen: Managed access reduces jump-box maintenance and improves governance with time-bound sessions.
  • Expected outcomes:
  • Reduced public exposure
  • Short-lived access aligned to change tickets
  • Clear audit trail for bastion/session operations

Startup/small-team example: private-by-default VCN with occasional admin access

  • Problem: Small team wants private instances but needs occasional SSH for debugging.
  • Proposed architecture:
  • One VCN, private app subnet
  • Bastion subnet + Bastion resource
  • Strict client allowlist using founders’ fixed IPs (or secure VPN egress)
  • Why Bastion was chosen: No need to maintain a jump VM; simpler and safer than public IPs.
  • Expected outcomes:
  • Private instances stay private
  • On-demand access for debugging
  • Minimal operational overhead

16. FAQ

1) Is “Bastion” the current official Oracle Cloud service name?

In OCI documentation and console, it is commonly presented as Bastion (OCI Bastion). If you see “Oracle Cloud Infrastructure Bastion,” that is the same service. Verify naming in official docs: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm

2) Do my private instances need public IPs to use Bastion?

No. A primary goal of Bastion is to access private targets without public IPs.

3) Do I still need to open port 22 to the internet?

No. You typically allow SSH only from the bastion subnet (VCN-internal), not from the internet.

4) What protocols does Bastion support?

Bastion is SSH-based. It supports SSH access and SSH port forwarding (tunneling TCP over SSH). For anything beyond that, verify in official docs.

5) Can I use Bastion to reach a private database?

Yes, typically via SSH port forwarding sessions, assuming the database endpoint is reachable from the bastion subnet and NSGs permit it.

6) Is Bastion a replacement for VPN?

Not usually. Bastion is for controlled admin access and tunneling, while VPN/FastConnect provide broader network connectivity.

7) Does Bastion record my SSH session (keystrokes/commands)?

Bastion provides control-plane audit events (session creation, etc.). Command-level recording is typically an OS-level/PAM solution. Verify your requirements and OCI capabilities in official docs.

8) What determines whether my SSH connection is allowed?

Three main layers: – IAM permission to create/use sessions – Bastion client CIDR allowlist – Network rules (NSGs/security lists) between bastion subnet and the target

9) Why does Bastion require a subnet association?

The subnet defines the network placement/path Bastion uses to reach private targets inside your VCN.

10) Should my bastion subnet be public or private?

A common best practice is private. Bastion does not require your targets to be in public subnets. Confirm any region-specific recommendations in the docs.

11) How do I restrict access to only my corporate office network?

Set the client CIDR allowlist to your corporate egress NAT IP ranges and restrict IAM session creation to approved groups.

12) Can multiple teams share one Bastion?

Yes, but governance matters. Use compartments, IAM, and tags to prevent cross-team access issues.

13) What happens when the session TTL expires?

The session ends and your connection is terminated. Plan TTL to match maintenance windows.

14) Can I automate Bastion session creation?

Yes, via OCI APIs/CLI/SDKs, subject to IAM policies. Always enforce TTL and auditing.

15) Why can’t I connect even though the session is Active?

Most commonly: – wrong OS username – wrong SSH key – NSG/security list does not allow bastion subnet to reach target on required port – client IP not in allowlist

16) Can Bastion access targets in a different VCN?

Potentially, if networking is configured (peering/DRG) and routing/security rules allow it. Validate architecture and security carefully.

17) Is Bastion suitable for production?

Yes, commonly. Use strong IAM, short TTL, strict allowlists, and comprehensive logging.

17. Top Online Resources to Learn Bastion

Resource Type Name Why It Is Useful
Official documentation OCI Bastion Documentation Canonical features, concepts, and configuration guidance: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm
Official pricing Oracle Cloud Price List Verify Bastion SKUs and region pricing: https://www.oracle.com/cloud/price-list/
Pricing calculator OCI Cost Estimator Build scenario-based estimates: https://www.oracle.com/cloud/costestimator.html
IAM policies reference OCI Policy Reference Correct policy syntax and permissions: https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/policyreference.htm
CLI install guide OCI CLI Installation Automate session lifecycle: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
Service limits OCI Service Limits Understand quotas for bastions/sessions: https://docs.oracle.com/en-us/iaas/Content/General/Concepts/servicelimits.htm
Free tier Oracle Cloud Free Tier Check if Bastion or related resources are included: https://www.oracle.com/cloud/free/

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps engineers, SREs, platform teams DevOps/cloud operations foundations, hands-on practices Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers SCM, DevOps tooling, cloud fundamentals Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud ops practitioners Operations, monitoring, reliability practices Check website https://www.cloudopsnow.in/
SreSchool.com SREs, operations teams SRE principles, incident response, reliability Check website https://www.sreschool.com/
AiOpsSchool.com Ops and automation teams AIOps concepts, automation, observability Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud training content Engineers seeking guided training https://www.rajeshkumar.xyz/
devopstrainer.in DevOps tooling and practices Beginners to intermediate DevOps engineers https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps support/training Teams needing practical implementation guidance https://www.devopsfreelancer.com/
devopssupport.in Operational support and training resources Ops teams and engineers https://www.devopssupport.in/

20. Top Consulting Companies

Company Name Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps services Architecture, implementation, operationalization Designing private network access with Bastion; securing admin access workflows https://cotocus.com/
DevOpsSchool.com DevOps consulting and enablement Training + implementation support Building standardized Bastion access runbooks; IAM policy design reviews https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting Cloud ops and DevOps process help Bastion adoption planning; CI/CD operational access patterns https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Bastion

  • OCI fundamentals: compartments, regions, availability domains
  • OCI Networking basics:
  • VCNs, subnets, route tables
  • security lists vs NSGs
  • private vs public subnets
  • Linux SSH basics:
  • key pairs, authorized_keys, ssh-agent
  • troubleshooting SSH connectivity
  • OCI IAM basics:
  • groups, dynamic groups (conceptually), policies

What to learn after Bastion

  • Hybrid networking: DRG, VPN Connect, FastConnect
  • Centralized logging/monitoring and SIEM integration
  • OS hardening and configuration management
  • Privileged access management (PAM) patterns (beyond basic bastion)
  • Zero-trust access patterns and strong identity controls

Job roles that use it

  • Cloud engineer / cloud operations engineer
  • Site Reliability Engineer (SRE)
  • DevOps engineer
  • Platform engineer
  • Security engineer (cloud security)
  • Solutions architect

Certification path (if available)

Oracle certifications change frequently. Look for OCI certifications covering networking and security, and verify current tracks on Oracle University: – https://education.oracle.com/

Project ideas for practice

  • Build a “private-only” OCI environment with Bastion-based access and strict NSGs.
  • Implement short TTL session patterns and tag sessions by ticket ID.
  • Create a standard runbook for break-glass access and audit review.
  • Extend to port forwarding for private database administration (in a sandbox).

22. Glossary

  • Bastion: A controlled entry point used to access private network resources, typically via SSH.
  • OCI Bastion: Oracle Cloud managed service providing session-based SSH access and port forwarding to private targets.
  • VCN (Virtual Cloud Network): OCI’s virtual network construct similar to a virtual private cloud.
  • Subnet: A segmented IP range within a VCN.
  • Private subnet: Subnet where instances typically do not have public IPs.
  • NSG (Network Security Group): Stateful virtual firewall rules applied to VNICs/resources.
  • Security list: Subnet-level firewall rules (another OCI security control).
  • CIDR allowlist: IP ranges allowed to initiate Bastion access.
  • Session TTL: Time-to-live; how long a Bastion session remains valid.
  • Managed SSH session: Bastion session type used to SSH to a private compute instance.
  • Port forwarding session: Bastion session type used to tunnel TCP traffic to a private IP:port.
  • IAM policy: Authorization rules defining who can perform actions on OCI resources.
  • Compartment: A logical isolation boundary for organizing and securing OCI resources.
  • Audit: OCI service that captures control-plane API events for governance and investigations.

23. Summary

Oracle Cloud Bastion (in the Security, Identity, and Compliance category) is a managed way to access private OCI resources using time-bound SSH sessions and SSH port forwarding, without exposing targets to the public internet or maintaining jump hosts.

It fits best when you want private-by-default networking, strong IAM governance, short-lived admin access, and auditable session lifecycle events. Cost is typically driven by session usage and duration, so optimize with short TTLs and disciplined operational workflows.

Next step: implement Bastion in a non-production compartment first, standardize IAM + NSG patterns, and validate your audit/log review process using the official Bastion documentation: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm