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

1. Introduction

What this service is

In Oracle Cloud (Oracle Cloud Infrastructure / OCI), “Managed Access” commonly refers to Oracle’s managed approach for providing secure, time-bound administrative access to private cloud resources (for example, SSH access to Compute instances that do not have public IP addresses). In current OCI documentation and the OCI Console, this capability is typically implemented by the OCI Bastion service. If your service catalog, internal naming, or training plan uses “Managed Access,” verify whether it maps to Bastion in your tenancy and region.

Simple explanation (one paragraph)

Managed Access lets you connect to private resources in Oracle Cloud without deploying and maintaining a traditional jump host. Instead of opening inbound ports to the internet or keeping a permanently reachable bastion VM, you create just-in-time sessions that expire automatically and are governed by IAM policies and audit logs.

Technical explanation (one paragraph)

Managed Access (OCI Bastion) is a regional managed service that provides controlled connectivity from an Oracle-managed bastion endpoint to targets in your VCN using a dedicated “bastion subnet”. Users create Bastion sessions (for example, managed SSH or SSH port forwarding) that are authorized by OCI IAM, constrained by duration and (optionally) client source IP ranges, and recorded in OCI Audit. Network access from the bastion subnet to target subnets is governed by NSGs/Security Lists.

What problem it solves

Managed Access solves the classic “secure admin access” problem:

You need SSH (or access to private ports) to instances or services on private subnets.
You do not want public IPs, broad inbound rules, or a long-lived jump host.
You need least privilege, time-bound access, governance, and auditability.

Renaming/Scope note: If you don’t see a service literally named “Managed Access” in the OCI Console, look for Bastion under Security, Identity, and Compliance. Verify in official docs whether “Managed Access” is a legacy label or an internal service catalog name in your organization.

2. What is Managed Access?

Official purpose

Managed Access in Oracle Cloud is the controlled, audited, just-in-time access pattern for reaching private resources—most commonly delivered via OCI Bastion.

Official OCI Bastion documentation home (use this as the canonical reference for current behavior and terminology):
https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm

Core capabilities

Managed Access typically provides:

Just-in-time access via expiring sessions
No public IP requirement on targets
Centralized governance through IAM policies, compartments, and tags
Auditability (session creation and lifecycle events via OCI Audit)
Two common session modes (verify names in your region/tenancy):
Managed SSH sessions to connect to port 22 on a target
SSH port forwarding sessions to reach other private ports through an SSH tunnel

Major components

When implemented via OCI Bastion, the core components are:

Bastion: A managed resource in a compartment, associated with a VCN subnet (“bastion subnet”)
Bastion subnet: A dedicated subnet in your VCN used by the service to reach targets
Session: A time-bound access grant (managed SSH or port forwarding)
Target resource: Usually a private Compute instance (or a private IP/port reachable from the bastion subnet)
IAM policies: Control who can create bastions and sessions
Network security: NSGs/Security Lists allow traffic from the bastion subnet to targets

Service type

Managed security access service (part of Security, Identity, and Compliance) that depends on your VCN for private reachability.

Scope (regional/global/etc.)

Regional: Bastion resources are created in a specific OCI region and attach to a subnet in that region’s VCN.
Compartment-scoped for administration and access control: you create and manage bastions and sessions in compartments (with IAM policies).

How it fits into the Oracle Cloud ecosystem

Managed Access is usually a foundational control in OCI landing zones and secure architectures:

Works alongside OCI IAM (users, groups, dynamic groups, policies)
Complements VCN design (private subnets, NSGs, route tables)
Supports security posture goals typically managed via Cloud Guard, Security Zones, and Audit
Often used with Vault (for key/secrets management) and OS-level hardening (CIS benchmarks)

3. Why use Managed Access?

Business reasons

Lower operational burden: no need to run, patch, monitor, and scale bastion VMs.
Reduced risk: fewer publicly exposed resources and fewer persistent access paths.
Better auditability and governance: supports internal controls and compliance narratives (who requested access, when, for how long).

Technical reasons

No public IP on targets: keep compute instances and internal services private.
Time-bound sessions: reduce the risk of forgotten access paths.
Supports private ports via tunneling: access internal services without opening wide network rules.

Operational reasons

Centralized access control: IAM policies define who can create sessions, in which compartments.
Standardized access workflow: a consistent, repeatable pattern for engineers and SREs.
Segmentation-friendly: align bastions to environments (dev/test/prod) and network zones.

Security/compliance reasons

Least privilege: create sessions only when needed and for limited duration.
Audit trail: session creation and management are logged in OCI Audit.
Network controls: NSGs and subnet rules can limit access to known paths.

Scalability/performance reasons

Eliminates the need to scale bastion hosts to handle concurrent admins (the managed service handles the control plane; capacity characteristics should be verified in official docs for any concurrency limits).

When teams should choose it

Choose Managed Access when:

Your workloads are in private subnets
You require secure administrative access (SSH and/or port tunneling)
You want time-bound, auditable access without managing jump hosts
You’re implementing a secure OCI landing zone or regulated environment

When they should not choose it

Managed Access may not be the best fit when:

You require full session recording (keystroke capture) for every admin action; OCI Bastion focuses on session management and audit of session lifecycle rather than full command capture (verify in official docs).
You need protocol support beyond SSH/tunneling and cannot adapt (for example, specialized admin protocols).
Your environment requires an on-prem broker with custom controls not supported by OCI-native managed access patterns.
You already have a standardized enterprise solution (e.g., PAM) and OCI Bastion is redundant—though it can still be used as a transport layer.

4. Where is Managed Access used?

Industries

Financial services: controlled admin access, separation of duties, audit readiness
Healthcare: private network access patterns and minimal public exposure
Public sector: tight control over administrative connectivity
SaaS providers: secure operations access to production clusters
Retail and e-commerce: secure operations access during incident response

Team types

Platform engineering / cloud engineering
DevOps and SRE teams
Security engineering and compliance teams
Operations and NOC teams
Developers working on private environments (with guardrails)

Workloads

Private Compute instances (Linux)
Internal API services reachable only via private IPs
Databases and admin ports accessed through SSH tunneling (e.g., 1521, 5432, 3306)
Kubernetes worker node access patterns (with strict governance; verify best practice for your cluster)

Architectures

Hub-and-spoke VCN designs (centralized access controls)
Multi-environment compartments (dev/test/prod)
Zero-trust-like segmentation where admin paths are explicit and time-bound

Real-world deployment contexts

Production: tightly controlled, minimal session duration, strict IAM, NSG restrictions, and mandatory auditing
Dev/test: similar pattern but typically less restrictive; still recommended to avoid public IPs and ad-hoc SSH exposure

5. Top Use Cases and Scenarios

Below are realistic scenarios that align well with Managed Access (OCI Bastion). Each use case includes the problem, why this service fits, and an example.

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

Problem: Engineers need shell access to troubleshoot a private VM.
Why it fits: Managed, time-bound SSH session without exposing port 22 publicly.
Example: A production app server sits in a private subnet; SREs open a 30-minute session for patch validation.

2) Port forward to a private database for diagnostics

Problem: DBAs need to run a query tool from their workstation, but the DB is private.
Why it fits: SSH port forwarding session provides temporary connectivity to DB port.
Example: Forward local port 15432 to private PostgreSQL port 5432 for schema inspection during incident triage.

3) Secure break-glass access during incident response

Problem: Emergency access must be fast, controlled, and auditable.
Why it fits: Create just-in-time sessions with short duration and strict IAM.
Example: On-call engineer creates a 15-minute session to inspect logs on a private VM after an alert.

4) Replace self-managed jump boxes

Problem: Jump hosts require patching, hardening, monitoring, and can become a security liability.
Why it fits: Managed service avoids persistent jump host VMs.
Example: A company decommissions a fleet of bastion VMs and standardizes on managed sessions.

5) Enforce environment separation (dev vs prod)

Problem: Teams accidentally access the wrong environment.
Why it fits: Compartment-scoped bastions and IAM policies enforce boundaries.
Example: Separate bastions in dev and prod compartments; only prod on-call group can create prod sessions.

6) Vendor or partner access with strict constraints

Problem: Third parties need limited access to specific systems.
Why it fits: Short-lived sessions, scoped to specific targets and ports; optional client IP restrictions (verify).
Example: A vendor gets 1-hour access to a specific VM for troubleshooting, only from the vendor’s office CIDR.

7) Access internal admin UIs without exposing them publicly

Problem: Internal tools (e.g., admin panels) should not be internet-facing.
Why it fits: Use port forwarding to reach internal HTTP services temporarily.
Example: Forward localhost:8443 to an internal admin UI on 10.0.2.10:8443.

8) Support hardened network designs (no inbound from internet)

Problem: Security policy forbids inbound internet access to workloads.
Why it fits: Targets remain private; access is brokered by the managed service.
Example: A regulated workload uses only private subnets and denies all inbound from public internet.

9) Standardize access workflows for compliance audits

Problem: Auditors require evidence of controlled admin access.
Why it fits: IAM policy + Audit logs show who created sessions and when.
Example: Security team pulls Audit records for bastion session events during a SOC2 audit.

10) Temporary access for migration or cutover tasks

Problem: Migration team needs limited access during a narrow cutover window.
Why it fits: Session duration matches change window; reduces lingering access.
Example: A 2-hour session to validate application configuration post-migration.

11) Private access to Kubernetes worker nodes (controlled)

Problem: Node-level debugging is occasionally required but shouldn’t be always open.
Why it fits: Time-bound SSH access (where allowed by cluster policy).
Example: SREs create sessions only during node drain/repair events (verify your organization’s Kubernetes hardening stance).

12) Reduce attack surface in multi-tier apps

Problem: App tiers should not be reachable from the internet, including admin ports.
Why it fits: Bastion sessions allow admin access without changing the exposure model.
Example: Web tier is public via LB; app and DB tiers are private and only reachable via Managed Access sessions.

6. Core Features

Feature availability can vary by region and tenancy configuration. Always confirm in the official OCI Bastion documentation: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm

1) Managed bastion resource (no bastion VM to maintain)

What it does: Provides a managed control plane to broker admin access to private targets.
Why it matters: Eliminates patching/hardening/monitoring a jump host VM.
Practical benefit: Fewer moving parts and fewer persistent internet-facing assets.
Caveat: You still must design VCN subnets and NSGs correctly; the service doesn’t replace network security hygiene.

2) Just-in-time, time-bound sessions

What it does: Sessions are created for a defined duration and expire automatically.
Why it matters: Reduces standing privileges and long-lived access paths.
Practical benefit: Cleaner compliance posture and reduced risk from forgotten access.
Caveat: During outages, ensure your break-glass process and IAM policies allow rapid session creation (without being overly permissive).

3) Managed SSH sessions (typical primary workflow)

What it does: Enables SSH to a private target, typically on port 22.
Why it matters: SSH is the default admin protocol for Linux and many appliances.
Practical benefit: Access private instances without public IPs.
Caveat: Still requires OS-level user access and SSH configuration; the service doesn’t replace OS hardening.

4) SSH port forwarding sessions

What it does: Creates an SSH tunnel so you can reach private ports (DB ports, internal APIs, admin endpoints).
Why it matters: Lets you debug and administer private services securely.
Practical benefit: Avoids exposing internal services via public load balancers or temporary firewall changes.
Caveat: Tunneling can be misused. Keep session durations short and restrict to specific targets/ports where possible.

