You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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.
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.
The text was updated successfully, but these errors were encountered:
Consider a refinement of #10 through hashicorp Vault integration
Why
Hashicorp vault integration would provide the following features:
Programming model
A service instance provides access to vault API by providing in binding credentials:
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:
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
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.
The text was updated successfully, but these errors were encountered: