Most of the kubernetes operators require the ability to create cluster roles, cluster role bindings, and crds.
I want a proper rbac segregation, and I want to avoid to put the deployment service account directly as an admin.
But if I only give it the cluster role edition permissions, it seems that it allows it to put itself admin in the end.
What is the proper way to deal with that? (if there is one).
You can have namespaces and have service accounts with access to only the specific resources and apiGroups that you want.
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitlab-tez-dev # account name
namespace: tez-dev #namespace
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: tez-dev-full-access #role
namespace: tez-dev
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["deployments", "replicasets", "pods", "services"] #resources to which permissions are granted
verbs: ["*"] # what actions are allowed
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: tez-dev-view
namespace: tez-dev
subjects:
- kind: ServiceAccount
name: gitlab-tez-dev
namespace: tez-dev
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: tez-dev-full-accessSo the above role does not have cluster access and it's access if limited to the defined namespace and to the specific resources and actions that are specified.
You can then use it for deployment in the defined namespace.
Have you seen how it's done in case of prometheus-operator ?
It avoids giving deployment service account the full admin rights, especially to let it control permission to perform actions 'create/bind' on roles or clusterroles resources in the 'rbac.authorization.k8s.io' API group.
I think you can use it as a good reference scheme for setting up separate RBAC rules for an operated App and App-Operator.