LogoLogo
WebsiteGarden Core
Main
Main
  • Welcome!
  • 🌳Getting Started
    • Adding Your First Project
  • 🌺Features
    • Live Mode
    • Insights
    • Secrets
    • One-click Preview Environments
    • Automatic Environment Cleanup
    • User Groups, Roles and Permissions
    • Cloud Workflows
    • Service Accounts
    • Cloud Builder
  • 🌿Guides
    • Setting Up a GitHub App
    • Setting Up a GitLab App
    • Authenticating to Cloud Providers
    • Authentication via SAML
  • 💐Cloud
    • Requirements
  • 🌻Enterprise (Self-Hosted)
    • Requirements
    • Installation
    • Updating Garden Enterprise
    • Vault
    • PostgreSQL Configuration
    • Creating KMS Keys
    • Creating an AWS Load Balancer
    • Monitoring Services
    • Environment Configuration
    • Updating the Admin Console
  • 🌹Misc
    • Release Notes
    • FAQ
    • Troubleshooting
Powered by GitBook
On this page
  • Creating secrets through the UI
  • Accessing secrets
  • Managing access to secrets
  • Example: Define unique AWS credentials per user
  • Managing secrets through the Garden CLI

Was this helpful?

  1. Features

Secrets

PreviousInsightsNextOne-click Preview Environments

Last updated 1 month ago

Was this helpful?

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.

By scoping a secret to an environment (such as staging), it's possible 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.

Creating secrets through the UI

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.

Accessing secrets

Managing access to secrets

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.

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

Example: Define unique AWS credentials per user

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.

Managing secrets through the Garden CLI

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 access secrets by using, for example, ${secrets.POSTGRES_PASSWORD} in your Garden template and configuration files. See also in the Garden open-source documentation.

You can also use garden command line to access secrets, e.g. .

Admins can create and read secrets, while Users can only read secrets. You can read more about permissions in the guide.

You can see all the ways to interact with the garden cloud secrets command in the .

🌺
"variables and templating"
garden cloud secrets list
roles and permissions
Core docs reference
Adding a secret
Duplicate secrets
Viewing secrets in the CLI