Accept Opaque secrets as TLS credentials for backward compatibility

[AryanP123]

Fixes #2518

Summary by CodeRabbit

• New Features

  • TLS credentials can now be recognized from compatible secrets even when they are not explicitly marked as TLS.
  • Syncing now supports TLS profiles backed by opaque secrets, improving compatibility with existing setups.

• Bug Fixes

  • Fixed secret detection so TLS-related configuration is applied more reliably across supported secret types.
  • Improved handling of nil or incomplete secrets to avoid false matches.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds an IsTlsCredentialSecret helper that identifies TLS-capable Kubernetes Secrets by checking type and required data keys, allowing Opaque-typed secrets with tls.crt, tls.key, and ca.crt to be treated as TLS credentials. Updates secret manager and sync handlers to use this helper, plus adds corresponding tests.

Changes

TLS Credential Detection

Layer / File(s)	Summary
IsTlsCredentialSecret helper and tests internal/kube/secrets/context.go, internal/kube/secrets/context_test.go	Adds exported IsTlsCredentialSecret function handling nil secrets, SecretTypeTLS, and backward-compatible SecretTypeOpaque/empty-type secrets with required TLS data keys; adds unit test suite covering multiple type/data combinations.
Secret manager dispatch update internal/kube/secrets/manager.go	handleSecret and TlsCredentialSecretPresent now use IsTlsCredentialSecret instead of direct secret.Type comparison to select the TLS branch and scan cached secrets.
Sync handler dispatch and integration test internal/kube/secrets/sync.go, internal/kube/secrets/sync_test.go	(*Sync).handle restructures its type switch to use IsTlsCredentialSecret for TLS branch matching while retaining basic-auth type check; adds TestSyncHandlerOpaqueTlsSecret and fixtureOpaqueTlsSecret verifying an Opaque secret resolves an SSL profile.

Estimated code review effort: 2 (Simple) | ~15 minutes

Sequence Diagram(s)

sequenceDiagram
    participant SecretWatcher
    participant SyncHandle as Sync.handle
    participant IsTlsCredentialSecret
    participant SslProfile

    SecretWatcher->>SyncHandle: notify Secret (type Opaque, TLS data)
    SyncHandle->>IsTlsCredentialSecret: check(secret)
    IsTlsCredentialSecret-->>SyncHandle: true (tls.crt, tls.key, ca.crt present)
    SyncHandle->>SslProfile: handleSslProfile(secret)
    SslProfile-->>SyncHandle: profile updated
    SyncHandle->>SyncHandle: doCallback()

Loading

Related Issues: #2518

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The code updates TLS secret detection and handling to accept Opaque secrets, matching issue #2518's compatibility fix.
Out of Scope Changes check	✅ Passed	The diff stays focused on TLS secret detection, handling, and tests, with no clear unrelated changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: accepting Opaque secrets as TLS credentials for backward compatibility.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

internal/kube/secrets/manager.go (1)

75-76: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Consider adding direct test coverage for the Opaque-secret dispatch path here.

sync.go got TestSyncHandlerOpaqueTlsSecret verifying the Opaque-secret branch end-to-end, but no equivalent test is included for handleSecret/TlsCredentialSecretPresent in this file. Since both files independently branch on IsTlsCredentialSecret, a regression in one wouldn't be caught by the other's tests.

Also applies to: 252-252

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c320e23-6097-411c-9153-a49cae40d1d7

📥 Commits

Reviewing files that changed from the base of the PR and between 172317c and 72dff74.

📒 Files selected for processing (5)

• internal/kube/secrets/context.go
• internal/kube/secrets/context_test.go
• internal/kube/secrets/manager.go
• internal/kube/secrets/sync.go
• internal/kube/secrets/sync_test.go

[c-kruse]

This last assertion would break at least one (probably untested) thing. Until this regression and the subsequent changes to tls credentials dependencies the controller was designed to mostly turn a blind eye to tlsCredentials secret contents. It mostly tried to sort the contents out in the router/kube-adaptor.

It's probably more work than just this to iron out all of the corner cases, but to tell whether or not a secret is suitable to be used with an sslProfile configuration we need more context. Example: a Connector with spec.useClientCert=false (default) only configures a sslProfile with a CA - no cert or key file.

All that to say - let's either properly solve for this with a path with concrete "reasons" a secret is unacceptable for a particular tlsCredential or return to ye olden days with something wide open like 'secret.Type == "" || opaque || tls'

[c-kruse]

Not to complicate this more, but just ran into another edge case we've never handled well: Listeners and MultiKeyListeners with requireClientCert=false have no real purpose for a CA certificate. We currently configure the sslProfile with one unconditionally and the router crashes when it is empty/absent. Looks like the kubernetes.io/tls type only requires tls.crt and tls.key (not ca.crt.)

Maybe the least controversial, most backwards compatible IsTlsCredentialSecret would be something like this? Would really count on your judgement here: A cryptic "Secret not found" error message is a big improvement over a crashing router deployment, but a major downgrade from a working link/service generated by regular skupper tooling.

func IsTlsCredentialSecret(secret *corev1.Secret) bool {
	if secret == nil || secret.Data == nil || secret.Type == corev1.SecretTypeBasicAuth {
		return false
	}
	return len(secret.Data["ca.crt"]) > 0
}