5) IAM-based authorization and compartment governance

What it does: Uses OCI IAM to define who can create/manage bastions and sessions.
Why it matters: Central control, consistent across OCI services.
Practical benefit: You can separate duties (admins who manage bastions vs users who create sessions).
Caveat: Mis-scoped IAM policies can allow overly broad access. Prefer compartment-level scoping and least privilege.

6) Network security via VCN, subnets, NSGs, and route tables

What it does: Requires explicit network connectivity from bastion subnet to target subnet/NSG.
Why it matters: Keeps access paths explicit and reviewable.
Practical benefit: You can tightly constrain traffic: only from bastion subnet CIDR to target port(s).
Caveat: Most connectivity failures are network-rule related. Plan NSGs early and test.

7) Auditability via OCI Audit (session lifecycle)

What it does: Records API events such as bastion and session creation/deletion in OCI Audit.
Why it matters: Central audit trail for access grants.
Practical benefit: You can answer “who created access, when, and to what target.”
Caveat: Audit logs typically record metadata and API events, not necessarily full keystroke logs of what happened inside the OS. Verify what is and isn’t captured in your environment.

8) Tagging and compartment organization

What it does: Supports OCI tagging and compartment placement (typical OCI resource governance).
Why it matters: Enables cost allocation, ownership tracking, and policy boundaries.
Practical benefit: Standardize naming and tags for security review and operational clarity.
Caveat: Tag enforcement depends on your governance processes and (optionally) tag defaults.

7. Architecture and How It Works

High-level service architecture

At a high level, Managed Access (OCI Bastion) works like this:

You create a Bastion resource in a compartment and attach it to a bastion subnet in your VCN.
An authorized user creates a session that targets a private resource (typically a private IP/port).
The user connects using SSH (or SSH tunnel) to an Oracle-managed endpoint for that session.
The service bridges the connection into your VCN via the bastion subnet to reach the target.

Request/data/control flow

Control plane:
Create bastion, create session, manage lifecycle via OCI Console/CLI/API.
All control plane actions are subject to IAM authorization and recorded in Audit.
Data plane:
The SSH stream (and port-forwarded traffic) is tunneled through the bastion session to the private target.
Your VCN security rules govern whether the bastion subnet can reach the target.

Integrations with related services

Common integrations/patterns:

OCI IAM: users, groups, policies, compartments
VCN: subnets, NSGs, route tables
OCI Audit: API event logging
Logging/Monitoring:
Bastion/session lifecycle events: primarily via Audit
OS-level logs: via your host logging agents or OCI Logging (if configured)
Vault:
Not required for Bastion itself, but often used to manage secrets/keys used by your operational tooling
Cloud Guard / Security Zones:
Use for governance and posture management (ensure your architecture is compatible with the constraints you enable)

Dependency services

VCN networking: subnets, routing, and security rules
Compute (for the most common target type)
IAM and Audit

Security/authentication model

Authentication to OCI: Users authenticate to OCI Console/CLI via IAM (or federation).
Authorization: IAM policies control ability to create/manage bastions and sessions.
Authentication to target:
Commonly via SSH keys and OS users on the target VM.
The bastion service facilitates connectivity; OS-level access is still governed by sshd configuration and OS accounts.

Networking model

The bastion is associated with a subnet in your VCN (“bastion subnet”).
The target must be reachable from the bastion subnet by routing and allowed by NSGs/Security Lists.
The user does not need direct network reachability to the target; they only need to reach the service endpoint for the session.

Monitoring/logging/governance considerations

Audit: Your primary source for bastion/session administrative events.
Operational monitoring: Most failures show up as “connection failed” in the client; correlate with:
Session status in Console
NSG/Security List rules
Target instance OS logs (/var/log/auth.log or /var/log/secure depending on distro)
Governance:
Use compartments to separate environments.
Use tags for ownership, environment, and cost tracking.

Simple architecture diagram (Mermaid)

flowchart LR
  U[Engineer Workstation] -->|Create session (IAM)| OCI[OCI Control Plane]
  U -->|SSH to session endpoint| BE[Bastion Endpoint (Oracle-managed)]
  BE -->|Private connectivity| BS[Bastion Subnet in VCN]
  BS -->|Allowed by NSG/SecList| T[Private Compute Instance (no public IP)]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Org["Enterprise / Team"]
    IdP[Enterprise IdP\n(SAML/OIDC Federation)]
    Users[Admins / SREs / DBAs]
  end

  subgraph OCI["Oracle Cloud (OCI) - Region"]
    IAM[OCI IAM\nUsers/Groups/Policies]
    Audit[OCI Audit]
    subgraph Net["VCN (Hub/Spoke or Single VCN)"]
      subgraph Access["Access Zone"]
        Bastion[Managed Access (OCI Bastion)\nBastion Resource]
        BastionSubnet[Bastion Subnet\n(Private)]
      end

      subgraph App["Workload Zone"]
        NSG1[NSG: App]
        VM1[Compute: App VM\nPrivate IP only]
        NSG2[NSG: DB]
        DB[(Database Service or DB VM)\nPrivate Endpoint]
      end
    end
  end

  Users --> IdP --> IAM
  IAM -->|Authorize| Bastion
  Bastion --> Audit

  Users -->|SSH / Tunnel| Bastion
  Bastion --> BastionSubnet
  BastionSubnet -->|NSG rules| VM1
  BastionSubnet -->|Port forward| DB

8. Prerequisites

Tenancy and account requirements

An Oracle Cloud tenancy with access to OCI Console.
Ability to create or use:
VCN and subnets
Compute instance (for the lab target)
Bastion (Managed Access) resources

