Hello all, Apache Brooklyn has supported Hashicorp Vault as an "externalized configuration" provider[1]. Vault. This was implemented in 2015 - at that time, Vault was at version 0.3.1 or thereabouts - still a fairly early product.
Fast forward to 2021 and Vault is at 1.6.0 and several of its early features have been deprecated and replaced with improved features, but Brooklyn has stood still. In recent PRs[2][3] I've updated the Vault provider to fix the breaking changes between versions 0.3 and 1.6, and to ensure that Brooklyn still works with a near-out-of-the-box configuration of Vault. So Brooklyn is now back at the "minimum" support for Vault - but it's not at the "recommended" level. This is a complicated subject, and I don't claim to fully understand it all. There's also quite a few different options, which vary depending on the environment that Brooklyn is running in. Below I summarise the resources available. I'm not proposing any immediate development effort right now, but if there is demand for using a better Vault implementation, the resources here will be a starting point for discussing implementations. The "Secure Introduction" problem - how you get a secret to an app for it to use to access Vault when you are trying to avoid storing secrets on the app - is talked about at [4]. A number of options are proposed there, depending on the deployment environment. For example, AWS-specific services can be used, if deployment is onto AWS. "Approle"[5][6] is Hashicorp's recommendation for apps to access Vault, but that requires a "trusted entity" to act as an agent to get a secret delivered to Brooklyn. Vault's tutorials describe Chef as a possible entity - it obtains a secret for each new client it sets up, and deploys it into the app it is deploying. Response wrapping[7] provides a way to deliver a secret to the app. Rather than deliver the secret directly, it's placed in a Vault "cubbyhole" and what is delivered is a single-use, short-TTL token. The short TTL means that an attacker has a very short time window to retrieve the secret. The single-use nature means that if an attacker is able to successfully get the secret, the app will know that if it can't retrieve the secret that it has been compromised. I suspect that the large variation of options and deployment environment makes a "one size fits all" approach quite difficult to implement. But interested in other people's thoughts. Richard. [1] https://brooklyn.apache.org/v/latest/ops/externalized-configuration.html#vault [2] https://github.com/apache/brooklyn-server/pull/1136 [3] https://github.com/apache/brooklyn-docs/pull/313 [4] https://learn.hashicorp.com/tutorials/vault/secure-introduction?in=vault/app-integration [5] https://www.vaultproject.io/docs/auth/approle [6] https://learn.hashicorp.com/tutorials/vault/approle [7] https://www.vaultproject.io/docs/concepts/response-wrapping.html
