OCI Instance Containers are the OCI way of saying “I have a Container… please run it for me…” The idea is that you don’t have to worry about the underlying resources. It’s serverless containers. Getting your container up and running is extremely simple. Assuming you already have a container published and a VCN created in your account, a container instance will be up and running in a matter of minutes.

The challenge comes in when you want to access other OCI resources from your container. You do not want to embed credentials into your container definition. The answer is: Resource Principal Authentication!

What is Resource Principal Authentication?

Resource Principal Authentication is a way that you can give a Resource (Your container instance) access to other services running inside of your OCI account, securely, without having to provide credentials. By using constructs like Dynamic Groups and OCI IAM Policies, your container instances gain secure access to your account, without having to have user names, passwords, or certificates embedded in your container to go stale.

Setting up Resource Principal Authentication for a container instances is a pretty straight forward process that can be accomplished in a few minutes.

Create a Dynamic Group

The first step in setting up Resource Principal Authentication is setting up a Dynamic Group to assign permissions to. The dynamic group is set up in your domain, and uses a matching rule:

ALL {resource.type='computecontainerinstance', resource.compartment.id = '{Compartment OCID}'}

In this case I have used a compartment filter as a limiting filter. You can use any supported limiting factor you like. The critical aspect is using “computecontainerinstance” as your type.

Create a policy

The next step is to define a policy that provides access to the resources you need. For example if I want my container instance to have permissions to send messages to a stream:

Allow dynamic-group '{Domain}'/'{Dynamic Group Name}' to use stream-push in compartment {Compartment Name}

Keep in mind that a single policy can have multiple statements, so combine all the permission that you need for your container into a single policy for east of management.

Warning: Keep in mind that the policies that you attach to the dynamic group will apply to the instance. This means that it doesn’t matter who is using your application, they will have access to these permissions. Always name sure to follow the principals of least privilege, and separate out the permissions that your container needs, from those of your users.

Writing the code…

Of course it all comes down to the code at the end of the day. In order to make sure you leverage the resource principal authentication, you need to create an Authentication Details Provider that takes the Resource Principal into account.

var _config = ResourcePrincipalAuthenticationDetailsProvider.GetProvider();

This config object will be created, with temporary credentials that have access, according to the policies, to your OCI account. You can then use this object to create the necessary client objects to perform any interactions you need.

var client = new Oci.SecretsService.SecretsClient(_config);

Once you have done this, your code will be able to access the resources you have deployed in your account without any further action required. The items outlined in red below are retrieved form an OCI Vault in my account:

Summary

Using Resource Principal authentication with your container instances is a very easy, an d secure way to provide access to resources in your account. The process requires only a few steps, and will have you up and running in minutes.

It is important however to carefully plan out the permissions that you want to assign to your container vs the permissions that you want to assign to your users. Resource Principal Authentication has no knowledge of the person using your application.

Because this method uses Dynamic Groups, you can update the permissions assigned to the container without having to make any changes to the the running container itself.