Kubernetes RBAC rules for PersistentVolume

PVs, namespaces, nodes and storages are cluster-scoped objects. As a best practice, to be able to list/watch those objects, you need to create ClusterRole and bind them to a ServiceAccount via ClusterRoleBinding. As an example;

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  name: <name of your cluster role>rules:- apiGroups: [""]  resources:  - nodes  - persistentvolumes  - namespaces  verbs: ["list", "watch"]- apiGroups: ["storage.k8s.io"]  resources:  - storageclasses  verbs: ["list", "watch"]---apiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRoleBindingmetadata:  name: <name of your cluster role binding>roleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: <name of your cluster role which should be matched with the previous one>subjects:  - kind: ServiceAccount    name: <service account name>

I see a potential problem here.

PersistentVolumes are cluster scoped resources. They are expected to be provisioned by the administrator without any namespace.

PersistentVolumeClaims however, can be created by users within a particular namespace as they are a namespaced resources.

That's why when you use admin credentials it works but with logdrop it returns an error.

Please let me know if that makes sense.

The new role needs to be granted to a user, or group of users, with a rolebinding, e.g.:

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: logdrop-rolebinding  namespace: logdrop subjects: - kind: User  name: logdrop-user       apiGroup: rbac.authorization.k8s.io roleRef:   kind: Role  name: logdrop-user-full-access   apiGroup: rbac.authorization.k8s.io