Application Secrets (Beta)

Manage application secrets while deploying in clouds and on-prem

The same application code has to distinguish between at least those three runtime environments and point the app to the right database accordingly. It can be done by placing the database connection string into a configuration file and using a separate version of the config for each environment. However, the database connection string is very sensitive information, especially in production, so it must be somehow protected. We can encrypt it, but the encryption keys need to be stored somewhere…

In public clouds, there are special services like AWS Secrets Manager and Azure Key Vault that help with key encryption and management, but you don’t have it on development machines, so you must treat the configuration differently depending on where it is running. And what if you need to test or run it in various clouds and multiple machines? It becomes an issue that’s really difficult to manage while preserving security (not to mention privacy). Here comes MystSafe to help us.

In MystSafe, you create application secrets (three in our example - one per environment) that contain different database connection strings, and you link each secret with information about a particular device – a runtime environment such as the developer's laptop, AWS VM, or Azure Kubernetes node. All the encryption happens behind the scenes, so you just need to put the right parameters for each runtime location, and your app will know to use the right database depending on the environment it’s currently running. No config files, hardcoded credentials, or identity-based key vaults are needed!

Application secrets allow apps to retrieve the secret values stored in MystSafe using characteristics of the runtime environment they are running on. The secret values retrieved by the app can be the same or different depending on the runtime and the setup. For example, you can specify the connection string for the production database when your app is running on AWS, a different connection string to the local development database when it's running on your MacBook, or a third one for the test database when the app is running on another machine in Linux docker container.

The secret values are encrypted using runtime parameters such as various environment variables specified during the secret setup. When the app retrieves the secret, it does not need to know any encryption key or look for any configuration file, so the source code and configuration files (if any) can be shared with others without the risk of leaking the secrets. Moreover, there is no public link between your app code and the secret entry in the MystSafe database, which is accessible to anyone and therefore cannot be hacked.

10 Reasons to use MystSafe Application Secrets

• Keep the same app source code and configuration files while managing different secret values and runtime environments

• Get rid of configuration files

• Share your app code with others or even store it in a public repository without disclosing the secrets

• Eliminate the need for maintaining different secret vaults while running in multiple environments such as AWS, Azure, GCP, OCI, or local computers

• Implement a secret vault in environments that don't have out-of-the-box secret vaults such as on-prem data centers or local networks

• Allow other developers and users to create their own secrets for your app without making any changes in the source code or configuration files

• Access MystSafe Application Secrets from any environment connected to the Internet without any special configuration or setup

• Simple one-line code in any major programming language to retrieve the secret

• Automate secret management by using network API

• Create your own secret vault without deploying anything in the cloud or on-prem