Secrets and variables

FlexStack stores your secrets and environment variables securely within your AWS account using Systems Manager Parameter Store. The values of these variables are encrypted by default and are never stored in FlexStack's own infrastructure. We also take care to ensure your secrets are never leaked into the CloudFormation templates generated when we provision your infrastructure.

In leveraging AWS's robust security features in combination with FlexStack's careful handling, you gain peace of mind, knowing that your application's critical information is securely managed and easily accessible to your services when they need it, under strict access controls.

Our system supports best practices for security and infrastructure management, enabling your team to focus on development and innovation with the confidence that your operational backbone is secure and efficient.

You may either add a secret to every Component within an Environment or add them to specific components within an environment. Only team members with Contributor access to an environment or component may edit, create, or view the value of a secret.

Create a shared environment variable

To create a secret that will be injected to all of an environment's components, click the "Secrets and variables" tab in the Environment menu. From there you may add one or several variables at a time, import variables from a .env, .json, or .yaml file, or manage existing secrets.

To update an existing secret, click on the secret in the table on the page. If you have permissions to do so, you will be able to update the secret's value or name, storage type, and view the current value of the secret.

Create a component variable

Component secrets are injected into individual services at build time via Docker Build Secrets and at runtime via environment variables. To create a component secret, open your component from the environment overview page and click on the "Secrets and variables" tab. Secrets added to components take precedence over any shared secrets with the same name that are added to environments.

From this tab, the process for creating, updating, and deleting secrets is the same as the process for adding environment secrets. For changes to secrets to take effect, you will need to redeploy your component.

How to read variables in your application

At runtime, secrets can be read from environment variables by referencing the name you used in the "Secrets and variables" tab. To access a secret named "SECRET_NAME" at runtime, read it from environment variables:

package secret

import (
  "os"
  "log"
)

func main() {
  // NOTE: never log your secrets : )
  log.Println(os.Getenv("SECRET_NAME")) 
}

How to read variables during a Docker build

To access a secret named "SECRET_NAME" in the Docker build step, you can mount the secret, then run run cat /run/secrets/SECRET_NAME to read the value of the secret. When you mount a secret, it will only be available in that specific step. In the example below, the environment variable of NPM_TOKEN will not be available in any other steps of the Dockerfile.

# Read the secret and use it as an environment variable 
RUN --mount=type=secret,id=NPM_TOKEN \
    --mount=type=secret,id=NEXT_PUBLIC_DOMAIN \
    export NPM_TOKEN=$(cat /run/secrets/NPM_TOKEN) && \
    export NEXT_PUBLIC_DOMAIN=$(cat /run/secrets/NEXT_PUBLIC_DOMAIN) && \
    npm run build

This looks cumbersome and it is. We're using a complete example to give you a better idea of how secret mounts work. If you wanted to add dynamism to the example above, you could do the following:

# Read the secret and use it as an environment variable 
RUN --mount=type=secret,id=NPM_TOKEN \
    --mount=type=secret,id=NEXT_PUBLIC_DOMAIN \
    --mount=type=secret,id=NEXT_PUBLIC_API_URL \
    --mount=type=secret,id=NEXT_PUBLIC_DOCS_URL \
    for f in /run/secrets/*; do export $(basename $f)=$(cat $f); done && \
    npm run build

As you may have caught on, Docker does not provide a way to pass environment variables to a build. The example above works great for most cases. However, when you don't need to pass sensitive data to the build step Build Arguments are a great alternative.

Reserved variable names

FlexStack sets the following environment variables by default: