Support using resolved org and space names instead of GUID

[z4ce]

As a vault service broker user, I'd like to define policies in a flexible manner using human readable names. It would be very useful if the broker could use the org and space names instead of GUIDs for the paths.

Org path: /cf/foundation-1/organization-2 Space path: /cf/foundation-1/organization-2/space-1 Service ID: /cf/foundation-1/organization-2/space-1/service-name

This way I could define a policy like

path "/cf/foundation-1/organization-2/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

then assign that policy to the user group managing those secrets

vault write auth/ldap/groups/ORG-2-OPS policies=ORG-2-OPS

[sethvargo]

As far as I know, those names aren't available via the API. At least, the service broker API doesn't seem to expose them. Additionally, this is a rather large security risk, since a rename of a group would inherit policies of that group.

[geofffranks]

We have a similar need for this, to allow us to share secrets across multiple production cloud foundry installations.

We were contemplating making a PR that would look up the names from the CF CLI (would require the broker to have a uaa client with admin-read-only privileges), and then mount paths like cf/<organization-name cf/organization-name/space-name, and cf/organization-name/app-name (if we can even nest mounts)

Would this be something you'd entertain for the broker @sethvargo ?

[amanoske]

Hey @geofffranks, This is matching up with a series of needs we've seen with other Vault users. Would love to setup some time to chat, as other members within the Vault team will be managing the PCF broker going forward.

Thanks!

[geofffranks]

@amanoske Sounds great! How should we coordinate?

[geofffranks]

@amanoske When would a good time to talk about this feature be?

[tyrannosaurus-becks]

I know this issue is old, but I saw it and thought I'd circle back on it now.

I did some poking on this and found that it is possible to create a PCF client and do API calls to get the names for orgs, spaces, applications, and service instances using their respective IDs. However, I don't think we should do it for two main reasons - security, and maintenance.

On the security issues, if users were able to provide arbitrary input at any point that went into naming a path, it would be possible to use it to try to dip into spaces with Vault they shouldn't have access to. It also might be possible to dip into a path that had had the same name previously.

On the maintenance issues, what if something were renamed? Things pointed at the old path could diverge from those pointed at the new path. Then there'd need to be a manual migration of secrets, and of getting the old apps to point at the new space. To me the behavior here isn't totally clear and I worry that what seems nice could actually become a way to shoot oneself in the foot.

Anyways, I totally get the UX perspective here of wanting human-readable paths. Yes, that would be wonderful and is a totally valid request! However, I think that the security and maintenance issues outweigh the convenience.

[teancom]

@amanoske Those are considerations I hadn't thought of! However, to be clear, this is not a matter of human-readiblity or convenience for us, it's a requirement in order to be able to use the vault service broker when deploying across multiple PCF foundations.

We have two separate PCF foundations in separate datacenters, managed to have the same ORGs and SPACEs and users. We then use a tool to deploy all apps to both foundations simultaneously. Everything works fine there, but the ORGs and SPACEs have different GUIDs, so an app that's in DC1 can't read/write any secrets from the same app in the same org and space in DC2. Without that ability, it breaks our approach of treating the separate foundations as one.

Hopefully that helps clarify what our need is. Let me know if you have any other questions around this. And thanks for looking back into it!

[Scoobed]

Has there been any movement on this?