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

Change multi-tenancy allowed namespaces to be more restrictive #1288

Closed
nader-ziada opened this issue Apr 1, 2021 · 6 comments · Fixed by #1331
Closed

Change multi-tenancy allowed namespaces to be more restrictive #1288

nader-ziada opened this issue Apr 1, 2021 · 6 comments · Fixed by #1331
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@nader-ziada
Copy link
Contributor

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

  • Currently in the multi-tenancy implemenations, allowed namespaces is by default open to any namespaces
  • Other CAP* provider have a little bit more restrictive approach like the following:
empty allowedNamespaces --> allows all namespaces
nil allowedNamespaces --> blocks all namespaces

nil NamespaceList --> blocks all
nil Selector --> blocks all
  • Consistency between providers is highly desirable, so the request here is to make capz consistent with other providers by adding LabelSelector and following the behaviour mentioned above

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
discussion here: kubernetes-sigs/cluster-api-provider-vsphere#1149 (comment)

Environment:

  • cluster-api-provider-azure version:
  • Kubernetes version: (use kubectl version):
  • OS (e.g. from /etc/os-release):
@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 1, 2021
@nader-ziada
Copy link
Contributor Author

/milestone v0.5.0

@k8s-ci-robot k8s-ci-robot added this to the v0.5.0 milestone Apr 1, 2021
@nader-ziada
Copy link
Contributor Author

/assign

@nader-ziada
Copy link
Contributor Author

I've looked at examples in kubernetes itself and think was wondering if we just should use the labelSelector and not have the []string . We originally added the []string because we had some implementations issues with the label

@gab-satchi @sedefsavas what do you think? why would we need both?

@gab-satchi
Copy link
Member

Having a labelSelector adds flexibility where namespaces can be added/removed without modifying the Identity. I can't think of any advantages the []string brings

@sedefsavas
Copy link

I think one benefit is in terms of security, []string gives us a way to limit the usage of an identity more explicitly and less prone to mistakes like adding matching labels to a namespace that should not have access to an identity. Access control is being more on the identity object side when we define allowedNamespaces as a list.

@devigned
Copy link
Contributor

Say I'm Alex and I want to gain access to your identity. I have access to create a namespace. I create a namespace and label it with something I know your identity will select. Boom, I am now using your identity.

^ I'm really concerned about label selectors with this scenario.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants