Alibaba Disk CSI driver operator gives the CSI driver env. variable ALIBABA_CLOUD_CREDENTIALS_FILE, pointing to a Secret file provided by CCO / ccoctl with this content: [default] type = access_key access_key_id: xxxxxxx access_key_secret: yyyyy The CSI driver ignores this file and loads some credentials from the cloud instance metadata: time="2021-11-30T19:24:09Z" level=info msg="Get AK: use STS" time="2021-11-30T19:24:09Z" level=info msg="Starting csi-plugin with sts" These metadata credentials seem to be enough for the driver to work (provision + attach + mount volumes), still, the CSI driver should use credentials provided by CCO. This is tracked upstream as https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/issues/557.
I tested the upstream PR, it works well. It needs to be merged upstream before we can use it. It will be painful to backport, but that's our job.
Assigning to Bo Teng, as Jiao Wang (our storage contact in Alibaba) does not have Bugzilla account yet. The upstream PR https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/pull/572 needs to be reviewed and merged and then we need either Alibaba to do a new release of the driver or Red Hat to backport the patch to 1.1.4, which is quite old.
Note that this is a blocker and it must be fixed before code freeze!
The upstream PR https://github.com/kubernetes-sigs/alibaba-cloud-csi-driver/pull/572 has been merged.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0056