Permissions / IAM roles

You need IAM permissions to manage:

Networking resources (VCN, subnets, NSGs) or access to an existing network.
Compute instances or access to an existing target instance.
Bastion/Managed Access resources and sessions.

OCI IAM policies are explicit and tenancy-specific. Use the official Bastion IAM/policy documentation to assign correct permissions (recommended):
https://docs.oracle.com/en-us/iaas/Content/Bastion/Reference/bastionpolicyreference.htm (Verify this exact URL/path in official docs; if it changes, navigate from the Bastion docs home.)

Billing requirements

Most networking primitives have no direct hourly fee, but compute instances do.
Managed Access (OCI Bastion) pricing may be no additional charge or usage-based depending on current Oracle pricing policies—verify in the official pricing pages before production rollout.

Tools needed

OCI Console (web)
SSH client:
macOS/Linux: ssh (OpenSSH)
Windows: OpenSSH (built-in) or PuTTY
Optional:
OCI Cloud Shell (convenient for SSH without local setup)
OCI CLI (only if you want automation; not required for this tutorial)

Region availability

Service availability can differ by region. Confirm your region supports Bastion/Managed Access by checking the OCI Console “Create” menus or the service documentation.

Quotas/limits

Bastion/session limits exist (number of bastions per compartment, sessions per bastion, session duration caps, etc.). These can vary.
Check “Service Limits” in OCI for Bastion and validate maximums for your target concurrency.

Prerequisite services

VCN with:
A bastion subnet
A target subnet for private resources
A target resource (for this lab: a private Linux VM)

9. Pricing / Cost

Oracle pricing changes over time and can be region- and contract-dependent. Do not rely on third-party numbers. Verify in official sources.

Current pricing model (how to validate)

Use Oracle’s official pricing and cost tools:

OCI Pricing page (entry point): https://www.oracle.com/cloud/price-list/
OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html

Then search for Bastion or the relevant service name used by Oracle for “Managed Access.”

Pricing dimensions (typical considerations)

Depending on Oracle’s current pricing for Bastion/Managed Access, cost may be:

No additional charge for the Bastion service itself (common for some managed security control planes), or
Charged by session-hours, bastion-hours, or another usage metric (verify).

Even if the service itself is free, your architecture still incurs costs:

Compute: instances you access (lab and production)
Network egress: data transfer out of OCI to the internet (for large port-forwarded transfers)
Logging: if you export/retain Audit logs or host logs beyond free allocations
Security tooling: Cloud Guard or third-party SIEM ingestion (if applicable)

Free tier

OCI Free Tier eligibility often applies to certain Compute shapes and networking usage, but does not automatically guarantee that every security service is free. Confirm:

Always Free resources: https://www.oracle.com/cloud/free/
Bastion/Managed Access pricing in the price list

Cost drivers

Session usage patterns: long-lived tunnels or many concurrent sessions can increase costs (if session-based billing applies).
Data volume through tunnels: port forwarding large datasets can cause egress charges if data leaves OCI.
Operational tooling: log retention, SIEM ingestion, and monitoring.

Hidden or indirect costs

Engineer time: misconfigured NSGs and IAM can cause productivity loss. Standardize patterns.
Key management overhead: managing SSH keys and OS users still matters; consider automation and centralized identity patterns.

Network/data transfer implications

SSH itself is low bandwidth, but port forwarding to services (especially downloading logs/dumps) can generate meaningful data transfer.
If traffic goes from OCI to the public internet (to your laptop), it may count as outbound data transfer.

How to optimize cost

Prefer short session durations and require re-authorization for extensions.
Use Cloud Shell where appropriate to reduce local setup friction (cost-wise it doesn’t remove egress, but can simplify operations).
Avoid moving large datasets over SSH tunnels; use object storage or internal transfer mechanisms when possible.
Separate dev/test from prod to prevent accidental high-volume transfers from prod.

Example low-cost starter estimate (conceptual)

A low-cost lab typically includes:

1 Always Free eligible compute instance (if available in your region)
1 VCN with private subnets (no direct cost)
Bastion/Managed Access sessions (verify if billed; may be no charge)

Your main variable is compute and any data egress during testing.

Example production cost considerations (conceptual)

In production, cost planning should include:

Expected number of engineers and average session duration
Peak incident-response concurrency
Port forwarding volume (especially if exporting data outside OCI)
Centralized logging retention and SIEM costs

10. Step-by-Step Hands-On Tutorial

This lab shows a practical and safe baseline: SSH into a private VM (no public IP) using Managed Access (OCI Bastion).

Objective

Create a private compute instance and access it securely using Managed Access sessions without exposing the instance to the internet.

Lab Overview

You will:

Create a VCN with two private subnets: – Bastion subnet (used by Managed Access) – Target subnet (where the VM lives)
Create a private Linux VM (no public IP)
Create a Managed Access (Bastion) resource
Create a managed SSH session
Connect to the private VM through the session
Validate that direct public SSH is not possible
Clean up

Notes: – Exact console labels can change. If you see “Bastion” rather than “Managed Access,” use “Bastion”—that is the official OCI service name in most tenancies. – Choose “Always Free Eligible” options where available to keep costs low.

Step 1: Create (or choose) a compartment

In the OCI Console, open the navigation menu.
Go to Identity & Security → Compartments.
Create a new compartment, for example: lab-managed-access.
Record the compartment name.

Expected outcome: A dedicated compartment for the lab resources.

Step 2: Create a VCN with two private subnets

Go to Networking → Virtual Cloud Networks.
Click Create VCN.
Choose VCN with Internet Connectivity only if you want NAT/IGW created automatically.
For a strict-private lab, you can still use the wizard and later ensure the instance has no public IP.
Name the VCN: vcn-managed-access-lab.
Create or confirm these subnets (names are examples): – subnet-bastion-private (private) – subnet-target-private (private)

If the wizard creates public subnets by default, you can still proceed but ensure: – Your target instance is in a private subnet and has no public IP – Your NSG rules are explicit

Expected outcome: A VCN exists with a private subnet for the bastion and a private subnet for the target.

Verification – In the VCN details, confirm both subnets exist and note their CIDR blocks.

Step 3: Create a Network Security Group (NSG) for the target VM

In the OCI Console, go to Networking → Network Security Groups.
Create NSG: nsg-target-ssh.
Add an Ingress rule allowing SSH from the bastion subnet CIDR: – Source type: CIDR – Source CIDR: CIDR of subnet-bastion-private – Protocol: TCP – Destination port: 22

Expected outcome: The target VM will only allow SSH from the bastion subnet path, not from the internet.

Verification – Review NSG security rules and confirm only bastion subnet CIDR is allowed to port 22.

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

Go to Compute → Instances → Create instance.
Name: vm-private-1.
Image: Choose an Oracle Linux image (or Ubuntu if preferred).
Shape: pick an Always Free Eligible shape if available.
Networking: – VCN: vcn-managed-access-lab – Subnet: subnet-target-private – Public IP: Do NOT assign
Add SSH keys: – Generate an SSH key pair locally (recommended), then paste the public key. – Example local generation: bash ssh-keygen -t ed25519 -f ~/.ssh/oci_managed_access_lab -C "managed-access-lab"
Attach NSG: – Add nsg-target-ssh to the instance VNIC.

Expected outcome: A running VM with only a private IP and no inbound access from the public internet.

Verification – On the instance details page: – Confirm Public IP address is empty/not present. – Note the Private IP address (you will use it as the target).

Step 5: Create the Managed Access (Bastion) resource

Go to Security, Identity, & Compliance → Bastion (or your console’s equivalent for Managed Access).
Click Create bastion.
Name: bastion-managed-access-lab.
Select VCN: vcn-managed-access-lab.
Select subnet: subnet-bastion-private.
Create the bastion.

Expected outcome: A bastion resource is created and becomes Active.

Verification – Check bastion lifecycle state is Active/Available. – Note the bastion OCID (useful for troubleshooting).

Step 6: Create a managed SSH session to the private VM

Open your bastion resource.
Click Create session.
Session type: Managed SSH session (wording may vary).
Target: – Target type: usually Compute instance or Private IP – Choose the instance vm-private-1 (if selectable) or input its private IP. – Port: 22
SSH public key: – Use the same public key you used (or a separate one) depending on the workflow your console supports.
Session duration: – Choose a short value (e.g., 30 minutes) for the lab.

Expected outcome: A session is created and becomes Active. The console typically provides an SSH command to copy.

Verification – The session shows Active (or similar). – The console offers connection instructions (SSH command, hostname, username, etc.).

Step 7: Connect to the private VM through Managed Access

Use the connection command provided by the OCI Console for the session (recommended, because it is guaranteed to match current OCI endpoint formats).

On your local machine (macOS/Linux), it will look similar to:

ssh -i ~/.ssh/oci_managed_access_lab <session-username>@<bastion-endpoint-hostname>

Or it may include a ProxyCommand / additional SSH options depending on session type and OCI’s current guidance.

Once connected, run:

hostname
whoami
ip addr | head

Expected outcome: You get a shell on vm-private-1 even though it has no public IP.

Verification – hostname returns your instance hostname. – whoami matches the OS user you used (for example, opc on Oracle Linux images, or ubuntu on Ubuntu images—verify your image defaults in the instance details).

Step 8: Validate that the instance is not directly reachable from the internet

From your laptop, attempt to SSH directly to the instance:

If the instance has no public IP, direct SSH is not possible.
Confirm in the instance details page that there is no public IP.

Expected outcome: There is no direct path from the internet to the private VM; access requires Managed Access.

Validation

Use this checklist:

Bastion resource state is Active.
Session state is Active.
You can connect using the console-provided SSH command.
Instance has no public IP.
NSG allows port 22 only from bastion subnet CIDR.

Troubleshooting

Common issues and fixes:

Session is Active, but SSH times out – Check NSG/security list rules on the target subnet/instance VNIC:
- Ingress TCP/22 must allow source = bastion subnet CIDR
- Ensure route tables allow reachability between bastion subnet and target subnet (same VCN typically works without extra routing).
Permission denied (publickey) – Ensure you used the correct private key (-i ~/.ssh/...). – Ensure the OS username is correct (opc, ubuntu, etc.). – Ensure the target instance has the corresponding public key in ~/.ssh/authorized_keys.
You can’t create bastion/session due to authorization – Your IAM policy may not allow bastion/session management in the compartment. – Ask your tenancy admin to apply the least-privilege policies from the official Bastion policy reference.
Bastion subnet selection issues – Ensure the subnet you selected belongs to the correct VCN and region. – Confirm subnet is not blocked by restrictive security lists that prevent the bastion from reaching targets.
Corporate network blocks SSH – Try using OCI Cloud Shell to run the SSH connection from within OCI’s network environment. – Confirm your organization allows outbound SSH.

Cleanup

To avoid ongoing costs:

Delete the Bastion session(s).
Delete the Bastion resource.
Terminate the Compute instance vm-private-1.
Delete NSGs created for the lab.
Delete the VCN (and its subnets, route tables, gateways) if you created it solely for the lab.
Delete the compartment (only if it’s dedicated and empty).

Expected outcome: No billable resources remain.

11. Best Practices

Architecture best practices

