This is a short blog post in an IAM Policy Tips & Techniques series that presents solutions to some of the interesting IAM policy requirements that I’ve been challenged with.

Challenge 

The challenge I was presented with was to write a policy statement that will allow a specific OCI user to create a managed OCI Bastion Service session, while restricting the host OS user that our OCI user is allowed to configure in the Bastion session. Note that the granularity required is not at the group level but rather it’s at the individual OCI user level. 

Solution

A solution is provided by the following policy statement: 

Allow any-user to manage bastion-session in tenancy where all {request.user.id='ocid.xxx.yyy.zzz', target.bastion-session.username='opc', target.bastion.name='apptier-bastion'}

This policy statement allows the OCI user ocid.xxx.yyy.zz to connect to any host that the bastion apptier-bastion can reach with the username “opc”. 

We reference the OCI user’s OCID in the statement because the only OCI general request variable that identifies the requesting user is request.user.id  containing an OCID. This is also the reason why this solution is restricted to native OCI users and  federated provisioned users in accounts without IAM Identity Domains .

Finally, here is an example at the OCI group granularity:

Allow apptier-bastion-users to manage bastion-session in tenancy where all { target.bastion-session.username='opc', target.bastion.name='apptier-bastion'}

Here any member of the apptier-bastion-users group will be able to connect to any host that apptier-bastion can reach with the OS username “opc“