Shipping fast and shipping securely don’t have to be at odds. A critical component of your site’s security posture is handling secret and sensitive values. Handling sensitive values in a controlled manner allows your team to focus on shipping customer value without slowing down to manage the risk of using environment variables within your site. That’s why we are introducing Netlify Secrets Controller, to help your team ship faster — securely.
Securing your secret keys
Secrets Controller is a new feature set from Netlify that provides a stricter access control policy, improved logging safety, and proactive secret scanning to find variables that your site might be exposing. These added layers greatly reduce the business risk of inadvertent or malicious exposure of your site’s secret values (e.g. database passwords or vault keys). Let’s see how that works and how these improvements impact your team.
Watch the 1-minute demo video
Secure handling of secret values with environment variables
As the ubiquitous method for providing variable settings to your applications, secure handling of secret values centers around environment variables. When you add or update an environment variable in Netlify, you can mark if it “contains sensitive values.” From there, all of the capabilities of Secrets Controller are applied to any variable marked this way.
Benefits of marking environment variables as secret values
What happens with these environment variables when they are marked as secret?
- An opinionated secrets policy is applied to them to ensure only code running on Netlify can access the raw values after they are set.
- Secret values are masked in build logs.
- During builds, Netlify scans the built site and repo code to find permutations of the secrets that might be embedded and stops the build from being published.
Access control for your secret keys
Not all environment variables are created equal. Some are simple settings while others are incredibly sensitive. Some very common examples:
- Database passwords
- API keys to a credentials vault
- Secret keys to connect to your storage layers
- Encryption/Signing keys
These environment variable values represent some of your site’s most sensitive pieces of data. How you handle these secrets can either increase your team’s velocity or slow it down due to added risk. At worst, the ability to control access can lead to a security incident impacting your business. Just recently, Microsoft announced that a stolen Azure AD signing key was used to breach the Exchange Online and Azure AD accounts of two dozen organizations.
With Secrets Controller, the environment variables containing sensitive values will be held to a clear and opinionated policy about how they can be used and accessed. This policy is based on industry best practices that puts constraints on secrets such that there’s no way for them to be accessed outside of your code running on Netlify.
Key parts of the secrets policy:
- Secret values are write-only. After setting a value, the UI, CLI, and API will no longer provide a human-readable, unmasked version of the value.
- Only code running on Netlify’s systems can read the original, unmasked values.
- The policy cannot be overridden and settings cannot be manipulated to allow the value to be human-readable from the UI, CLI, and API.
The complete policy promotes defense-in-depth security with strict layers for your team to build against. When your team creates a secret value, they will know how it can be accessed and, more importantly, the ways it cannot be accessed. With Netlify Secrets Controller, there’s no additional permissions to manage or ensure are sufficiently strict. There’s no accidentally leaving the secret value open, and there is now a clear understanding that only builds/deploys on Netlify can possibly access the values. When your team goes through auditing exercises, the Secrets Controller policy will save your team valuable time and let them focus their efforts on other areas.
Consequences of mishandling environment variables
As your team is developing new features or debugging existing ones, they are focused on solving the feature problems at hand. For one reason or another, teams eventually find themselves in the position that secrets ended up in the wrong place. If this happens, the time it takes to detect the exposure and then mitigate the impact are paramount to the amount of damage this exposure could potentially cause to your customers or the business.
Let’s take a look at a case that’s painfully easy to do:
App Settings
We have a website that has a few configurations for feature flags. This site sets the flags via environment variables. During our build, we’ve been manually injecting these values into the site as follows:
flags.FEATURE_FLAG_A = process.env.FEATURE_FLAG_A;
flags.FEATURE_FLAG_B = process.env.FEATURE_FLAG_B;
After the build, the website’s public, client code has these flags injected into it.
At some point in the future, a developer gets tired of doing this process and wants to streamline it so that feature flags automatically appear in the client when defined. The above code is changed to:
flags = {...process.env};
After the build, the website’s public, client code will have all of the flags set as environment variables automatically, just as the developer intended. However, it will also have any other environment variables that are set as well.
There are two realities that this could represent: 1) the developer might not have realized this over injection and publicly exposed secrets or 2) the developer knew this would inject all environment variables but is expecting they should only be used for feature flags on this site. Then one day, another developer or business stakeholder adds a secret environment variable to the site or team. Not knowing this assumption in this site, the next deploy will publicly expose secrets.
Yikes! That was so easy to do!
Netlify Secrets Controller: automatic secret scanning
With Netlify Secrets Controller, after the build completes but before the site is deployed, Netlify’s build system will automatically search for the existence of this site’s secrets in the code repo pulled to create the site and the build output. If the secret scanning finds a secret, it will fail the build and inform the developer of what environment variable secret was found in the repository or build output. It will also tell the developer where to find it in that file.
Proactive protection with Netlify Secrets Controller
Going back to our example of two realities above: 1) if the developer’s change immediately started injecting secrets, the build would have been blocked automatically preventing secrets exposure. Or 2) the next build and deploy after a stakeholder added a secret environment variable would have also resulted in a blocked build to prevent exposure of the secret variable values.
Automatic secret scanning provided by Netlify Secrets Controller gives you proactive protection to prevent and/or stop ongoing exposure of your business’ secret environment variable values.
Enhanced security with Netlify Secrets Controller unlocks speed
When you put all of these capabilities together, Netlify Secrets Controller allows your team to rely on clear boundaries where secrets can be accessed and proactive protections to make sure those values aren’t put in places that can be easily exposed to outside actors or internal teams. These layers of protections allow teams to build with confidence and that means they are building faster and more securely.
Ship **it Securely with your team
If you’re a current enterprise customer, all you need to start using Secrets Controller is to start marking your environment variables as secrets if they contain sensitive values. From that point, all of the benefits of Secrets Controller are automatically enabled — including proactive secrets scanning.
If you’re not a Netlify Enterprise customer, reach out to our team for a custom demo.
If you’re trying to figure out how to take advantage of Secrets Controller and the various options available to suit your unique needs, visit our Secrets Controller docs.
