run with reduced permissions (Role instead of ClusterRole)

[wdw-jst]

Is your feature request related to a problem? Please describe. We wanted to use kubernetes-replicator within a shared Kubernetes Cluster (Rancher), where creation of ClusterRole and ClusterRolebinding is not permitted. We use the following RBAC setup:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: replicator-kubernetes-replicator
  namespace: replicator
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: replicator-kubernetes-replicator
  namespace: replicator
rules:
- apiGroups: [ "" ]
  resources: [ "namespaces" ]
  verbs: [ "get", "watch", "list" ]
- apiGroups: [""]
  resources: ["secrets", "configmaps"]
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "rolebindings"]
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: replicator-kubernetes-replicator
roleRef:
  kind: Role
  name: replicator-kubernetes-replicator
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: replicator-kubernetes-replicator
  namespace: replicator

This should give the service account the permission to access the resources within our project.

We deploy the kubernetes-replicator into the same namespace replicator. However the container failed to start with erros like

pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1.ConfigMap: failed to list *v1.ConfigMap: configmaps is forbidden: User "system:serviceaccount:replicator:replicator-kubernetes-replicator" cannot list resource "configmaps" in API group "" at the cluster scope

The message shows for other resources as well (namespaces, secrets, ...)

Describe the solution you'd like kubernetes-replicator to work in shared Kubernetes Cluser (e.g. Rancher, OpenShift) within scope of project.

Describe alternatives you've considered None

Additional context We also tried the same Role with a dedicated Kubernetes Cluster, also without success

[mittwald-machine]

There has not been any activity to this issue in the last 14 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

[martin-helmich]

Thanks for the report :+1: and sorry for the late response. 🙄🙏 This might be one of these issues that are more complicated than they first appear. 🤯 Some thoughts:

1. The entire replicator was designed with the goal in mind to replicates resources across namespaces. By definition, it'll need read/write access to multiple namespaces for that. Using the replicator in a single namespace was never the intended use case, since in that case you won't need it for most of the use cases it was designed to solve.
2. Apart from using a ClusterRoleBinding to grant access to all namespaces, granting access to a select subset of namespaces should also be possible using a ClusterRole (or multiple Roles in different namespaces) with different namespaced RoleBindings.
3. HOWEVER, the replicator in its current state won't play along with that, because it sets up its informers using un-namespaced WATCH and LIST calls to the replicated resources (like the configmap replicator here), which still require cluster-wide access. To support multiple-namespaces, the replicator would need to be refactored to use multiple informers (one for each namespace), which would further complicate replication logic.

Realistically, I don't see us finding the resources to implement a major change like this one anytime soon. However, PRs are always welcome. 🙂