Overly permissive service account

[wei669]

Hello. We recently sent our charts and images for vulnerability scan, and this is the feedback we received.

The service account "strimzi-cluster-operator" has been granted to a role with high permission, which all actions (* - list/create/delete/patch etc.) secretes, configmaps and other resources. This is an example of an overly permissive service account, because it has more privileges than are necessary to run the application it is associated with.

Here is the permissions associated to the SA:

- apiGroups:
  - ""
  resources:
  - pods
  - serviceaccounts
  - configmaps
  - services
  - endpoints
  - secrets
  - persistentvolumeclaims
  verbs:
  - get
  - list
  - watch
  - create
  - delete
  - patch
  - update

An attacker can access all secrets, update secrets, delete secrets, delete pods etc. This will lead to a malicious user to access other resources or perform denial of services by deleting resources. Is there a way we can reduce the permissions while allowing operator to administrate the cluster? If all these verbs and resources are required, can we remove them using kubectl after spinning up the cluster and etc?

Can we limit the RBAC permissions to namespace level i.e., switch clusterrole to role / rolebinding? Currently the strimzi operator sits in the same namespace as all other services and we have no plan to let strimzi operator to administrate resources outside of its cluster.

[scholzj]

An operator like Strimzi needs to be able to do things such as update or delete secrets or pods. That is how it runs the Kafka clusters. I do not think these permissions are in any way special. These are the things operators do.

Currently the strimzi operator sits in the same namespace as all other services

You should probably use the namespaces a bit better then and have for example different namespace for your Kafka and for your database etc. It might not completely solve any security concerns, but will certainly provide better isolation, make it easier to monitor and debug things etc.

Can we limit the RBAC permissions to namespace level i.e., switch clusterrole to role / rolebinding? Currently the strimzi operator sits in the same namespace as all other services and we have no plan to let strimzi operator to administrate resources outside of its cluster.

That is your call during the installation. If you installed the operator to watch and manage the whole cluster, then it needs Cluster Role Bindings for all its ClusterRoles because you told it to manage Kafka clusters in all namespaces. If you install it to watch for example only its own namespace, it would install for some of the permissions (such as reading secrets) only RoleBindings for the ClusterRoles which give it access only to its own namespace. So this is something you control.

Just keep in mind that Kubernetes are not really a multitenant platform and with resources such as CRDs you need to be careful about installing a separate operator into each namespace for example.

[wei669]

@scholzj Can you share doc or instructions how to install to watch for only its namespace?

[scholzj]

There are no instructions for that. The default installation is watching only its own namespace.