Question: Is it possible to limit access to certain resources?

[Stijnc]

Limit access to resources

situation

As an Azure adminstrator I want to provide an abstraction layer so the development teams can deploy resources in Azure without direct portal access. OSBA provides this capability, but due to corporate standards I want to limit access to certain resources.

Example

Can I achieve these with native kubernetes RBAC? example: Dev Team A: create MSSQL and keyvault Dev Team B: nothing (I suppose this can be achieved with namespaces + network policies?) Dev Team C: redis and keyvault

Thanks, Stijn

[krancour]

Good question.

@carolynvs does Service Catalog allow whitelists / blacklists on a namespaced ServiceBroker definition? I see that https://github.com/kubernetes-incubator/service-catalog/pull/1773 merged, but I also see that https://github.com/kubernetes-incubator/service-catalog/issues/250 was closed with the conclusion that it couldn't be done. So I'm not sure which it is.

If it can be done, I can't spot the docs for it.

[jeremyrickard]

I'll chime in (I helped write the name-spaced broker stuff)!

@Stijnc, to make this work you'll need to take advantage of some advanced service catalog features, as @krancour points out. I'll link you to some specific documentation pages below, that are found here: https://svc-cat.io/docs/

The two capabilities you'll need to make this work are Namespaced Service Brokers (which you can find documented here: https://svc-cat.io/docs/namespaced-broker-resources/) and the catalog filtering (which you can find documented here: https://svc-cat.io/docs/catalog-restrictions/)

What you'll end up doing is creating a namespace per team. When you define RBAC for that namespace, you'll want to restrict who can create service brokers if you really want to lock things down, so you as the admin could register the broker. Then, you will create a ServiceBroker that points to OSBA for each namespace you want to control, rather than creating the ClusterServiceBroker resource. This could be individual OSBA deployments if you want to use different service principals for the provisioning, or it could be a shared instance that is just registered multiple times.

When you register the ServiceBroker resource, the class and plans get created in that namespace as well when the catalog is listed. You can only create a service instance in that namespace, so the RBAC rules will apply here. I.e. Dev Team A has permission to create a service instance in namespace A, people on Dev Team B don't have access to do so.

The final piece comes from the catalog restrictions. This lets you write things that look like label selectors. There are some examples in the docs above, but I'm not sure they are the best. They essentially let you allow or not allow classes and/or plans. You should be able to filter on the class "external names" though, which should get you want you want.

I'm happy to chat on the kubernetes slack sometime if you need assistance working through this.

[jeremyrickard]

Super simple example:

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBroker
metadata:
  name: example-ns-broker
  namespace: ns-broker
spec:
  authInfo:
    basic:
      secretRef:
        name: my-service-broker-auth
        namespace: broker
  url: http://my-service-broker.broker.svc.cluster.local
  catalogRestrictions:
    servicePlan:
    - "spec.externalName==basic"

This would give you all the Service Plans that are named basic, like we have on a few of our services. You can combine the catalog restrictions and provide both class and plan restrictions.

[jeremyrickard]

I'll also add that we (service catalog) are actively looking for people to use these features and provide feedback, so we'd welcome any you have. The namespaced broker feature gate will also be dropped in the next release and it will be a fully supported capability.

[krancour]

Glad I deferred to @jeremyrickard here. Very clear and well-worded answer.

@Stijnc let us know if this helps.