Secrets

Secrets #

A Secret allows you to manage the lifecyle of sensitive information inside of Riser. Riser takes advantage of Public Key Infrastructure to provide a mechanism that allows for the secure management of sensitive values within a GitOps environment.

To learn more about the architecture of this feature, review the Secrets Internals section.

ℹ️ Other than a brief moment during the encryption phase, Riser does not have access to your Secrets. Riser does not need access to your secrets or your private keys on your Kubernetes clusters.

Saving a Secret #

There are some important considerations to consider when using this feature:

  • Secrets are stored per App and per Environment
  • Secrets may not be shared between Apps or Environments
  • For security reasons, there is intentionally no mechanism to read or copy a Secret
  • You should not consider Riser Secrets as the canonical store for sensitive information

Use riser secrets save (name) (plaintextsecret) (targetEnvironment) from inside your app folder to save a secret. For example, to save a postgres URL to the dev environment:

riser secrets save POSTGRES_URL "postgres://user:s3cr3t@postgres.net/mydb" dev

You should now see your secret using the command riser secrets list (environment)

Accessing Secrets from your App #

Once one or more Secrets are saved to an Environment, they are automatically bound to your App on each subsequent Deployment in that Environment. Secrets are securely bound to your app using environment variables. For example, a Secret named POSTGRES_URL is bound to the environment variable POSTGRES_URL in your app.

Secret Revisions #

When you wish to update a Secret, simply save a secret with the same name and a new value for the target Environment using riser secrets save.... Like saving a new Secret, the new value is not applied until after a new Deployment in that Environment takes place. Additionally, Riser will assign a revision number to the Secret. The Secret Revision is tied to your Deployment’s Revision. This means that if you ever rollback your Deployment that your Secret values will rollback along with it.

Advanced Example #

Most of the time it’s just as simple as saving a Secret and creating a Deployment. The following is a more complex example where we save multiple revisions of the Secret and rollback our Deployment. Let’s start with an App with no Secrets and we wish to save a secret FOO and access it from our code:

riser secrets save FOO fooval1 dev

Current State: The secret has been encrypted and saved in the State Repo, but the environment variable FOO does not exist until we create a new Deployment to the dev Environment.

riser deploy v1 dev

Current State: The environment variable FOO now has the value fooval1 in the dev Environment. The Deployment Revision is 2.

riser secrets save FOO fooval2 dev

Current State: The new secret value has been encrypted and saved in the State Repo. The environment variable FOO will still have the value fooval1 until we create a new Deployment to the dev Environment.

riser deploy v1 dev
ℹ️ It’s okay to deploy the same Docker tag multiple times (e.g. v1 in this example). Riser considers all configuration as code, including secrets. Riser will still create a new Deployment Revision even though you are deploying with the same Docker tag.

Current State: The environment variable FOO now has the value fooval2 in the dev Environment. The Deployment Revision is 3.

We’ve discovered a problem with our App and we’ve decided to rollback the Deployment back to Revision 2

riser rollout dev r2:100

Current State: The environment variable FOO now has the value fooval1 in the dev Environment. The Deployment Revision is 2.

Riser always uses the most recent Secret Revision for a Deployment, regardless whether or not a rollback ocurred. If we were to redeploy our app again:

riser deploy v1 dev

Current State: The environment variable FOO now has the value fooval2 in the dev Environment. The Deployment Revision is 4.

ℹ️ You never need to worry about the specific Secret Revisions. Riser manages which Deployment Revision maps to which Secret Revision for you so that you don’t have to.

Deleting a Secret #

Deleting a Secret has not yet been implemented.