vsphere-csi-node service account missing

**What happened**: vsphere-csi-node DaemonSet is recycling when failing to list ConfigMaps.
```syslog
2023-03-24T18:39:47.672045164Z stderr F E0324 18:39:47.671928 1 reflector.go:178] k8s.io/client-go@v0.18.5/tools/cache/reflector.go:125: Failed to list *v1.ConfigMap: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in the namespace "kube-system"
```

Upon further investigation, the templates in eks-anywhere do not specify service account, cluster role, cluster role binding, role, or role binding manifests as evidenced in the [vsphere-csi-driver.yaml](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/manifests/vanilla/vsphere-csi-driver.yaml#L93-L147) spec in the [kubernetes-sigs/vsphere-csi-driver](https://github.com/kubernetes-sigs/vsphere-csi-driver) repo.

**What you expected to happen**: vsphere-csi-node should be able to list, get, & watch configMap resources in the `vmware-system-csi` or `kube-system` namespace. It should also have the appropriate cluster permissions associated with the service account.

**How to reproduce it (as minimally and precisely as possible)**: Issue exists EKS-A clusters created on vSphere with the CSI resources enabled (default).

**Anything else we need to know?**: n/a

**Environment**:
- EKS Anywhere Release: v0.14.5
- EKS Distro Release: 1.23

Start by comparing the EKS Anywhere vSphere CSI templates with the referenced manifests/vsphere-csi-driver.yaml lines 93-147, focusing on the service account and RBAC resources. Confirm the generated DaemonSet identity and verify that it can list, get, and watch ConfigMaps in the stated namespace without recycling.

Written by the indexing model from the issue text.