chore(docs): update rbac guide for shared cluster #3443
Conversation
| ``` | ||
| 2. Create an Azure IAM group for the developers who are allowed to deploy to dev namespaces only. Add all the Users to the group and note the group ID. | ||
|
|
||
| 3. Create a root namespace (`webdev-root` for example) which will have a role that can be inherited by sub-namespaces (all dev namespaces). |
There was a problem hiding this comment.
maybe we could call it just dev-root? Then its also fine for non-webdev projects
There was a problem hiding this comment.
another option could be garden-dev-root
| ``` | ||
| If there is no dedicated development k8s cluster, the following configurations can be used to limit the permissions, of developers on a shared cluster using RBAC (Role-Based Access Control), to specific dev namespaces only. This can help to ensure that developers have the appropriate access to resources on the shared cluster. | ||
|
|
||
| > We have verified to ensure that the following configuration is effective for an Azure IAM group that includes all developers. Similar approach can be followed for any other k8s group mapping. (Contributions, to this doc, are welcome) |
There was a problem hiding this comment.
I would prefer this guide to cover AWS, Azure and GCP. I think the only places where the configuration differs is the mapping between IAM and Kubernetes RBAC.
There was a problem hiding this comment.
Before I go ahead and make changes, I feel we are repeating ourselves especially with this doc.
In my opinion an optimal solution, to make this doc to be valid for all three major* cloud providers, is not keeping it in git book but rather having it as a README in three different example projects (per cloud provider) and having cross reference to that README in the gitbook doc. This way we can also serve with updated config or so. It also makes quite easier to understand when we look at an example than going through the doc. Wdyt?
There was a problem hiding this comment.
Sounds like a good idea too. My thinking was that we get the differences covered here and the rest can more or less stay as is. But the example projects are also a good idea, i will leave that to you :-)
|
|
||
| 1. Install hierarchical namespace controller in the k8s cluster. | ||
| ``` | ||
| kubectl apply -f https://github.com/kubernetes-sigs/hierarchical-namespaces/releases/download/v1.0.0/default.yaml |
There was a problem hiding this comment.
Can we show how to get the latest version of the controller and use that version instead of hardcoding it? Afraid that the version will be outdated pretty soon.
| ``` | ||
| kubectl apply -f https://github.com/kubernetes-sigs/hierarchical-namespaces/releases/download/v1.0.0/default.yaml | ||
| ``` | ||
| 2. Create an Azure IAM group for the developers who are allowed to deploy to dev namespaces only. Add all the Users to the group and note the group ID. |
There was a problem hiding this comment.
| 2. Create an Azure IAM group for the developers who are allowed to deploy to dev namespaces only. Add all the Users to the group and note the group ID. | |
| 2. Next we will need to take care to map your Cloud Provider's IAM groups or users to Kubernetes RBAC. This differs slightly between different cloud providers. The following should give you a brief overview, but might not cover all use cases. Please consider your Cloud Provider's documentation for further info. | |
| For Azure: Create an IAM group for the developers who are allowed to deploy to dev namespaces only. Add all the Users to the group and note the group ID. This group ID can be directly used in `roleBindings` and `clusterRoleBindings`. For more info see [here](https://learn.microsoft.com/en-us/azure/aks/azure-ad-rbac). | |
| For AWS: Add your users to the [aws-auth configmap](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) and add them to an `apiGroup` that you want to use, we will call it `developers` here. This will be your group ID going forward. | |
| For GCP: You can [create a Google group or add IAM users](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control#rolebinding) directly to `roleBindings` and `clusterRoleBindings` We recommend creating a group, as adding single users to several `roleBindings` and `clusterRoleBindings` can become rather tedious. |
| subjects: | ||
| - apiGroup: rbac.authorization.k8s.io | ||
| kind: Group | ||
| name: <Azure IAM group ID> |
There was a problem hiding this comment.
| name: <Azure IAM group ID> | |
| name: <group created in step 2> |
| subjects: | ||
| - apiGroup: rbac.authorization.k8s.io | ||
| kind: Group | ||
| name: <Azure IAM group ID> |
There was a problem hiding this comment.
| name: <Azure IAM group ID> | |
| name: <group created in step 2> |
| subjects: | ||
| - apiGroup: rbac.authorization.k8s.io | ||
| kind: Group | ||
| name: <Azure IAM group ID> |
There was a problem hiding this comment.
| name: <Azure IAM group ID> | |
| name: <group created in step 2> |
| 3. Create a root namespace (`webdev-root` for example) which will have a role that can be inherited by sub-namespaces (all dev namespaces). | ||
|
|
||
| 4. Create a clusterRole and ClusterRoleBinding. | ||
| ``` |
There was a problem hiding this comment.
| ``` | |
| ``` | |
| # Allow reading namespaces and persistent volumes, which are cluster-scoped |
| ``` | ||
|
|
||
| 7. Update project.garden.yaml in order to make sure that sub-namespaces have an annotation (`hnc.x-k8s.io/subnamespace-of: webdev-root` for example) of root namespace where permissions are inherited from. | ||
| ``` |
There was a problem hiding this comment.
I think providing an example garden project is a great idea, but let's remove the unneeded parts like the local kubernetes env and providers and everything else that is not strictly required here.
ghost
marked this pull request as draft
What this PR does / why we need it:
RBAC config guide for scoping permissions when there are no dedicated Dev k8s clusters.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer: