Operator fails to load credentials from clusterRef when SASL is enabled

[fstr]

When creating a topic via the Topic CRD, the operator is not able to correctly use the bootstrap-user or superuser credentials from the cluster spec. This happens when sasl.bootstrapUser.secretKeyRef is used AND sasl.secretRef is used (without a sasl.users list).

"error":"failed topic (twitch-chat) metadata retrieval library error: broker closed the connection immediately after a request was issued, which happens when SASL is required but not provided: is SASL missing?

The bug is in redpanda-operator/charts/redpanda/client/client.go function authFromDot. This function is first trying to fetch the bootstrap user via SecretBootstrapUser but returns early with the given config. It then falls back to fetch the superuser via SecretSASLUsers, but the function returns nil. We end up with no SASL credentials and the request to create a topic fails.

func SecretBootstrapUser(dot *helmette.Dot) *corev1.Secret {
	values := helmette.Unwrap[Values](dot.Values)
	if !values.Auth.SASL.Enabled || values.Auth.SASL.BootstrapUser.SecretKeyRef != nil {
		return nil // we end up here
	}

// secrets.go
func SecretSASLUsers(dot *helmette.Dot) *corev1.Secret {
	values := helmette.Unwrap[Values](dot.Values)

	if values.Auth.SASL.SecretRef != "" && values.Auth.SASL.Enabled && len(values.Auth.SASL.Users) > 0 {
           ...
	} else if values.Auth.SASL.Enabled && values.Auth.SASL.SecretRef == "" {
		panic("auth.sasl.secretRef cannot be empty when auth.sasl.enabled=true")
	} else {
		return nil // we end up here
	}

Specs:
The topic has the following spec:

apiVersion: cluster.redpanda.com/v1alpha2
kind: Topic
metadata:
  name: twitch-chat
spec:
  partitions: 1
  replicationFactor: 3
  cluster:
    clusterRef:
      name: mycluster

The cluster has the following spec:

apiVersion: cluster.redpanda.com/v1alpha2
kind: Redpanda
spec:
  clusterSpec:
    auth:
      sasl:
        bootstrapUser:
          mechanism: SCRAM-SHA-512
          name: bootstrap-user
          secretKeyRef:
            key: password
            name: redpanda-bootstrap-user
        enabled: true
        mechanism: SCRAM-SHA-512
        secretRef: redpanda-superuser
...

Environment:

• Operator: v25.1.3
• Redpanda: v25.2.5
• Kubernetes: 1.33

What makes this code error prone is that it is used in two different use cases. One use case is that the operator creates the secrets if they don't exist. The other use case is that the operator tries to load credentials from the secrets using the same code.

This code has been refactored on the main branch but from glancing over it, I assume the same bug still exists on main.

[fstr]

Possible workarounds for anyone coming here:

1. Don't set the bootstrap-user secret via sasl.bootstrapUser.secretKeyRef. Let the redpanda-operator generate it

2. Don't use sasl.secretRef or use it in combination with a sasl.users list. This is not an option for most users of the chart, as it requires putting the password in plaintext into the Redpanda cluster manifest.

3. Don't use spec.cluster.clusterRef on the Topic CRD and instead use spec.cluster.staticConfiguration

[andrewstucki]

Hi @fstr thanks for the bug report. I'm actively refactoring some of the client construction code at the moment in #1136 and will make sure this is regression tested there.