Python Encryption

Photo by Towfiqu barbhuiya on Unsplash. Read or listen to this article on Medium.

A DevOps perspective on securing deployment parameters

Code builds and deployment automation has paved the way for many great things. Long gone are the days of monthly, manual code releases; modern CI/CD pipelines now have the ability to release every code commit that passes automated testing in the development and staging environments to production.

In order to make this magic happen, DevOps teams must build code that is environment agnostic. The exact same code must be deployed in DEV, TEST, STAGE, and then in PROD, passing the proper parameters at deployment time to make the solution behave appropriately. Microservices architecture and the decoupling of independent subcomponents that have to discover each other after being deployed to work together make this a very challenging task. Keeping track of these deployment parameters, the “glue” that will make all these naive components work together in any given environment, has become a new challenge in itself.

While it is common knowledge, It probably can’t hurt to repeat it one more time: you should never, under any circumstances, embed credentials of any kind, including API keys, in your code or a container image. Credentials uploaded to a code repository or image registry should be considered to have been compromised and changed immediately.

But, you may ask: if you can’t keep track of these precious deployment parameters in a source code repository, what can you do? Keeping these critical values in a version-controlled repository is a good idea, but as long as they are encrypted. Public/private key cryptography provides the best solution because the encrypted secret cannot be decrypted without the private key, so they can safely be uploaded to a private GitHub repository as long as the decryption key is not.

Good old configuration files or “.INI” files are surprisingly well suited to store deployment parameters because they allow for storing the same key name with different values in multiple sections representing the various environments. For Instance:

The value of my database username db_user will be the same for all sections (DEFAULT) but the value for db_pwd can be different in DEV than in PROD.

The rsa_crypto Python library and command-line utility allow you to combine the flexibility of storing values in configuration files with the security of private/public key encryption. Self-contained binary files for Windows, Mac, and Linux are also available as a convenience.

The first step is to generate new keys:

By default, the tool creates a new 4096-bit RSA key pair (secret) and saves it into a single file, protected by a password meeting the PKCS#8 standard and using the scrypt key derivation function to thwart brute-force dictionary attacks. The key is safe with a good password, but it should still never be stored in a code repository.

Having yet another password doesn’t lend itself well to deployment automation. The tool also provides a way to extract that password-protect file into separate public and private key files that don’t require a password.

The public key file can safely be distributed to anyone who needs to be able to encrypt values, it cannot be used for decryption. This is a great option as credentials are usually managed by a separate group in most organizations.

Conversely, the private key must be guarded with extreme caution as it can be used to decrypt any values without any password. The tool will look for these key files in the current directory (the one you are executing the command from), the directory where the script is located, as well as in the user’s home directory. It will also look for the key files as environment variables, which might be a better option in many situations.

The private key file can then safely be deleted, it can always be re-generated from the password-encrypted key file:

The tool can also be used with the -k option to specify a different key name prefix, allowing users to have multiple keys for different environments or purposes or credentials managed by different teams:

This get and set parameters of the script can also be used to store and retrieve encrypted values in a configuration file. The configuration file must already exist:

The structure of the file is fairly simple, it contains sections delimited by brackets [MY_SECTION]. Note that the section name can be case-sensitive. The [DEFAULT] section is used by default.

Each section will then contain several "options" and values (key/value pairs). Only the value will be encrypted, the option name will remain in cleartext.

This structure is very well suited for keeping track of values that need to be different by environment, such as to keep track of database passwords in a DEV, TEST, and PRODUCTION environments.

To save a value of an option named database_password in the DEV section using the default encryption key:

If you don't specify a value, the script will prompt you for the value so that it is not visible in the command line history. Optionally, if you prefer, you can also specify the value as a command-line parameter by using the -v parameter.

To decrypt the value:

Note that in the above example the rsa_private.pem private key allowed us to decrypt the data without prompting for a password. Once again, be extremely careful because anyone with that file can decrypt the data. If the private key is not present, the script would then prompt for a password to open the protected key-pair file rsa_key.bin.

Now let's set and get the PROD password:

The content of the .rsa_values.conf configuration file will look something like this:

The tool can also be used to encrypt entire files, such as a Kubernetes Parameter Store .yaml configuration file, by using the -f option.