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

Feature: allow flexible subjects for clusterrolebindings/rolebindings #41

Open
stjudecloud-cloudy opened this issue Aug 24, 2020 · 2 comments

Comments

@stjudecloud-cloudy
Copy link

In Azure AKS users can have access granted by either by their AD group membership, or directly using AD user ID. It would be extremely useful, if user access management could be done using permission-manager.

In order to achieve it, it would be necessary to allow different kind of subjects for both clusterrolebinding and rolebinding.
This is an example of clusterrolebinding used for assigning RBAC to AD group:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-developer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: id-redacted

Similarly kind: User can be used to grant a specific user access to Kubernetes using RBAC.
Ideally, web interface should allow creation of different kind of subjects and used created subjects for access grants.

@angelbarrera92
Copy link
Contributor

Uhmm we have to analyze it. Currently, when a permissionmanageruser is created, then a serviceaccount is created too. So all bindings stick to the serviceaccount subject.

Changes to 🔝 behaviour is a major change that we have to evaluate, but we understand the situation.

@sandeepcp
Copy link

This is just creating a service account. We would like to see more functionality like Role Role bindings
As per the document, service account is just for application and jobs

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

No branches or pull requests

3 participants