Least privilege RBAC for VSO

[dnlopes]

Describe the bug I'm trying to setup a least privilege RBAC role for the VSO, and so far I was unable to define one that works. The ClusterRole I'm defining is the one below, which does not seem to work:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-vso-cluster-role
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["apiextensions.k8s.io"]
    resources: ["customresourcedefinitions"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["clusterroles", "clusterrolebindings"]
    verbs: ["get", "list"]

Do you have any guidelines on the least privilege RBAC that VSO requires for a proper setup?

Thank you!

[dnlopes]

After some try and error I came up with the following ClusterRole which seems to work:

# cluster wide permissions (least privilege) for the csi-vso ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-vso-cluster-role
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs:
      [
        "get",
        "list",
        "watch",
        "create",
        "update",
        "patch",
        "delete",
        "deletecollection",
      ]
  - apiGroups: ["apiextensions.k8s.io"]
    resources: ["customresourcedefinitions"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["clusterroles", "clusterrolebindings"]
    verbs: ["get", "list", "delete", "create"]
  - apiGroups: ["authorization.k8s.io"]
    resources: ["subjectaccessreviews"]
    verbs: ["create"]
  - apiGroups: ["authentication.k8s.io"]
    resources: ["tokenreviews"]
    verbs: ["create"]
  - nonResourceURLs: ["/metrics"]
    verbs: ["get", "post"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "patch"]
  - apiGroups: [""]
    resources: ["serviceaccounts"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["serviceaccounts/token"]
    verbs: ["create", "get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["daemonsets", "deployments", "statefulsets"]
    verbs: ["get", "list", "patch", "watch"]
  - apiGroups: ["secrets.hashicorp.com"]
    resources: ["*"]
    verbs: ["*"]
  - apiGroups: ["apps"]
    resources: [""]
    verbs: [""]

I'm not sure what I expect from this open issue though. I guess having this documented somewhere on Hashicorp (or this repo) would be good, to avoid granting admin permissions for the VSO.

In any case, I'm ok in closing this issue.

[kschoche]

HI @dnlopes - Thanks for tracking this down, I certainly do agree that we should have a goal of using least priv for RBAC. I took a little look and I'm trying to piece together the deltas between what you found and what we have. Aside from the obvious of using secrets.hashicorp.com with a ["*"], most of the other fields seem little changed to my eyes except for the tokenreview+customresourcedefinitions resources. Is there a reason why these are a preferred method over how we're originally doing it?

Thanks! ~Kyle

[0xmeyer]

@kschoche I assume that the resources tokenreviews and subjectaccessreviews were included, because otherwise an extra service account with the role system:auth-delegator has to be created for the Kubernetes Auth Method. If the two RBAC rules could be included, it would certainly be a significant improvement (in my opinion).