The ASM plugin currently has four Kubernetes API permissions that are all cluster-scoped (not node-scoped), and could benefit from paring them down by making certain ones optional or removing them altogether. Ideally, the ASM plugin would not require any permissions of its own from Kubernetes or AWS, so that the principal of least permissions is followed.
From https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/deployment/private-installer.yaml#L13-L24
- apiGroups: [""]
resources: ["serviceaccounts/token"]
verbs: ["create"]
- apiGroups: [""]
resources: ["serviceaccounts"]
verbs: ["get"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["get"]
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get"]
The ASM plugin currently has four Kubernetes API permissions that are all cluster-scoped (not node-scoped), and could benefit from paring them down by making certain ones optional or removing them altogether. Ideally, the ASM plugin would not require any permissions of its own from Kubernetes or AWS, so that the principal of least permissions is followed.
From https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/deployment/private-installer.yaml#L13-L24
GETonserviceaccountsis used for IRSA-based auth to get a pod's IAM role via an annotation. For installations using EKS Pod Identity, this can be removed (you could use a condition in the helm chart template to make this optional)Its worth noting that Kubelet today has permissions to list all pods (but not nodes), but this permission is going to be restricted in future versions of Kubernetes to only allow a node to list the pods running on it.