Vault support #11
Description
Consider a refinement of #10 through hashicorp Vault integration
Why
Hashicorp vault integration would provide the following features:
- secret revocation/rotation
- secret access loggin & audit
- per app execution transient credentials (such as a DB access credentials, a CF CC API transient revocable token)
Programming model
A service instance provides access to vault API by providing in binding credentials:
- Vault CLI-compatible environment variables
- VAULT_ADDR: the HTTP endpoint to connect to vault
- VAULT_TOKEN: a token used by the application to access secret. This authenticates the applications and is attached authorization (a policy).
- Base-path: the base vault path from which secrets/credentials would be fetched
Native app usage of REST API
The application is then free to use the vault REST API, or one of the SDKs to natively use vault such as dynamically fetch secrets.
One notable library is https://github.com/spring-cloud-incubator/spring-cloud-vault-config and its associated documentation
Refinement with app-id auth backend
If an app were to directly use the appi-id backend, then the app-id backend replaces an injected token with more fine grain accesses through a:
- app-id: found in the VCAP_SERVICES
- user-id: typically the CF app-guid found in VCAP_APPLICATION
The static-creds-broker typically handles the VAULT-TOKEN generation from the vault appid (that identifies the application) and the user id (the CF app GUID). This enables operator to scope authentication to a given CF app GUID (or a set pf appguid, e.g. one per site)
Buildpack integration
For simple applications that don't need to be dependent on vault, and prefer consumming credentials through a standard VCAP_SERVICES environment variables, the buildpack takes the responsibility of invoking vault, fetching secrets, and enriching the VCAP_SERVICES environment variable with them.
Native buildpacks
In this approach, each buildpacks (java, php, ...) adds an option to fetch secret as a pre-start command. This requires to maintain forks of official buildpacks.
Vault-buildpack
In this approach, the pre-start command is factored out in a vault-buildpack that is composeable with other buildpacks to avoid forking each of them. This is a transient solution until CF natively support composeable buildpacks.
The current heroku-buildpack-multi only starts the start cmd from the last buildpack as shown in https://github.com/ddollar/heroku-buildpack-multi/blob/master/bin/release#L3-L4 and make explicit in recent heroku 1st class support for multi-buildpacks https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app#viewing-buildpacks
The last buildpack in the list will be used to determine the process types for the application.
Any process types defined from earlier buildpacks will be ignored.
It is however worth fetching secrets at runtime instead of staging time.
Instead the vault buildpack could itself play the role of the heroku-buildpack-multi, and fetching other buildpacks from http.
Vault decorator producing a runtime hook
The https://github.com/cf-platform-eng/meta-buildpack can be used to invoke a vault decorator which would in turn produce a .profile hook that would be executed at runtime.
See https://github.com/cf-platform-eng/spring-config-decorator/blob/master/bin/compile as a similar example.
Buildpack hooks
The buildpack hooks (currently at the proposal status) enables each application to embed hooks executed at runtime to modify the start command and invoke the vault cli.
This is a light alternative to a php buildpack python extension, and possibly language independent.
This is however duplicated in apps teams, and not centralized within the platform.
Binary service broker
The binary service broker (currently at the proposal status) might distribute the vault CLI binaries within all "binary-service-broker-compatible" buildpacks without forking them.