I am currently facing the current situation. I want to give users access to individual namespaces, such that they can
- create and deploy ressources with Helm charts (for instance, from Bitnami)
On the other hand the users are not supposed to
- create/retrieve/modify/delete RBAC settings like ServiceAccounts, RoleBindings, Roles, NetworkPolicies
- get hands on secrets associated to ServiceAccounts
Of course, the crucial thing is to define the best Role for it here. Likely, the following is not the best idea here:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: role
namespace: example-namespace
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
Hence, it would be great if you could come along with some sensible approach that the users can work on it as freely as possible, yet do not get hands on some more "dangerous" resources.
In essence, I want to follow the workflow outlined here (https://jeremievallee.com/2018/05/28/kubernetes-rbac-namespace-user.html). So what matters most is that individual users in one namespace, cannot read the secrets of the users in the same namespace, such that they cannot authenticate with the credentials of someone else.
In my opinion the following strategy will help:
automountServiceAccountToken: false
in secret and POD level using policies. This helps in protecting secrets when there is a node security breach. The secret will only be available for execution time and will not be stored in the POD.https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers