Secret not fetched from current namespace, but from the default namespace

Question

I have some deployments running in a custom namespace. They reference a secret azure-files to obtain the credentials to map a volume. This mapping is done like this:

volumes:
- azureFile:
    secretName: azure-files
    shareName: myshare
  name: azure

When I apply the YAML, then the pods try to spin up, but fail. When I describe the pod I see the following error:

Type     Reason       Age                From               Message
----     ------       ----               ----               -------
Normal   Scheduled    26s                default-scheduler  Successfully assigned development-l56t08/develop-is4-58b4d966b4-948dw to aks-agentpool-41062645-vmss000002
Warning  FailedMount  10s (x6 over 26s)  kubelet            MountVolume.SetUp failed for volume "azure" : Couldn't get secret default/azure-files

For some reason Kubernetes attempts to fetch the secret from the default namespace instead of my own namespace. When I add the secret to the default namespace, everything works. Does anyone know how to solve this? I was under the impression that you couldn't even reference secrets in other namespaces.

The secret does exist in my namespace and other secrets seem to work fine...

Answer 1

It is a bug in AKS code.

Whatever the CSI driver mechanism does with secrets must remain backwards compatible with and adapt to the in-tree implementations, not the other way around.

Please revert #97417 and pick to 1.18-1.20 to restore compatibility to the 1.18-1.20 releases. This needs to happen before 1.18 leaves maintenance ( https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md#118 )

the csi translation library change in https://github.com/kubernetes/kubernetes/pull/97877/files#r596900593 may need adjustment as well

For track the bug check: azurefile-aks .