That Finnish Guy

You might have seen dynamic groups mentioned when browsing through OCI console or when you’ve read the documentation. One of the most important things when creating services is handling access to specific services so that your access keys are not compromised.

This is one neat way of managing that in the cloud. Instead of storing keys and passwords on the server where your service is running on you can create a dynamic group which is then linked to specific instances you choose in your compartment. If you’ve used AWS earlier then similar configurations there are called instance profiles.

In OCI the dynamic group is then assigned a policy which determines what the instances in the group can access through API’s. You have option to use variety of different methods such as the OCI SDK’s, oci-cli or even Terraform! Some of the authentication methods are described here.

Testing Dynamic Groups

To test functionality of dynamic groups I’ve created one public instance in OCI and created dynamic group “dynamic-group-test” with a rule that all instances in specific compartment belong to that group. You have possibility to use rule builder for simple rules or then create more complex rules with exclusions or rules based on tags by typing them yourself.

 ALL {instance.compartment.id = 'ocid1.compartment.oc1..xxxxx'} 

After that I’ve created following policy under Policies:

Allow dynamic-group dynamic-group-test to manage buckets in tenancy

That’s a huge privilege to assign for a group! If you are doing a real implementation always go with the least privilege so your systems don’t get wide privileges by default. Even though managing security in cloud is in some ways made lot easier compared to on-premise world it’s one area what is still neglected due to doing it properly will take time and effort. So don’t be that person who skips it!

After logging to my server I installed oci-cli on it to see how can I access object storage. You can install oci-cli using following command:

bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"

Why it’s not pre-installed in OCI compute instances or via yum package is beyond my understanding. Would be great if it gets added! To use oci-cli without doing the setup with your keys you need to use the flag –auth instance_principal.

If I want to query my namespace:

[opc@mydemoserver ~]$ oci os ns get --auth instance_principal
{
  "data": "simodemo"
}

But I can do more as I gave full access to object storage for this instance. So I’ll create a bucket in my compartment:

[opc@myjumpserver ~]$ oci os bucket create --name simo1 --compartment-id ocid1.compartment.oc1..xxxxx --auth instance_principal
{
  "data": {
    "approximate-count": null,
    "approximate-size": null,
    "compartment-id": "ocid1.compartment.oc1..xxxxx",
    "created-by": "ocid1.instance.oc1.eu-frankfurt-1.xxxxx",
    "defined-tags": {},
    "etag": "c77f88e7-1859-422e-af1b-fa1afd8defff",
    "freeform-tags": {},
    "kms-key-id": null,
    "metadata": {},
    "name": "simo1",
    "namespace": "simodemo",
    "object-lifecycle-policy-etag": null,
    "public-access-type": "NoPublicAccess",
    "storage-tier": "Standard",
    "time-created": "2019-04-01T14:56:54.841000+00:00"
  },
  "etag": "c77f88e7-1859-422e-af1b-fa1afd8defff"
}

Works like a charm! But can I do more with oci-cli now such as list all instances running in specific compartment?

[opc@myjumpserver ~]$ oci compute instance list --compartment-id ocid1.compartment.oc1..xxxxx --auth instance_principal
ServiceError:
{
    "code": "NotAuthorizedOrNotFound",
    "message": "Authorization failed or requested resource not found.",
    "opc-request-id": "BE3413852ED54B95BF9D724C3AAF2B99/21A0503F15C35E278F221214B346C541/3E184B8AAE7889A047C2B32753DECE94",
    "status": 404
}

Access is strictly restricted within those policies I give to the dynamic group. If I add following policy:

Allow dynamic-group dynamic-group-test to read instances in tenancy

I can then instantly query my compute instances without issues.

Summary

Using dynamic groups in OCI is great way to enhance your solution security and stop managing keys on the server side. Just think the access from the least privilege perspective so instances don’t get too wide permissions.

I think Oracle is cycling the keys automatically and they are only temporary when the instance needs them but I couldn’t yet find deeper info on that. If I get that information in the future I will update this post accordingly.

Dynamic groups should definitely be part of your strategy if you need to access OCI services from your instances.