Shared Secrets

In loft, shared secrets are similar to normal kubernetes secrets, but can be accessed globally. They can be used to store and share sensitive information across your users and teams independent of the connected clusters. Shared secrets consist of multiple keys and values. By default, shared secrets are stored in the namespace you installed loft into and can be optionally encrypted with a custom defined encryption key.

Create a new Shared Secret

Shared secrets can be created via kubectl, loft CLI or the loft UI.

Go to the Secrets view and click on 'Add Shared Secret'.
Shared Secrets
Create a new Shared Secret
Enter the name of the secret and press 'Create'.
Use a single Shared Secret for multiple Values

It is good practice to use a single shared secret for multiple keys, e.g. it makes sense to have a shared secret prod and development with different access rights for different teams and users.

Manage Access to Shared Secrets

You can define which users or teams are able to view, update or delete the shared secrets. This can be done either by using the loft UI or kubectl in the management cluster (the cluster where loft is installed).

Go to the Secrets view and click on a shared secret. Then click on 'Access' and on the 'Add Access' button.

Adding Access
Add Access to a Shared Secret

When the drawer opens you are able to configure the following options:

  • Verbs: what access rights should the defined users and teams have to this shared secret
  • Users: which users are effected by these access rights
  • Teams: which teams are effected by these access rights

After you have configured the verbs, users and teams, press the 'Save' button.

Adding Access
Save Access
How Access Works Behind the Scenes

If a user can access a shared secret is purely defined through kubernetes RBAC. loft creates the required roles and role bindings automatically in the background based on what is defined in the spec.access section of the SharedSecret resource.

A user or team can access a shared secret if the right is granted to 'get' (verb) 'sharedsecrets' (resource) in 'storage.loft.sh' (api group) in the namespace where the secret is stored (typically the namespace where loft is installed). This however also means that cluster admins will be able to access all shared secrets, since they have the right to access all resources in all namespaces.

Read from a Shared Secret

Reading a key from a shared secret can be done through the loft UI, loft CLI or kubectl.

Go to the Secrets view and click on a shared secret name. A list of available keys should appear. Then click on 'Show Value'.

Read Secret
Read a secret key value

Change data in a Shared Secret

Changing the data of a shared secret can be done through the loft UI, loft CLI or kubectl.

Go to the Secrets view and click on a shared secret name. A list of available keys should appear. Then either click on an already existing key name or on 'Add Key'.

Read Secret
Add a secret key

Click on 'Save' and the key should appear in the list.

Enable Shared Secrets Encryption

Enterprise Feature

This is an enterprise feature. Please make sure your license permits secrets encryption before you follow this guide.

By default, secrets are not encrypted and stored plain text (base64 encoded) in the underlying shared secrets custom resource. You can configure loft to encrypt the data of secrets by specifying an encryption key. This can be done via helm:

helm upgrade loft loft --repo https://charts.devspace.sh/ \
--namespace loft \
--reuse-values \
--set env.SECRETS_ENCRYPTION_KEY=my-secret-encryption-key

From now on all secrets will be encrypted with the specified encryption key.

Loss of Encryption Key

If you lose the encryption key, the secrets data cannot be recovered. You will have to manually delete all shared secrets via kubectl: kubectl delete sharedsecrets.storage.loft.sh -n loft --all