Manageably safe and secure

Secret management in Rust with AWS Parameter Store

What’s so insecure about storing secrets in environment variables? As mentioned in the previous post, environment variables are the simplest approach for injecting configuration into your application. Simple because shell’s make it easy to export data in plain text for a process to interact with. Exported env information is then made available to any other part of that application and potentially any spawned child processes. There are no scoping rules for environment variables within a given process. Considering containers ( i.e. docker ) you can provide environment variables to containers that may actually run multiple processes, sometimes called sidecars. Exposure of this information may be and is often unintentional. A common approach to security is that access should be a privilege, not a right. When storing secrets in environment variables you are enabling potentially unintentional right to access to many components of your software stack, in plain text!

Organizations should also be aware that security risks related to leakage of secrets do not always come from attacks on the outside but more often than not the weaker link comes from within organizational walls.

Environment variables have a way of spreading when left unmanaged. You will often find copies of these secrets stored in local configuration files and shell initialization scripts on developer machines, making it easier for them to run applications locally. The risk this puts on the organization is then not only protecting against leakage in production but also leakage by way of access to an employee laptop. It’s not uncommon for employees using unmanaged env configuration systems to share these secrets over communication channels like slack, at which point these values now live on slacks servers. The practice of manually copying these around also suffers from the phenomena of forgetting what you’ve copied to your clipboard and accidentally posting in public channels. Whoops!

What makes Parameter Store more appropriate for secrets configuration than environment variables? Three things: built-in security primitives ( SecureString is a value type ), centralized management ( removes the habit of storing values ), access control ( controls who can access values ).

Technically envy store works very much like the envy crate. It uses parameter names to deserialize into members of a type safe struct. It was also a goal to encourage the use of the AWS best practice of name prefix hierarchies. That ended out surface in envy stores Rust API which accepts a AsRef<Path> type representing that prefix. Another notable part of it’s interface relates to the fact that Parameter Store is an external configuration service. A tradeoff for added security and external management is that there is a runtime dependency on a network service. This is typically the same tradeoff for any micro services architectures. As such, envy store’s interface returns a futures::Future type which encodes both the deferred availability of a value as well as the potential for network or authentication failure.

Related posts:

It is known that we as humans struggle with remembering and managing multiple complicated passwords, that are required to access different applications on a daily basis. To comply with the latest…

If you are still a newbie to the baking world and often wonder how to make cookies that are just perfect, then do not worry because our collection of cookie recipes has you covered. We bring forth…

Poppy landswimming for a good back scratch.. “A Photo a Day 131” is published by The Solitary Cook.