Requesting your assistance with an issue where the customer reported a service degradation. Many pods using PVCs were unable to start due to a timeout error while waiting for the external-attacher of the disk.csi.azure.com CSI driver to attach the volume. 

The issue was traced back to a missing service account (azure-disk-csi-driver-node-sa) in the federated credentials for the disk CSI driver.The root cause of the problem seems to be the missing service account (azure-disk-csi-driver-node-sa) in the federated credentials for the disk CSI driver which when added was fixed.This is a standard installation of OCP with Federated IDs on Azure.  

I need your help in identifying if the third service account that runs the csi-disk-node pods has been missed by mistake or on purpose.Configuration of *openshift-cluster-csi-drivers-azure-file-credentials reports 3 different service accounts:

1) azure-file-csi-driver-operator
system:serviceaccount:openshift-cluster-csi-drivers:azure-file-csi-driver-operator
2) azure-file-csi-driver-controller-sa
system:serviceaccount:openshift-cluster-csi-drivers:azure-file-csi-driver-controller-sa
3) azure-file-csi-driver-node-sa
system:serviceaccount:openshift-cluster-csi-drivers:azure-file-csi-driver-node-sa but the one for *openshift-cluster-csi-drivers-azure-disk-credentials has only 2 service accounts:

1) azure-disk-csi-driver-operator
system:serviceaccount:openshift-cluster-csi-drivers:azure-disk-csi-driver-operator
2) azure-disk-csi-driver-controller-sa
system:serviceaccount:openshift-cluster-csi-drivers:azure-disk-csi-driver-controller-sa

1. This is a standard installation of OCP with Federated IDs on Azure