Managing Secrets
Last updated
Last updated
Garden Cloud lets you manage secret and other environment variables and scope these to any of:
a project
an environment
a user
This means that you can define multiple versions of each secret and a specific user will only be able to access the one that is relevant to them.
This can be used in different ways, but some common examples include:
A Garden service account has credentials to run scripts in the CI environment
Each developer is assigned unique secrets for a cloud platform (e.g. AWS IAM keys, or Google Cloud credentials)
The production database password and other credentials are only accessible by senior technology employees, e.g. VP Engineering.
Because a secret can be scoped to an environment (such as staging), it's easy to make a secret accessible to an entire group of people. This secret can also be overridden on a per-user level so you don't have to give all your secrets to, for example, a contract developer who joined recently for a trial period.
To add a secret at any scope, navigate to a project in Garden Cloud, click on the "Secrets" tab and click "Add Secret".
Project level secrets: To make the secret available to anyone who can access the project, leave the 'Choose an environment' dropdown blank. The secret will then be available across all environments and all users.
Environment level secrets: To make a secret available to all users who have access to a specific environment, select the environment you want from the 'Choose an environment' dropdown. For example, you might set a database user and password that your CI environment can use to set up and tear down data while running unit tests.
User-level secrets: To make a secret available to a specific user, first choose an environment. This will activate the user dropdown and you can then assign the secret to that user.
You can define the same secret multiple times under different scopes. For example, you could
Define your production database credentials at a project level
Define your staging database credentials for your "dev" and "CI" environments
Define read-only staging database credentials for your "dev" environment and an intern user
If your developers have access only to the "dev" environment, they will now only be able to access the staging database credentials, and the intern will only be able to access the read-only staging database credentials. You can access secrets by using, for example, ${secrets.POSTGRES_PASSWORD} in your Garden template and configuration files.
To manage a user's access to secrets, you can assign them the Admin or User role on a specific project or environment where the secret is set.
Admins can create and read secrets, while Users can only read secrets. You can read more about permissions in the roles and permissions guide.
For example, if you had several contract developers assisting with a specific project, you could create a new Group, and assign it User permissions on a specific project. Users for this group would
Only be able to see secrets for the relevant project
Be restricted from adding or removing secrets from that project
In the example below, we've defined AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID twice. One instance is scoped to the dev environment and can be accessed by any user who has access to that environment. Another one is specific to the user Jane Doe. Because the user-level secret takes precedence over the environment-level secret, Jane Doe will not be able to access the environment-level secret.
The Garden CLI has experimental support for adding, deleting and viewing secrets stored in Garden Cloud. For example, to get an overview of existing secrets for a project, run garden cloud secrets list. You will see a list of secrets defined for that project, as shown below.
You can see all the ways to interact with the garden cloud secrets command in the Core docs reference.
