The Vault product produced by Hashicorp is an API-first approach to managing operational secrets in a distributed system world. The use of secrets is rarely optional as one generally need them to access to your clouds, your databases, and your bespoke internal microservices. With much of the Vault UX focus currently being placed on it's RESTful API, integrations are straightforward. The CLI interface is implemented in a way which makes integration via UNIX pipes fairly easy. Early on in our experiments with Vault at Autodesk we decided that some lightweight Python might be a bit better for codifying our Vault usage opinions than cargo-culted shell scripts and thus aomi was conceived.
The predominant thoughts which drove the aomi concept were easing the transition from current methods of handling secrets into the API-first world provided by Vault. Most applications read their secrets from heterogeneous configuration files. With the success of twelve factor apps many have begun placing secrets in environment variables. Both of these options have their own flaws and yet they remain the status quo. With aomi, extracting secrets from vault into environment variables, static, or template-built files becomes delightfully simple. It allows the provisioning of on-demand access to secrets which may be used by applications without sweeping changes to the underlying codebase.
You can also use aomi to seed a Vault instance with structured data. By crafting a Secretfile one can define Vault paths (comprised of a mount point and a relative path) and fill them with a variety of secrets. As of publish it can write generic secrets from either static files or a set of key/value pairs defined in YAML. It is also possible to provision AWS secrets, and the application authentication type. While the Secretfile contains the paths and some associated metadata, the actual secrets are located in a different path (one which is probably not pushed to a source control repository). Vault and EC2 policies are located in yet a separate folder, which is safe to be shared. By defining secrets (and associated policies) in this fashion we are able to leverage existing source control and code review practices when processing security policy changes.
Extracting secrets is even more straight forward. There are three ways to extract secrets from Vault with aomi. One common use case is writing secrets to files with the
extract_file action. Templates may be rendered with secrets using the Jinja2 library. Secret paths are translated to template variables, allowing the generation of custom output expected by many application configuration technologies. The third method is rendering environment variable shell snippets. This allows for easy integration with scripts and existing twelve factor apps.
We intend to ensure that, irregardless of any organizational opinions which develop around our use of Vault, aomi will remain lightly opinioned. We expect that this will entail configuration options where appropriate, however the default behaviors is unlikely to change. We hope you find aomi to be useful, and we at Autodesk welcome collaboration with anyone excited about API driven access to operational secrets.