Kubernetes RBAC rules for PersistentVolume

7/1/2019

I'm trying to create RBAC Role / rules for a service that needs a persistent volume and it's still failing with forbidden error.

Here is my role config:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: logdrop-user-full-access
  namespace: logdrop
rules:
- apiGroups: ["", "extensions", "apps", "autoscaling"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

And this is my cut down PersistentVolume manifest:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: logdrop-pv
  namespace: logdrop
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    namespace: logdrop
    name: logdrop-pvc
  hostPath:
    path: /efs/logdrop/logdrop-pv

When I try to apply it I get a forbidden error.

$ kubectl --kubeconfig ~/logdrop/kubeconfig-logdrop.yml apply -f pv-test.yml 
Error from server (Forbidden): error when retrieving current configuration of:
Resource: "/v1, Resource=persistentvolumes", GroupVersionKind: "/v1, Kind=PersistentVolume"
Name: "logdrop-pv", Namespace: ""
Object: &{map["apiVersion":"v1" "kind":"PersistentVolume" "metadata":map["annotations":map["kubectl.kubernetes.io/last-applied-configuration":""] "name":"logdrop-pv"] "spec":map["accessModes":["ReadWriteMany"] "capacity":map["storage":"10Gi"] "claimRef":map["name":"logdrop-pvc" "namespace":"logdrop"] "hostPath":map["path":"/efs/logdrop/logdrop-pv"] "persistentVolumeReclaimPolicy":"Retain"]]}
from server for: "pv-test.yml": persistentvolumes "logdrop-pv" is forbidden: User "system:serviceaccount:logdrop:logdrop-user" cannot get resource "persistentvolumes" in API group "" at the cluster scope

On the last line it specifically says resource "persistentvolumes" in API group "" - that's what I have allowed in the rules!

I can create the PV with admin credentials from the same yaml file and I can create any other resources (pods, services, etc) with the logdrop permissions. Just the PersistentVolume doesn't work for some reason. Any idea why?

I'm using Kubernetes 1.15.0.

Update:

This is my role binding as requested:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: logdrop-user-view
  namespace: logdrop
subjects:
- kind: ServiceAccount
  name: logdrop-user
  namespace: logdrop
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: logdrop-user-full-access

It's not a ClusterRoleBinding as my intention is to give the user access only to one namespace (logdrop), not to all namespaces across the cluster.

-- KeepLearning
kubernetes
rbac

3 Answers

3/10/2020

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/v1
kind: ClusterRole
metadata:
  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/v1beta1
kind: ClusterRoleBinding
metadata:
  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>
-- Onur Yılmaz
Source: StackOverflow

7/1/2019

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
-- codemonkey
Source: StackOverflow

7/9/2019

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.

-- OhHiMark
Source: StackOverflow