Should different CF apps get different policies? about vault-service-broker HOT 6 CLOSED

I am missing something. Since I am still relatively new to CF, it was only after reading up on the Service Broker interface that I see know that to achieve the capability I am after requires creating a CF service instance i.e. "cf create-service ... ", for each application, and binding each application to its own service. Creating a service seems to invoke the 'provision' method of the Service Broker API which creates a new 'instance', which in the context of the Vault Service Broker creates instance specific generic secret and transit mounts.

The intuitive (at least for me) approach would have been to have the 'bind' method create the generic secret and transit mounts using the application ID in the path. But I guess that train has sailed.

from vault-service-broker.

Hey there,

Unfortunately this is a limitation of the broker model. We call this out in the README:

All instances of an application will share a token. This goes against the recommended Vault usage, but this is a limitation of the Cloud Foundry service broker model.

If something changes in the future, we'd happily support the new workflow.

from vault-service-broker.

Just to clarify for anyone else reading this issue, my issue is not with 2 instances of an application getting the same token.

My point was that 2 completely different applications (NOT 2 instances of the same application) can bind to the same Vault service instance, and the Vault env vars set for them will contain different tokens, but the backend secret and transit paths (containing the Vault service instance ID) for them will be the same and their different tokens will be assigned the same policy (e.g. cf-_). My mistake was thinking completely different applications should be bound to the same Vault service instance.

The approach taken by the Broker seems to require a Service instance is created for each different application. I suggested a more intuitive approach would be to have the backend secret and transit path contain the application id (e.g. cf/<app-id>/secret) rather than the Service instance id (and have all applications bind to the same Service instance). That seems like it would be a breaking change though, so that is more of a passing comment than a change request.

from vault-service-broker.

I suggested a more intuitive approach would be to have the backend secret and transit path contain the application id (e.g. cf//secret) rather than the Service instance id (and have all applications bind to the same Service instance).

That would be nice... see my comment above though - that's not an oversight in this broker's design; we don't receive that information from the API that way.

from vault-service-broker.

Apologies then, I don't understand your comment above. I assume the relevant bit of your comment is "All instances of an application will share a token." as you say this is a limitation of the CF Service Broker model?

As I was trying to say, I'm not talking about instances of the same application, hence why I don't understand how your comment is relevant to the point I was trying to make. Perhaps you could clarify?

To reiterate, imagine you have a CF app that returns weather results, and a CF that returns movie times. These are obviously two different apps. If you bind these apps to the same Vault service instance via the Vault Service Broker, they get different tokens (this was my experience) but they get the same "backends" e.g. "cf//transit".

You also seem to be saying (I'm probably wrong) that the app id is not available as part of the binding request? Seems like the 'details' parameter passed to the Bind function in the Vault Service Broker is a brokerapi.BindDetails struct that contains AppGUID (based on reading the code, I have no idea if it is actually populated though).

from vault-service-broker.

Hi @samadhicsec

What I'm saying is that we do not get the app ID until the bind phase (https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md), but the mounts are created as part of the provision phase.

from vault-service-broker.