Unable to create PVC due to missing ClusterRole access to secret for dynamic efs

[fbrousse]

/kind bug

What happened?

The creation of a PVC fails due to missing permissions when using dynamic EFS provisioning.
We can see this error log in the efs-csi-controller pod :

I0513 07:49:31.449884 1 event.go:282] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"my-ns", Name:"fbr-testing", UID:"7fb0a868-4237-40ed-adac-d7d1a62c2acf", APIVersion:"v1", ResourceVersion:"364527245", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' failed to provision volume with StorageClass "efs-dynamic": error getting secret efs-dynamic in namespace kube-system: secrets "efs-dynamic" is forbidden: User "system:serviceaccount:kube-system:efs-csi-controller-sa" cannot get resource "secrets" in API group "" in the namespace "kube-system"

What you expected to happen?

The creation of a new PVC using the class referenced for dynamic provisioning (in the case efs-dynamic) should work.

How to reproduce it (as minimally and precisely as possible)?

Deploy the driver and try to create a PVC as this one :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fbr-testing
  namespace: my-ns
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-dynamic
  resources:
    requests:
      storage: 5Gi

Anything else we need to know?:

This is related to these lines commented out :

aws-efs-csi-driver/deploy/kubernetes/base/controller-serviceaccount.yaml

Line 39 in cff2c27

# - apiGroups: [ "" ]

Maybe we can narrow down the permissions to only the name of the secret (that's what I did to fix)

Environment

• Kubernetes version (use kubectl version): 1.21
• Driver version: aws-efs-csi-driver:v1.3.7

[universam1]

related to #677 #674 ?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[universam1]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.