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.

CodePudding user response：

In my opinion the following strategy will help:

1. RBAC to limit access to service accounts of own namespace only.
2. Make sure 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

3. Encrypt secrets stored in ETCD using kms(recommended). But if you dont have a kms provider then you can also choose other providers to ensure minimum security.

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers

CodePudding user response：

Sound like the ClusterRole edit would almost fit your needs. https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles

It will allow access to secrets "However, this role allows accessing Secrets and running Pods as any ServiceAccount in the namespace, so it can be used to gain the API access levels of any ServiceAccount in the namespace."