Shhhh, it’s a secret…
Secrets are an essential part of secure programming. I’ve been programming since the early 90s, and back then, secrets weren’t nearly as big a deal as they are today. Passwords would be hard-coded into applications… connection strings stored in configuration files in the application install directory… we’ve learned a lot since those days.
With cloud computing, most providers generally provide you with an option for a Secrets Vault of some sort. This provides you with a centralized location to store secret information that can then be referenced in your application. These secret vaults take care of all the underlying requirements like infrastructure management, securing access, and encrypting your secret data, and allow you to focus on building your applications.
OCI, has a service called Vault that you can use for this purpose. Vault is a secure system that you can use to store all kinds of information, such as user names, passwords, connection strings, and encryption keys. So for the .NET developers out there, everything you used to base64 encode and shove into Web.config and hope no one found… You can now securely store in OCI Vault and easily access it in your application.
Setting up a vault and secrets
Getting set up to store your secrets in a vault is a three-step process:
Create vault
To create a Vault, click the Hamburger menu, select the Identity and Security category, and then click on Vault.
Creating the Vault is pretty straightforward. You choose the compartment and provide a name. You can optionally choose to make the vault a “virtual private vault,” which will enforce some restrictions around multiple tenants on the platform; however, for most applications and users, this is not going to be necessary.
Consider the vault like a container to hold all of your secret data. You might want to consider a separate vault for each application, for example.
As you can see here, OCI makes pricing for security services, including vaults, very cost-effective. Much more so than trying to set up and maintain your own secrets management software.
Create a master key
The next thing you want to do is create a master Key to use to encrypt the secrets that you are going to store.
For the master key, you will provide a name and select whether you want the encryption to be hardware or software-backed. Using software-backed keys has several benefits, including lower costs. You might need to select hardware-based encryption if you are in specific, highly regulated industries.
You can, as an option, import an external encryption key. This is useful if you have an HSM on premises and you want to generate the encryption keys yourself. For most users, allowing OCI to create the encryption keys for you will be more than sufficient.
You can have multiple master encryption keys. This would be useful in situations where you have an application with multiple tenants. Each tenant could have a different key. You are then able to control access to the various keys with IAM permissions.
Create your secret
Finally, we are going to create the actual secret. Give the secret a name, a description so that you know what this item is for, and choose the encryption key that you want to use. You can select an option to either supply the secret data yourself or allow the vault to generate a secret for you. Supplying the secret is going to be useful when you need to store a connection string, while auto-generation can be used for creating pass phrases.
Using Secrets in your applications…
Retrieving secrets from the OCI Vault is pretty easy, once you get past some initial confusion.
As you can see from this snippet, there are two SDK components that you can add via NuGET. The OCI.DotNetSDK.Secrets and the OCI.DotNetSDK.Vault. You might initially grab the Vault library, because you are interacting with the Vault service… I did… and then I spent about an hour trying to figure out what was going on, and why I couldn’t get access to the secret data.
The Vault service is specifically geared to encryption functions. The secrets library is specifically designed for storing and retrieving secrets. So… you need to pull in the OCI.DotNetSDK.Secrets library only.
Once you have the correct library in your application, the code to retrieve the secret looks like this:
public DataRepository(IBasicAuthenticationDetailsProvider provider)
{
var client = new Oci.SecretsService.SecretsClient(provider);
GetSecretBundleRequest getSecretBundleRequest = new GetSecretBundleRequest
{
SecretId = "{Secret OCID}"
};
var secretResponce = client.GetSecretBundle(getSecretBundleRequest).Result;
var secretBundle = secretResponce.SecretBundle;
Base64SecretBundleContentDetails secretBundleContent = (Base64SecretBundleContentDetails)secretBundle.SecretBundleContent;
var content = secretBundleContent.Content;
var decodedBytes = Convert.FromBase64String(content);
var connectionString = Encoding.UTF8.GetString(decodedBytes);
}
Note that secrets are stored and retrieved as Base64 encoded strings, so you will have to decode the secret once it has been retrieved.
Security
Security is everyone’s responsibility everywhere, and this is especially true of security around secrets. You need to ensure that only the applications that require access to secrets actually have permissions to read and write secrets. Whatever way you decide to implement security around access, make sure that only the appropriate applications and processes have access to retrieve your secrets.