Use a dedicated bastion subnet per environment (dev/test/prod) to simplify NSG rules and audits.
Prefer private subnets for workloads; keep public exposure limited to load balancers or explicitly required endpoints.
In hub-and-spoke designs, decide whether bastions live in a hub VCN (centralized) or per-spoke (segmented). Choose based on blast radius and governance needs.

IAM/security best practices

Enforce least privilege:
Separate roles:
- Bastion administrators (manage bastions)
- Session users (create/use sessions)
Require short session durations, with controlled extension workflows.
Prefer federated identity (SAML/OIDC) and MFA for admin identities.
Use compartments to isolate:
prod vs non-prod
business units
regulated workloads

Cost best practices

Keep sessions short and discourage “always-on” tunnels.
Avoid transferring large datasets through tunnels; use Object Storage or internal transfer patterns.
Periodically review Audit logs and session usage to right-size processes.

Performance best practices

For port forwarding, keep tunnels targeted to necessary ports and services.
Use local tooling responsibly—avoid running heavy queries through tunneled connections that create operational strain.

Reliability best practices

Document break-glass procedures and keep them tested.
Use infrastructure-as-code (where appropriate) to standardize VCN, NSGs, and bastion deployment patterns.

Operations best practices

Standardize naming conventions:
bastion-<env>-<region>
session-<user>-<ticket>
Use tags:
Environment, Owner, CostCenter, DataClassification
Maintain runbooks:
“How to create a session”
“Common connection failures”
“Incident access process”

Governance/tagging/naming best practices

Use tag defaults in compartments when your governance model supports it.
Consider policies that restrict bastion creation to approved compartments.
Periodically review:
bastions that are unused
overly permissive NSG rules
long default session durations

12. Security Considerations

Identity and access model

Access is governed by OCI IAM policies.
Place bastions and targets in compartments aligned to your org structure.
Use group membership or dynamic groups (where appropriate) to keep access maintainable.

Encryption

SSH provides in-transit encryption for session data.
For target services reached through port forwarding (DB connections, HTTPS admin UIs), ensure those services also use TLS where appropriate.

Network exposure

The major security win is removing public IPs and inbound exposure from targets.
Restrict NSG ingress on targets to:
Source = bastion subnet CIDR
Ports = only what’s needed (22, or specific tunneled ports)

Secrets handling

Avoid storing SSH private keys in shared locations.
Use developer workstations with disk encryption and secure key storage.
Consider enterprise key management workflows (for example, storing encrypted keys in a secrets manager) if your policies require it.

Audit/logging

Use OCI Audit for:
Who created a session
When a session was created/ended
Which bastion and target were involved (metadata)
For what happened inside the instance:
Use OS logs (sshd logs) and/or host-based logging agents
Consider centralized log aggregation in OCI Logging or a SIEM

Compliance considerations

Managed Access supports compliance goals like:

Reduced attack surface
Just-in-time privileged access patterns
Auditability of access grants

But compliance often requires additional controls:

MFA and centralized identity
Formal approval workflows (ticketing)
Session recording (if required—OCI Bastion may not provide keystroke capture; verify)

Common security mistakes

Allowing SSH to targets from 0.0.0.0/0 “temporarily” and forgetting to remove it.
Reusing the same bastion for all environments without compartment/policy boundaries.
Not restricting session duration or not reviewing session usage.
Treating bastion access as a replacement for OS hardening and patching.

Secure deployment recommendations

Use separate bastions per environment and restrict IAM accordingly.
Require short TTL for sessions; enforce re-approval if extensions are needed.
Use NSGs and strict source CIDRs from the bastion subnet only.
Keep targets private; avoid public IPs unless absolutely required.

13. Limitations and Gotchas

Validate these against your region’s current OCI Bastion documentation and service limits.

Not a full PAM solution: Managed Access manages connectivity and session lifecycle; it may not provide full privileged access management features like keystroke recording, approval workflows, or password vaulting (verify).
Network rules are the #1 failure point: Missing NSG ingress from bastion subnet to target port is common.
OS-level SSH requirements still apply: Users, keys, file permissions, and sshd config must be correct.
Service limits: Maximum sessions, maximum duration, and per-compartment quotas can constrain incident response if not planned.
Regional scope: Bastion is regional; cross-region access requires region-specific bastions or network design that supports it.
Port forwarding risk: It can unintentionally create broad access to internal services if not controlled.
Endpoint/command formats can change: Always use the OCI Console-provided connection instructions or verify the CLI/API syntax in the latest docs.
Data egress charges: Large transfers over tunnels to the public internet can incur costs.
Security Zones constraints: If you use Security Zones, verify that Bastion and required network configurations are allowed.

14. Comparison with Alternatives

Managed Access (OCI Bastion) sits in a landscape of access patterns and tools.

Alternatives inside Oracle Cloud

Public IP + SSH: simplest but least secure for private workloads.
Self-managed jump host in OCI: flexible but higher ops and security burden.
VPN/FastConnect + private access: good for enterprise connectivity, but still needs a controlled admin access pattern on top.
Third-party PAM (integrated with OCI): broader feature set but more complexity and cost.

Alternatives in other clouds

AWS Systems Manager Session Manager (agent-based): strong for private access without SSH inbound; different model than bastion.
Azure Bastion: managed bastion-like service for RDP/SSH.
GCP IAP TCP forwarding: identity-aware access proxy model.

Open-source / self-managed alternatives

