@alfredkrohmer i just created this issue to track your problem.

Just discovered this while testing the 0.5.0 release, this change breaks a use case that we have: not specifying the namespace in the secretRef or kubernetesServiceAccountToken sections in the auth spec for certain providers (Vault in our case) in ClusterSecretStores. The namespace of the ExternalSecret referring to the ClusterSecretStore would then be used when authenticating against the provider.

Implementation for secretRef in Vault provider:

external-secrets/pkg/provider/vault/vault.go

Lines 829 to 832 in 787129e

	ref := types.NamespacedName{
	Namespace: v.namespace,
	Name: secretRef.Name,
	}

Implementation for kubernetesServiceAccountToken in Vault provider:

external-secrets/pkg/provider/vault/vault.go

Lines 853 to 861 in 787129e

	tokenRequest := &authenticationv1.TokenRequest{
	ObjectMeta: metav1.ObjectMeta{
	Namespace: v.namespace,
	},
	Spec: authenticationv1.TokenRequestSpec{
	Audiences: audiences,
	ExpirationSeconds: &expirationSeconds,
	},
	}

Originally posted by @alfredkrohmer in #750 (comment)

So, the behavior you describe is not intended. The ClusterSecretStore should point to a single service account in a particular namespace and not use a SA from the namespace the ExternalSecret is in.

I guess it is this line specifically that shouldn't be there.

I'm interested in how your use-case looks in detail, can you provide more information? Do you basically share one ClusterSecretStore that points to a vault and configures things "globally" but the authentication bits lie in each and every namespace?