Managing secrets with private Docker images

Environment variables are key-value pairs provided by the operating system that influence how applications run. They’re often used to configure paths, enable features, or inject sensitive information like API keys or tokens without hardcoding them into source code.

For example, the following commands print the PATH variable in different environments:

In the JavaScript ecosystem, environment variables are often defined in a file named .env (or some variation) stored in the project root. This file contains values that are loaded at runtime and made available via process.env in Node.js:

These variables aren’t available by default - they need to be loaded explicitly in code (or implicitly through build tooling) using packages like dotenv.

Even for client-side web apps, Node.js is commonly used during the build step. Many frameworks (such as Next.js, Vite, or Webpack) allow you to expose specific variables to the frontend by prefixing them or using special loaders, plugins, imports, or comments. This means it's possible-intentionally or accidentally-to embed sensitive variables into client-side bundles.

Environment variables themselves are not always sensitive. Many are harmless configuration flags or tokens used in low-risk contexts.

However, some variables-like API keys, credentials, or private tokens-must be treated as secrets. These values must never be committed to source control or exposed to the public.

• ✅ Access Token - used to fetch public content from the Delivery API; safe and often exposed in frontend code.
• 🛑 Role-based API Key (Client ID + Secret) - used to manage content; must be kept private and should never be exposed to the client.

The distinction is simple: if exposing a variable can result in unauthorized access or damage, it’s a secret.

In a CI/CD environment like GitHub Actions, secrets are used to safely pass sensitive values into your builds and deployments without storing them in code.

GitHub provides a secure Secrets section in repository settings where you can define these variables. Once stored, their values:

• Can be injected as environment variables in workflows.
• Are write-only - you won’t be able to read them later, only update them.
• Are automatically redacted from CI/CD pipeline logs.

Use this mechanism to store secrets like:

• Private registry credentials
• API keys
• Authentication tokens

During local development, developers often rely on .env files to load secrets as configuration variables. However, in CI/CD pipelines, these secrets must come from the CI provider’s secret management system (such as GitHub Secrets).

Our aim is to recreate the same environment securely in your pipeline - by injecting secrets into the build process without ever hardcoding them or exposing them in client-facing code.

Once your secrets are safely added to your repository, you can inject them into your CI workflows as environment variables or Docker build arguments, depending on how your application expects them.

GitHub provides a secure way to manage sensitive values in each repository under Settings → Secrets and variables → Actions.

Add all required secrets here before continuing.

If your application already relies on a .env file (or some variation), you can generate this file during your CI workflow using the secrets stored in GitHub.

Once generated, the .env file will be available to any build step that runs in the same job. It will be discarded automatically once the CI job completes.

If your application needs secrets to be available at Docker build time (to supply in RUN steps for example), you can pass them using the --build-arg flag.

After building the container image, you should push it to your container registry. Ensure that your registry is not publicly accessible, as public images can be pulled by anyone.

In GitHub, container images appear under Packages in your repository and are labelled as either Public or Private.

If you're deploying to Contensis Blocks, you'll need to:

1. Add your private registry credentials to Contensis.
2. Integrate the Contensis Block Push GitHub Action into your CI workflow to deploy the image.

You can include the push step as part of your existing build job or as a separate deployment job.

• Never include private secrets in code that is served to the client - for example, in components that are rendered on both the server and client side
• Restrict the use of private secrets to server-side operations only
• Never commit private secrets to source control, unless explicitly agreed upon for a specific, secured use case.
• Be aware that build tools may inline process.env.* or special global variables during build time, which can expose secret values in final client-side bundles if used incorrectly.
• Avoid pushing container images to public registries if they include private secrets, as this creates a significant risk of data leakage
• Understand that leaks can happen - if a secret is exposed, immediately revoke any public access, inform your team, and rotate any affected keys or credentials as a top priority.