Use Instance Principal to access Secrets
“Do not store any Secrets locally”, as a developer you would have heard this sentence a number of times from your superiors. The truth is that even if you store all your secrets safely in a vault, you end up saving the key to the vault locally for e.g. “A key embedded in a config file which connects to the cloud”, “A passphrase to unlock a private vault” etc. This only means that the “Keys to the Kingdom” are still available locally which just needs an intelligent hacker to trace them correctly.
Q) Is there any way one can securely store their Secrets?
Answer: Yes, one can use “Instance Principals” to access their secrets from the vault. (Let’s dig deep into the answer)
Assume you are writing an application which runs on one or more compute instance on a cloud like AWS or Oracle. Instance Profile in AWS or Instance Principal in Oracle can be treated as an “Identity” provided to that instance. IAM Policies can be written to grant access to various resources to that instance which can include Keys & Secrets stored in the Key Vault.
While coding your application you can safely assume that the Instance on which the application will run has access to the required keys/secrets whereas in the background the cloud administrator would have written the appropriate IAM Policies which provides the required access to the instance.
Under the hood, the instance too would have a config object which would have a key to authenticate itself but it would be secured under the root user which would be very difficult if not impossible for the hacker to read.
With this approach, we have managed to securely store our secrets in a vault without any key stored locally to access the vault. This mechanism can also be extended to Kubernetes where Instance Principal of each node of the cluster will be granted access to the secrets.
Let us quickly see the above theory in action with an example:
I am using Oracle Cloud Infrastructure (OCI) as my cloud provider.
Step1: Create an compute instance and add it to a “Dynamic Group” say (SecretReaders).
Step2: Create/Edit a matching rule where you provide the instance’s OCID to make it a part of the group.
Step 3: Create an IAM Policy which allows the dynamic group (SecretReaders) to manage secrets. Note: You should try to create the policy as restrictive as possible.
Step 4: Create/Edit the policy statement to provide the appropriate access to the secrets.
Step 5: Access the secrets in your application code. Here, I am using Python OCI SDK to access the secrets stored in the OCI Vault. From the code you can easily make out that a secret with a particular OCID is read from the vault which is then base64 decoded and ready to be used to connect to a database or to access an API or to decrypt a file or for any other purpose. Also, you can see that the config object is empty (config={}) which means no file stored locally is used to access the secret.
References:-
