template.metadata.name ignored in sealed secret

[ErikEngerd]

Which component:
sealed secret controller: docker.io/bitnami/sealed-secrets-controller:0.26.3

Describe the bug

When creating a sealed secret with a setting of spec.template.metadata.name different from the name of the sealed secret, a secret is created with name equal to metadata.name of the sealed secret. The metadata.name from the template section is ignored.

To Reproduce

Create a sealed secret.
Add an override for metadata.name in the template section. Example:

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: passwordsecret-ss
spec:
  encryptedData:
    ARTIFACTORY_PASSWORD: YOUR_ENCRYPTED_SECRET_HERE
  template:
    metadata:
      name: passwordsecret

Now a secret named 'passwordsecret-ss' is created, not the expected secret 'passwordsecret'.

Expected behavior
In the above example, a secret with name 'passwordsecret' should be created.

Version of Kubernetes:
kubectl version:

Client Version: v1.29.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.4+k3s1
WARNING: version difference between client (1.29) and server (1.27) exceeds the supported minor version skew of +/-1

Additional context
Add any other context about the problem here.

[ErikEngerd]

NOTE: the kubernetes version is a bit old (I have no control over that). However, the issue should also occur on newer clusters since it is the sealed secret operator that finally decides what the name of the generated secret should be.

[tarikdem]

Just encountered this myself, guessing this is what's causing it:

sealed-secrets/pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go

Lines 327 to 329 in 9439ac6

	// Ensure these are set to what we expect
	secret.SetNamespace(smeta.GetNamespace())
	secret.SetName(smeta.GetName())

Is there a reason the name/namespace need to match the SealedSecret metadata?

[tarikdem]

From the docs:

Note the SealedSecret and Secret must have the same namespace and name. This is a feature to prevent other users on the same cluster from re-using your sealed secrets. See the Scopes section for more info.

[ErikEngerd]

shouldn't the metadata.name configuration be removed then from the template? Having this parameter there suggests that it can be independently configured of the name of the sealedsecret. Right now it silently ignores the name.

Alternatively, users could also be warned in the output of kubectl describe and in the status field of the secret. I realize the change would be downwards incompatible.