OCI Bastion Service for Secure Access

Private resources are private for a reason. A database or an application server with no public address cannot be reached directly from the internet, which is exactly the protection you want. But people still need to reach those resources occasionally, for maintenance, for troubleshooting, for an emergency fix, and how they do that has historically been one of the weakest points in cloud security. The OCI Bastion service exists to make that access secure, time limited, and recorded, so the act of reaching a private resource stops being the hole in your defences.

The old pattern was a jump host, a permanently running machine with a public address that administrators connected to first and then hopped from to reach private resources. It worked, but it was a standing target. It ran all the time whether anyone needed it or not, it needed patching and hardening, and its open port was a permanent invitation. The Bastion service removes that standing target by providing access on demand instead of access always on.

How the Bastion service works

Rather than a permanent machine, the Bastion service creates a session when you need one and tears it down when you are done. You request a session to reach a specific private resource, the platform sets up a secure tunnel for a limited time, you do your work, and the session expires. There is no permanent open port, no always running host to maintain, and no standing target for an attacker to probe. Access exists only when it is needed and only for as long as it is needed.

Because the session is created through the platform, it is governed by the same identity controls as everything else, so who can create a bastion session is decided by policy as described in our IAM policies guide. And because every session is a platform action, it is recorded in the audit trail covered in our audit and logging guide, so you have a record of who reached what and when.

Why this is more secure

The security gain comes from three properties working together. Access is time limited, so a session does not linger as a way in after the work is done. Access is governed, so only the right people can create a session to the right resource. And access is recorded, so there is an audit trail of every privileged connection. Compare that to a jump host, which is always available, often shared, and frequently under monitored, and the difference in exposure is large.

Using it well

The service does the heavy lifting, but a few practices make it genuinely strong. Keep the right to create sessions tightly scoped, so only the people who need privileged access have it, and so the resources they can reach are limited to what their role requires. Keep session durations short, long enough to do the work but not so long that a forgotten session becomes a risk. And review the audit trail of sessions periodically, because the record only protects you if someone occasionally looks at it.

The Bastion service works best as one part of a layered access design. Network rules, covered in our NSGs and security lists guide, still decide which traffic the target resource accepts. The bastion does not replace those rules, it gives you a secure, governed way to reach the resource within them. Together they let you keep resources truly private while still being able to reach them safely when you must.

Session types and what they suit

The service supports more than one style of session, and choosing the right one matters for both security and convenience. One style gives you a direct tunnel to a port on a target resource for the duration of the session, which suits administrative access to a machine you manage. Another style is more tightly bound to a managed instance through its own agent, which can be appropriate where you want the access to be mediated even more closely. The point is not to memorise the variants but to recognise that the service is flexible enough to fit different access needs, and that picking the session type deliberately keeps each kind of access as narrow as the task requires rather than defaulting everyone to the broadest option.

Whatever style you use, the operational habit that matters most is treating bastion access as exceptional rather than routine. If your team finds itself creating sessions constantly to do ordinary work, that is usually a sign that the work should be automated or that the resource should expose a managed interface, rather than that privileged human access should become a daily habit. The healthiest estates use the bastion for the genuine exceptions, the troubleshooting and the rare manual fix, and handle the routine through pipelines and managed tooling that never need a person to reach inside a private resource at all. That keeps the volume of privileged access low, which keeps the audit trail meaningful and the risk small.

Bringing it together

The Bastion service turns one of the oldest weak spots in cloud security, the standing jump host, into access that exists only on demand, only for the people allowed, and only for as long as the work takes, with a record of every session. Prefer it over permanent jump hosts, scope who can connect and to what, keep sessions short, pair it with tight network rules, and review the trail. Done that way, reaching a private resource stops being a risk and becomes a controlled, audited event. The network side is in our NSGs and security lists guide, the full model is in our complete security guide, and our IAM and security practice designs access models like this for clients.