As of now, service account import secrets are copies of remote service account secrets, with an additional "server" field. As such, their format is neither the same as service account secrets, nor the same as kubeconfig files. They are mounted as-is, under /var/run/secrets/admiralty.io/serviceaccountimports/, and the custom pkg/config library is required to create Kubernetes configs from them.
If service account import secrets used the kubeconfig format, client-go itself could create configs from them. Existing Kubernetes clients could use multicluster-service-account with zero code change.
~Note that multiple service account imports can be mounted in a single pod. When a single service account import is mounted, we would mount it in the default kubeconfig location by default, and when multiple service account imports are mounted, we would merge them before mounting them as a single kubeconfig file. client-go already has code to specify which context/cluster should be used from a kubeconfig file.~ [EDIT: We can't modify the content of mounted secrets at admission, so let's just mount them as usual. The user can use the --kubeconfig option or KUBECONFIG environment variable to point to the mounted kubeconfig, or use a path override in code.]
As of now, service account import secrets are copies of remote service account secrets, with an additional "server" field. As such, their format is neither the same as service account secrets, nor the same as kubeconfig files. They are mounted as-is, under
/var/run/secrets/admiralty.io/serviceaccountimports/, and the custompkg/configlibrary is required to create Kubernetes configs from them.If service account import secrets used the kubeconfig format, client-go itself could create configs from them. Existing Kubernetes clients could use multicluster-service-account with zero code change.
~Note that multiple service account imports can be mounted in a single pod. When a single service account import is mounted, we would mount it in the default kubeconfig location by default, and when multiple service account imports are mounted, we would merge them before mounting them as a single kubeconfig file. client-go already has code to specify which context/cluster should be used from a kubeconfig file.~ [EDIT: We can't modify the content of mounted secrets at admission, so let's just mount them as usual. The user can use the
--kubeconfigoption orKUBECONFIGenvironment variable to point to the mounted kubeconfig, or use a path override in code.]