[Bug] ParseClientSecret rejects Opaque secrets for AuthModeTLS

[ConnorGraham]

Summary

ParseClientSecret enforces corev1.SecretTypeTLS for mTLS connections, but many organizations
store TLS credentials in Opaque secrets to support multiple files in a single secret (e.g.,
tls.crt, tls.key, and ca.crt together). The Kubernetes kubernetes.io/tls secret type only
natively supports two keys (tls.crt and tls.key), so teams that need to bundle a CA cert
alongside the keypair must use Opaque.

Steps to Reproduce

1. Create a Kubernetes Opaque secret containing tls.crt, tls.key, and optionally ca.crt
2. Configure a TemporalWorker with AuthModeTLS referencing that secret
3. Observe: reconciler fails with secret <name> must be of type kubernetes.io/tls

Expected Behavior

The controller should accept both corev1.SecretTypeTLS and corev1.SecretTypeOpaque for
AuthModeTLS, as both can contain the required tls.crt / tls.key data. The actual credential
parsing in fetchClientUsingMTLSSecret already reads the keys by name (secret.Data["tls.crt"],
secret.Data["tls.key"]), so no further changes are needed there — only the type guard in
ParseClientSecret needs relaxing.

Affected Code

File: internal/controller/clientpool/clientpool.go:252

case AuthModeTLS:
    if secret.Type != corev1.SecretTypeTLS {
        err := fmt.Errorf("secret %s must be of type kubernetes.io/tls", secret.Name)
        return nil, nil, nil, err
    }
    return cp.fetchClientUsingMTLSSecret(secret, opts)

Suggested Fix

case AuthModeTLS:
    if secret.Type != corev1.SecretTypeTLS && secret.Type != corev1.SecretTypeOpaque {
        err := fmt.Errorf("secret %s must be of type kubernetes.io/tls or Opaque", secret.Name)
        return nil, nil, nil, err
    }
    return cp.fetchClientUsingMTLSSecret(secret, opts)

Additional Context

• The fetchClientUsingMTLSSecret function is already key-name-driven and works correctly with
  Opaque secrets containing the right keys — only the type assertion blocks it.
• Standard Kubernetes tooling (e.g., cert-manager) can issue either secret type depending on
  configuration.
• This restriction breaks organizations that bundle tls.crt, tls.key, and ca.crt into a
  single Opaque secret, which is a common pattern for managing multiple file-based credentials.

[carlydf]

Thanks for reporting this! Sounds reasonable to me. @jaypipes what do you think?