Commonly (in 90% of cases), the most popular way to store configuration data for your applications is in text files. There are different formats such as INI, YAML, JSON, or Java Properties. We follow this practice because application frameworks provide a simple mechanism for it. In some cases, since these files are plain text, it is a common practice to save the versions of these files into the projects’ control version systems (Git, Bazaar, SVN) as well.
Now, imagine this possible scenario: Our server has a security issue and an unauthorized person is able to log in and read the configuration file. The “intruder” has access not only to our server, but (even worse) all sensitive data, including database credentials, API keys, log paths, encryption keys, etc.
So, at this point you should think…
Where can I safely store my sensitive data?
To answer this question, we need to survey the security of our data: how developers will access to it, how testers will access it, and how it will be accessed by the application deployed in different environments, like the production environment.
To allow all users who need to save and read secrets with the right level of access, a good practice could be to set different data sources as destinations for writing and reading your company secrets. These data sources could include the following:
- Environment vars
- Configuration files (must be encrypted)
- 3rd party services to store secrets
One safe approach could be to allow users to read secrets depending on their security level from a chain of previously mentioned data sources sorted by priority. This would allow all involved “actors” to store and read the secrets.
Knowing the data sources, we could create a simple Class to read a secret key from these different sources, assigning them a priority level. For instance, the developers could save secrets in Environment vars only for their local environments. The same concept applies to testing environments, but for servers in Staging or pre-prod environments, the secrets could be stored in encrypted files in order to let the devops team integrate it with their automation tools. For production environments, since most servers are located behind VPNs with access to the outside world and are more exposed to potential attacks, storing secrets in third party services such as Vault (by Hashicorp) or Amazon KMS are highly encouraged.
Vault vs. Amazon KMS
Vault and KMS differ in the scope of problems they are trying to solve. The KMS service is focused on securely storing encryption keys and supporting cryptographic operations (encrypt and decrypt) using those keys. It supports access controls and auditing as well.
In contrast, Vault provides a comprehensive secret management solution. The transit backend provides similar capabilities as the KMS service, allowing for encryption keys to be stored and cryptographic operations to be performed.
Flexible secret backends allow Vault to handle any type of secret data, including database credentials, API keys, PKI keys, and encryption keys. Vault also supports dynamic secrets, generating credentials on-demand for fine-grained security controls, auditing, and non-repudiation.
Avoid saving secrets in plain text files, specially if they are unencrypted and stored in source control with revision history. Figure out the security level needed for your application and the best data sources to store the secrets in a safe manner, define the priority order to read these data sources and the policies to fetch secrets from these sources, and follow the golden rule: keep all your actors involved in this process. Developers and testers will need a way to set their secrets, and the Devops/SRE team should be aware of the user roles that need to be available in your servers to properly access the secrets.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Providing an always-on and highly secure feature flagging and experimentation platform is core to making product decisions with Split. From the beginning, we have designed and built our infrastructure and practices with security and reliability as a top priority and are excited to validate this with SOC 2 Type 2 certification.
Kicking off an internally developed feature flagging system is standard practice for many companies today as feature flags help engineering teams release faster at lower risk. As use cases for feature flags grow, so do the challenges of building an in-house system. This article will explore 10 challenges of building an in-house feature flagging solution.
At Split, we recognize the significance of the GDPR both to our customers and to the services we provide. Our customers expect to work with partners who commit to compliant data protection and information security standards when handling their data. For that reason, Split with support from EU external advisers, has been undertaking (and continues to undertake) a number of activities to ensure that it is GDPR-ready by May 2018 and beyond.