Restricting ClusterServiceBroker's Plans/Classes to Namespaces Proposal

[gmrodgers]

The goal of this proposal is to enable the ability for users of the ClusterServiceBroker resource, provided by service-catalog, to restrict which namespaces in a kubernetes cluster that its service classes/plans can be visible/used from, whilst also reducing the toil on the user by only having to register and manage one broker.

Motivation

Currently, if a user of service-catalog wants to restrict the usage of service classes/plans to specific namespaces, they have to use both the namespaced ServiceBroker and filter CatalogRestrictions in their spec. For example, if one wanted to restrict a plan ‘plan-A’ to namespace ‘namespace-1’, one would currently apply the following:

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBroker
  metadata:
    name: broker-name
    namespace: ‘namespace-1’
  spec:
    url: http://broker-url.com
    catalogRestrictions:
      servicePlan:
      - “spec.externalName==plan-A”

But if one wanted to apply this plan restriction to not only ‘namespace-1’ but also namespaces 2..100, then one has to do this 100 times. If one wanted to collate the information of instances/bindings, one would have to do so across 100 namespaces, maintaining a mapping between every one.

Problems

• To achieve the above goal, you have to create and manage a ServiceBroker resource with the correct CatalogRestrictions in every namespace.
• Instances/bindings are split across multiple logical brokers, even though they belong to the same actual broker instance.
• Additional step to register the broker multiple times (along with corresponding secret).
• Changes to the broker need to be added to every single namespaced service broker resource.

Possible Solution

Our proposed solution to this problem is to modify the CatalogRestrictions spec field in the ClusterServiceBroker so that it now has the concept of a namespace. This would look as follows:

spec:
  catalogRestrictions:
    namespaces:
    - namespace-1
    - namespace-2
    servicePlan:
    - “spec.externalName==plan-A for namespace==[namespace-1, namespace-2]”

The ClusterServiceBroker controller would then create the broker’s classes and plans via the namespace-scoped ServiceClass and ServicePlan in the namespaces specified in the CatalogRestrictions. Specifically in this case, ServiceClasss representing the broker’s classes would be created in namespace-1 and namespace-2. And a ServicePlan for representing plan plan-A would be created in namespace-1 and namespace-2.

Another example would be:

spec:
  catalogRestrictions:
    namespaces:
    - namespace-1
    - namespace-2
    - namespace-3
    servicePlan:
    - “spec.externalName==plan-A for namespace==[namespace-1, namespace-2]”

In this case, ServiceClasss representing the broker’s service classes would be created in namespace-1 , namespace-2, and namespace-3. And a ServicePlan for representing plan plan-A would be created in namespace-1 and namespace-2. All plans for each service class for the broker (including plan-A) would have an equivalent ServicePlan in namespace-3.

In the case of deletion of the broker, it would behave similarly to the current behaviour except it would clean up the namespaced versions of the service class and plan resources.

If the namespaces are not specified in the CatalogRestrictions, then the current behaviour will be maintained i.e. the controller will create a ClusterServiceClass and ClusterServicePlan for the broker’s service classes and plans respectively.

Reasons for this solution

• It is intended that this solution will be backward compatible, hence using the namespace specification in the servicePlan and serviceClass string lists.
• Making use of the already existing CatalogRestrictions in Service Catalog

Request For Comment

Would love to get feedback on this proposal, especially with regard to the possible solution. Mainly:

• Is it possible for ServiceClass/ServicePlans to reference a ClusterServiceBroker?
• Is this change feasible? If so, what would be the effort/complexity of such a change?

Thanks!

P.S. Following from the example in #2734, I made this proposal as an issue. Happy to move elsewhere if it works better

[gmrodgers]

hey @kubernetes-sigs/service-catalog-maintainers, if you get time could one of yous take a look/assign assignees!

[gmrodgers]

@mszostok @jberkhahn any chance you folks you could get a chance to look at this!

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/service-catalog/issues/2820#issuecomment-734235608): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[jhvhs]

/reopen /lifecycle frozen

[k8s-ci-robot]

@jhvhs: Reopened this issue.

In response to [this](https://github.com/kubernetes-sigs/service-catalog/issues/2820#issuecomment-735735261): >/reopen >/lifecycle frozen Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[mrbobbytables]

This project is being archived, closing open issues and PRs. Please see this PR for more information: https://github.com/kubernetes/community/pull/6632