Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow config to restrict service plans to an exact org set, excluding protected orgs #234

Open
jblackman opened this issue Jul 29, 2020 · 1 comment

Comments

@jblackman
Copy link

jblackman commented Jul 29, 2020

Is your feature request related to a problem? Please describe.
For security reasons, we want to restrict a custom service broker to a set of specific orgs, but using "limited_access_plans" means that protected orgs will also be granted access, which we don't necessarily want.

"Protected" orgs is a dual-use setting: protect from deletion and protect from service-access restrictions. So, whilst I enjoy the comfort of knowing that cf-mgmt won't delete my org, for my use case exposing my custom service to these orgs is a highly undesirable side-effect.

Describe the solution you'd like
Would it be feasible to add a new field to the configuration to exactly specify the orgs? Something like this:

service-access:
- broker: custom-but-secure-broker
  services:
  - service: a.secure.service
    restricted_access_plans: # a.secure.plan is only available to the foo-org
    - plan: a.secure.plan
      orgs:
      - foo-org

If a plan is specified as both "limited_access" and "restricted_access", then I would suggest the result is either undefined (caveat emptor) or an error would be raised.

Describe alternatives you've considered
We can work around this by globally disabling access in config, then having a further pipeline step to enable access just for the org(s) desired. It does leave a window where service instances cannot be created, which is slightly inconvenient :)

Additional context
Is including protected orgs in service plan access controls the best behaviour? The original feature request #84 and its feedback #160 do not define the use case that prompted it.

@mstergianis
Copy link
Contributor

Hi there @jblackman, the team has put this into our tracker and will be reviewing the feature request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants