Add a namespaced version of ServiceBroker, ServiceClass, and ServicePlan

[pmorie]

I have had a number of interested parties asking for namespaced versions of ServiceBroker, ServiceClass and ServicePlan. I think this is perfectly valid and would be similar to what CF does (global and org-scoped brokers). We should consider this for the second beta release, but it is NOT a 0.1.0 item.

[duglin]

From #1233:

Right now brokers, classes and plans are global, meaning they are cluster-wide and are not scoped to a particular namespace. There are going to be times when people will want things localized to a namespace. We need to consider how we'll support these.

Some notes:

• Global Broker/NS Classes : may not be a visibility issue, rather its an RBAC/ACL issue. Meaning, we may not be able to hide these classes from people in other namespaces, but we should be able to block their ability to use them via some policy mechanism. For example, define a "policy" resource that defines who has what access to the Class, or add data to the class itself to represent this info. Then use an admin controller to allow/block usage.
• NS Broker : would be visible to just the NS. We may need to create new resources (e.g. LocalServiceBroker/Class/Plan) since current resources are non-NS scoped.
• Global Instances : how do we deal with instances that are not scoped to a namespace?

marking this a v0.1.0 since I think we need to discuss and make sure we don't need changes before beta. Of the ones listed above I think the "Global Instances" one might need to be addressed before beta because if we prepend the word "Local" to Broker/Class/Plan to indicate they're NS-specific, then perhaps our current ServiceInstance should be LocalServiceInstance too?

--

If we do support global instances I wonder how we'll create bindings/creds. I believe that secrets are bound to namespaces, so that might mean that to get the creds for a global instance we'd need to bind it to a namespace. While that may be necessary from an ACL perspective in Kube, it seems to defeat the purpose of a "global" instance. Although, having a "global" resource could mean that you're doing admin (cluster-wide) type of stuff anyway, so perhaps there won't be the notion of bindings/creds at all for these types of services. The ACL side of it will be done via the OriginatingIdentity header on the provision request. Just wondering....

[pmorie]

We discussed the naming of resources re: this problem in the SIG Arch meeting on Sept 28, 2017. The consensus was that the cluster-scoped resources should be called Cluster*.

Created #1288 for this

[duglin]

Closing since #1288 should cover it

[nilebox]

@duglin Hrm, the #1288 is only about renaming the current (cluster-scoped) resources. I guess we need to keep this issue open for tracking adding support for namespace-scoped ones?

[duglin]

yea I guess so

[pmorie]

For the record, for anyone watching - we do not intend for this to block the beta, we are only interested in ensuring that we have a good forward-compatible design.

[ash2k]

Having this feature would be very useful for us. We need it for namespaced integration testing of various usage scenarios. Both for OSB providers and for Instance/Binding consumers.

[jboyd01]

I've started a proposal on this, hope to have it for review Jan 29th 2018.

[MHBauer]

@eriknelson has #dibs on impl with lots of PRs merged and in-progress

[MHBauer]

/close
server-side complete, docs partially complete, client side in progress