Teleport
HashiCorp Boundary
OpenSSH on hardened bastion hosts
WireGuard-based admin overlay networks

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Managed Access (OCI Bastion)	OCI-native private access to VMs/services	Managed, IAM-governed, time-bound sessions; no jump host VM	May not include full session recording/approvals; requires careful NSGs	You want OCI-native, low-ops private admin access
Self-managed jump host (OCI Compute)	Full control/custom tooling	Flexible; can add proxying, recording, custom controls	Patch/harden/monitor burden; persistent attack surface	You need custom protocol support or tooling not available in managed service
VPN / FastConnect + private SSH	Enterprise connectivity patterns	Strong private connectivity, integrates with corp network	Doesn’t inherently provide JIT/session governance	You already have private connectivity and need network-level access; pair with Managed Access or PAM
Third-party PAM (e.g., enterprise tool)	Strict compliance and governance	Approvals, recording, credential vaulting	Cost and operational complexity	You must meet stringent audit requirements and need full PAM features
AWS SSM Session Manager	AWS workloads	Agent-based, no inbound ports, strong IAM integration	AWS-specific; requires SSM agent and permissions	Your workloads are in AWS and you want agent-based access
Azure Bastion	Azure workloads	Managed RDP/SSH experience	Azure-specific; pricing model differs	Your workloads are in Azure
Teleport / Boundary	Multi-cloud / hybrid	Strong identity integration, auditing, sometimes recording	Must operate and scale platform	You need consistent access across OCI + on-prem + other clouds

15. Real-World Example

Enterprise example: regulated bank operations access

Problem: A bank runs customer-facing services in OCI. Policy forbids public IPs on application servers and requires auditable administrative access with strict separation between dev and prod.
Proposed architecture:
Separate compartments for dev/test/prod
Dedicated VCNs (or network zones) per environment
Managed Access (OCI Bastion) per environment with dedicated bastion subnet
NSGs restrict SSH to app instances only from bastion subnet CIDR
IAM policies:
- Only SRE on-call group can create prod sessions
Central logging strategy:
- OCI Audit forwarded to SIEM
- OS auth logs shipped to centralized logging
Why this service was chosen:
Removes persistent jump hosts
Supports just-in-time access and auditability
Fits OCI native governance model (compartments, IAM)
Expected outcomes:
Reduced attack surface (no public IPs)
Faster audits with clear session creation history
Less ops overhead than managing bastion VMs

Startup/small-team example: SaaS on private subnets

Problem: A startup deploys microservices on private instances and wants a safe, simple way for two engineers to access production during incidents.
Proposed architecture:
Single VCN with private subnets for app and DB
Managed Access (OCI Bastion) in a small “prod” compartment
Session duration defaults to 30 minutes
NSG for instances only allows port 22 from bastion subnet
Why this service was chosen:
Minimal setup and minimal ongoing maintenance
Strong default security posture without building a PAM platform
Expected outcomes:
Secure operational access without public SSH
Quick onboarding of new engineers with standardized access steps

16. FAQ

Is “Managed Access” an official OCI service name?
In many OCI environments, the official service name for managed admin access is Bastion. Some catalogs/training material may refer to it as “Managed Access.” Verify in the OCI Console and official docs: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm
Do my target instances need public IP addresses?
No. A primary benefit is accessing private instances without public IPs.
Do I need to deploy a jump host VM?
Typically no. Managed Access is designed to eliminate self-managed jump hosts for common SSH/tunneling workflows.
What protocols are supported?
Commonly SSH and SSH port forwarding. If you need other protocols, you may tunnel them through SSH if appropriate. Verify protocol support in current docs.
Does it record everything typed during an SSH session?
Generally, OCI Audit records session lifecycle events, not full keystroke capture. For full session recording, you may need host-based tooling or a PAM product. Verify in official docs.
How is access controlled?
Through OCI IAM policies, compartments, and network security rules (NSGs/security lists).
Can I restrict who can create sessions versus who can create bastions?
Yes—this is a recommended practice. Use separate IAM policies and groups.
What is the “bastion subnet” used for?
It provides private network reachability from the managed service into your VCN so it can reach private targets.
Do I need to open port 22 to the internet on my target VM?
No. You should only allow port 22 from the bastion subnet (or its NSG-controlled path).
Can I use Managed Access to reach a database port?
Yes, typically using SSH port forwarding sessions (for example, tunnel to 5432/1521/3306), assuming network rules allow it.
How long should sessions last?
Keep them short (15–60 minutes) and extend only with explicit need. Production often uses shorter durations.
What’s the most common reason sessions fail?
NSG/Security List rules: target port isn’t allowing traffic from the bastion subnet CIDR, or routing is incorrect.
Is Managed Access regional?
Yes, typically bound to a region because it attaches to a VCN subnet in that region.
Can I automate session creation?
Often yes via OCI APIs/CLI/SDKs, but exact commands and parameters should be taken from current official docs.
How do I prove compliance to auditors?
Combine: – OCI Audit logs for session lifecycle events – OS logs for authentication/activity – Change management/ticketing references to show approvals and purpose

17. Top Online Resources to Learn Managed Access

Resource Type	Name	Why It Is Useful
Official documentation	OCI Bastion documentation	Canonical reference for Managed Access behavior, concepts, and workflows: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm
Official documentation (IAM)	Bastion IAM policy reference	Required for correct permissions design (verify the exact page path from docs home). Start at: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm
Official pricing	OCI Price List	Validate whether Bastion/Managed Access is billed and how: https://www.oracle.com/cloud/price-list/
Official cost tool	OCI Cost Estimator	Build a cost model including compute, network egress, and logging: https://www.oracle.com/cloud/costestimator.html
Architecture center	Oracle Architecture Center	Reference architectures and best practices for secure OCI deployments: https://docs.oracle.com/en/solutions/
Official tutorials/labs	Oracle LiveLabs	Hands-on labs; search for “Bastion” or secure access patterns: https://apexapps.oracle.com/pls/apex/f?p=133:1:0
Official videos	Oracle Cloud Infrastructure YouTube	Product walkthroughs and best practices: https://www.youtube.com/@OracleCloudInfrastructure
CLI documentation	OCI CLI docs	Automation reference for OCI services (use for scripting sessions; verify current syntax): https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm
SDK documentation	OCI SDKs	Programmatic control for provisioning and governance: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/sdks.htm
Community learning	OCI blogs and community posts	Useful for practical troubleshooting, but always validate against official docs (start from official OCI blog hub): https://blogs.oracle.com/cloud-infrastructure/

18. Training and Certification Providers

The following institutes are listed as training providers; verify current course offerings directly on their sites.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps/SRE, platform engineers, cloud engineers	OCI DevOps, security operations, infrastructure automation fundamentals	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps practitioners	SCM/DevOps foundations, automation concepts that support secure access operations	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud ops and operations teams	Operational practices, monitoring, reliability, secure access patterns	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, reliability engineers	SRE practices, incident response workflows, access governance patterns	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams adopting AIOps	Observability, operational analytics, incident workflows where managed access is a control	Check website	https://www.aiopsschool.com/

19. Top Trainers

These sites are listed as trainer-related resources/platforms. Confirm specific trainer profiles and OCI coverage on each site.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training and guidance (verify exact focus)	Beginners to intermediate engineers seeking mentorship	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training and coaching	Teams and individuals learning DevOps tooling and practices	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps services/training (verify offerings)	Startups and small teams	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and training resources	Operations teams needing practical support	https://www.devopssupport.in/

20. Top Consulting Companies

The following companies are listed as consulting providers. Validate exact service catalogs and OCI specialization directly with them.

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify specifics)	Secure cloud architecture, migration planning, operational processes	Designing private network access patterns; standardizing bastion session governance	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and training services	Platform engineering enablement, DevOps pipelines, cloud operations	Implementing governed access workflows; building runbooks and automation around OCI access	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify specifics)	CI/CD, infrastructure automation, operational maturity	Secure access design reviews; integrating audit trails into operational compliance	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To use Managed Access effectively in Oracle Cloud, learn:

OCI fundamentals: regions, compartments, IAM basics
Networking: VCNs, subnets, CIDRs, route tables, NSGs, security lists
Linux administration basics:
SSH keys, users, sudo, sshd troubleshooting
Security fundamentals:
least privilege, zero trust concepts, audit logging

What to learn after this service

Infrastructure as Code on OCI:
Terraform for OCI (Resource Manager or self-managed Terraform)
Enterprise identity integration:
SAML/OIDC federation and MFA enforcement
Observability:
OCI Logging, Monitoring, and SIEM integration patterns
Broader security posture:
Cloud Guard, Security Zones, vulnerability scanning
PAM concepts:
approvals, session recording, secrets management (Vault + enterprise tooling)

Job roles that use it

Cloud Engineer / Cloud Operations Engineer
DevOps Engineer
Site Reliability Engineer (SRE)
Security Engineer (cloud security)
Platform Engineer
Solutions Architect

Certification path (if available)

Oracle certifications evolve. Start here and select OCI tracks aligned with security and architecture:

Oracle University (OCI training/certs): https://education.oracle.com/

For Bastion/Managed Access specifically, it’s typically covered inside broader OCI architect/security curriculum rather than as a standalone certification topic.

Project ideas for practice

Secure admin access baseline: Build a private VCN with managed access and strict NSGs; document runbooks.
Port-forwarding toolkit: Create standardized scripts for DB port forwarding with short TTL sessions (validate against official CLI support).
Multi-environment governance: Separate dev/test/prod bastions with compartment policies and tags.
Audit reporting: Export OCI Audit events for session creation into a reporting dashboard or SIEM.
Break-glass design: Implement an emergency access group with strong controls and tested procedures.

22. Glossary

OCI (Oracle Cloud Infrastructure): Oracle Cloud’s infrastructure platform.
Security, Identity, and Compliance: OCI console category grouping security and governance services.
Managed Access: In this tutorial, the managed pattern/service for secure, time-bound access to private resources—commonly implemented as OCI Bastion.
Bastion: OCI managed service that brokers SSH/tunnel access to private targets.
VCN (Virtual Cloud Network): Your private network in OCI.
Subnet: A range of IPs within a VCN; can be public or private depending on routing and access rules.
NSG (Network Security Group): Virtual firewall rules applied to VNICs/resources to control traffic.
Security List: Subnet-level firewall rules (older model; still widely used).
Compartment: OCI logical container for organizing and controlling access to resources.
IAM Policy: Statements that grant permissions to groups/dynamic groups in OCI.
Session (Bastion session): Time-bound access grant for SSH or port forwarding.
Port forwarding: SSH tunneling technique to access private ports through an SSH connection.
Audit (OCI Audit): Service that records API calls and administrative events in OCI.
Private IP: IP address reachable only within private networks (VCN).
Public IP: Internet-routable IP address.

23. Summary

Managed Access in Oracle Cloud (most commonly implemented through OCI Bastion) provides a practical way to enable secure, time-bound, auditable access to private resources without deploying and maintaining jump hosts.

It matters because it reduces attack surface (no public IPs or open inbound SSH), supports IAM-governed access control, and improves compliance posture through auditable session lifecycle events. Architecturally, it fits best in private subnet designs and compartment-based governance models within Security, Identity, and Compliance.

Cost-wise, validate whether the service itself is billed in your region, and always account for indirect costs like compute, logging retention, and data egress. Security-wise, treat network rules and IAM scoping as first-class design elements, and don’t assume it replaces OS hardening or full PAM controls.

Use Managed Access when you need OCI-native private admin access with low operational overhead. As a next step, standardize your deployment via Infrastructure as Code and integrate Audit + OS logs into a centralized observability and compliance workflow.

rajeshkumar

Category