Cloud Secret Resolvers (CSR)

Cloud Secret Resolvers is a set of tools to help your applications (on Kubernetes) to retrieve any credentials from cloud managed vaults without the needed to write additional boilerplate code in your applications!

Cloud Secret Resolvers (CSR)

Installation

Cloud Secret Resolvers is available on Linux, ARM, macOS and Windows platforms.

Binaries for Linux, ARM, Windows and Mac are available as tarballs in the release page

Using on Kubernetes

AWS
- Prerequisites:
  1. Enabled the OIDC provider on your EKS cluster (https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)
  2. Your application Kubernetes pod has a service account with the following privillege: policy.json
- Update your application entrypoint as follows:
```
#!/bin/bash
eval $(csr)
node ... # your application runtime command
```
- Update your application Kubernetes config maps as follows:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: [your config map name]
  namespace: [your config map namespace name]
data:
...
CLOUD_TYPE: "aws"
AWS_REGION: "[your AWS region name]"
AWS_SECRET_NAME: "[your AWS secret name]"
```
Azure
- Prerequisites:
  1. Create a managed identity for your Azure Key Vault (https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview)
  2. Grant "Key Vault Reader" and "Key Vault Secrets User" RBAC roles to the managed identity (https://docs.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli)
  3. Create an Azure Identity and an Azure Identity Binding on your AKS cluster to map the managed identity to your pods on the cluster for providing access to the Azure Key Vault (https://azure.github.io/aad-pod-identity/docs/demo/standard_walkthrough/)
- Update your application entrypoint as follows:
```
#!/bin/bash
eval $(csr)
node ... # your application runtime command
```
- Update your application Kubernetes config maps as follows:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: [your config map name]
  namespace: [your config map namespace name]
data:
...
CLOUD_TYPE: "azure"
AZ_VAULT_NAME: "[your Azure key vault name]"
```
Google Cloud
- Prerequisites:
  1. Enabled the Workload Identity on your GKE cluster (https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
  2. Your application Kubernetes pod has a service account with Secret Manager Secret Accessor permission
- Update your application entrypoint as follows:
```
#!/bin/bash
eval $(csr)
node ... # your application runtime command
```
- Update your application Kubernetes config maps as follows:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: [your config map name]
  namespace: [your config map namespace name]
data:
...
CLOUD_TYPE: "gcloud"
GOOGLE_PROJECT_ID: "[your Google cloud project Id]"
```

Hashicorp Vault

Prerequisites:
1. Enabled Kubernetes Authentication on your Vault (https://www.vaultproject.io/docs/auth/kubernetes)
2. Your application Kubernetes pod has a service account with Read Only permission to the Vault secret path

Update your application entrypoint as follows:

#!/bin/bash
eval $(csr)
node ... # your application runtime command

Update your application Kubernetes config maps as follows:

apiVersion: v1
kind: ConfigMap
metadata:
  name: [your config map name]
  namespace: [your config map namespace name]
data:
...
CLOUD_TYPE: "vault"
VAULT_ADDR: "[your vault addr]"
VAULT_ROLE: "[your vault role]"
VAULT_PATH: "[your vault secret path]"

How it works

The architecture looks like below.

Internally, the CSR find local environment variables in the Kubernetes Pod Container which have Cloud Vault key placeholders for example: export db_username=${db_username}, then the CSR will extract db_username as a key and ${db_username} as a value. Finally, the CSR will use ${db_username} to match cloud vault key, retrieve cloud vault value, and map the value with db_username local environment.