Skip to content
This repository has been archived by the owner on May 6, 2022. It is now read-only.

ACL for controlling access to ServiceClasses #250

Closed
duglin opened this issue Jan 12, 2017 · 9 comments
Closed

ACL for controlling access to ServiceClasses #250

duglin opened this issue Jan 12, 2017 · 9 comments
Milestone

Comments

@duglin
Copy link
Contributor

duglin commented Jan 12, 2017

When a broker is registered with a service controller, who in Kube can see those services? Everyone? Do we want to have some kind of ACL to limit apps in certain namespaces to certain services?

We should probably discuss what we want for MVP-1, for later and what we want to do to allow for future tweaks to this decision that are backwards compatible.

@duglin duglin added this to the MVP 1 milestone Jan 12, 2017
@arschles
Copy link
Contributor

...who in Kube can see those services?

@duglin our decision, as of the last face-to-face meeting, was to put the ServiceClasses resulting from a Broker addition into the "global" namespace

We should probably discuss what we want for MVP-1, for later and what we want to do to allow for future tweaks to this decision that are backwards compatible.

I think we should discuss this after MVP-1. We have a lot on our place and it'll be much easier to add an (optional) ACL (or similar) than to rush something and replace it later.

@MHBauer
Copy link
Contributor

MHBauer commented Jan 13, 2017

related to #162?

@pmorie
Copy link
Contributor

pmorie commented Mar 1, 2017

My opinion on where we stand on this: in MVP, there will not be controls on this. We should have a policy of some type that determines whether a particular user can see a particular service class. There are a number of options for how we could do this, and I sincerely doubt that we will have any time before kubecon to discuss them.

So, I think we can either move this issue to the 'Later' milestone, or close it (since it is decided for the moment) and create a new issue to add a policy resource.

@pmorie pmorie modified the milestones: Later, MVP 1 Mar 6, 2017
@arschles arschles removed this from the Later milestone Apr 3, 2017
@arschles
Copy link
Contributor

arschles commented Apr 3, 2017

Moving to 1.0.0 since this is related to the RBAC we speak of in the roadmap

@arschles arschles added this to the 1.0.0 milestone Apr 3, 2017
@pmorie pmorie changed the title What is the scope of a service controller? ACL for controlling access to ServiceClasses May 12, 2017
@pmorie
Copy link
Contributor

pmorie commented Dec 19, 2017

We discussed a couple different possibilities for this at the November 2017 face to face. Writing RBAC policies that the controller checks is fairly easy to do. Implementing ACL filtered list in Kubernetes, however is not.

@pmorie
Copy link
Contributor

pmorie commented Dec 19, 2017

My own opinion, having argued originally for RBAC rules and ACL filtered list: we probably need to look at ways to expose cluster-scoped serviceclasses and plans into individual namespaces in a way that is controlled by policy.

@carolynvs
Copy link
Contributor

This is on the roadmap for GA. Will it be resolved with the blacklist/whitelist PR once it's merged? Otherwise I think it needs to be removed from the milestone.

@n3wscott
Copy link
Contributor

We get close after catalog restrictions, and all the way there after namespaced brokers/classes/plans.

@pmorie
Copy link
Contributor

pmorie commented May 14, 2018

I think we should close this issue - since we've established that ACL filtered list/watch is essentially not possible today.

I'm happy to leave it open if people want, but this isn't a feature we have a path to deliver in its original form.

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

No branches or pull requests

6 participants