Resolve KEDA GCP credential Secret references from the provider schema

[nadaverell]

KEDA GCP Secret Manager credentials are nested under credentials.clientSecret.valueFrom.secretKeyRef. Radar's audit adapter and authentication drawer read a shallow field that does not exist in the provider contract, so they miss the credential Secret. Read the actual nested name/key and link namespaced TriggerAuthentication credentials to the correct Secret.

ClusterTriggerAuthentication credential names remain visible as plain text: its operator credential namespace is not available in this drawer. Apply that same scope rule to its direct Secret references rather than navigating to a fictional cluster-scoped Secret. Resolving the operator namespace is a separate change. No Secret values, key existence, cloud authentication, graph edges or Diagnose expansion are claimed.

Scope: existing supported KEDA config-reference extraction for the unused-ConfigMap/Secret audit, plus shared authentication drawers and package consumers after normal updates. This corrects an existing relationship rather than adding a new generic reference parser. The KEDA v2.21 GCP provider contract is the source of the field path.

Validation: complete internal audit suite and three drawer interaction/schema cases pass; type check, production frontend/embed/backend build and full root make test pass. Actual isolated-kind browser navigation reaches the correct namespaced empty Secret. A live MCP audit counterfactual flags that Secret as unused after removing only the nested credential reference, then clears the finding when the reference is restored. The fixture has no credential values or KEDA controller, and does not prove cloud authentication. The settled capture was inspected.

---

Note

Low Risk
Corrects config-reference paths and UI linking for KEDA auth resources; no changes to authentication, secret values, or cluster credential namespace resolution.

Overview
Aligns KEDA GCP Secret Manager credential tracking with the provider schema: both the audit TriggerAuthentication config-ref extractor and KedaTriggerAuthRenderer now read credentials.clientSecret.valueFrom.secretKeyRef (name/key) instead of a non-existent shallow clientSecret.name, so unused-Secret audit and the drawer surface the real credential Secret.

The drawer links namespaced credential and secretTargetRef Secrets via ResourceLink; without a resource namespace (e.g. ClusterTriggerAuthentication), those names stay plain text so navigation does not target invented cluster-scoped Secrets. A regression test ensures the old shallow GCP shape is ignored.

^{Reviewed by Cursor Bugbot for commit 88d0855. Bugbot is set up for automated code reviews on this repo. Configure here.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Resolve KEDA GCP credential Secret references from the provider schema

🐞 Bug fix 🧪 Tests 🕐 10-20 Minutes

AI Description

• Read KEDA GCP credential Secret references from the provider-defined nested field instead of a
 nonexistent shallow field.
• Link namespaced credentials in authentication drawers; show cluster-authentication references as
 plain text when their namespace is unknown.
• Test nested references, navigation, and rejection of the shallow shape.

Diagram

graph TD
  A["KEDA Authentication"] --> B["Nested Credential Ref"] --> C["Audit Extractor"] --> D["Unused Secret Audit"]
  B --> E["Authentication Drawer"] --> F{"Namespace known?"} -->|Yes| G["Secret Navigation"]
  F -->|No| H["Plain Text"]

Loading

High-Level Assessment

Keep the targeted correction in the existing audit extractor and drawer. A generic reference parser or cross-language shared schema would add complexity for one known provider field; resolving the operator namespace for cluster-scoped authentications remains a separate concern.

Files changed (4) +104 / -5

Bug fix (2) +7 / -4

crd_config_refs.goExtract the provider-defined GCP credential Secret name +1/-1

Extract the provider-defined GCP credential Secret name

• Changes KEDA TriggerAuthentication extraction to read the Secret name from clientSecret.valueFrom.secretKeyRef. This lets the existing unused-Secret audit recognize the namespaced credential reference.

internal/audit/crd_config_refs.go

KedaTriggerAuthRenderer.tsxDisplay nested GCP credentials with namespace-safe links +6/-3

Display nested GCP credentials with namespace-safe links

• Reads the provider-defined credential Secret name and key, linking the Secret only when the authentication resource supplies a namespace. Applies the same namespace rule to direct Secret references, leaving cluster-authentication names as plain text.

packages/k8s-ui/src/components/resources/renderers/KedaTriggerAuthRenderer.tsx

Tests (2) +97 / -1

crd_config_refs_test.goCover nested credentials and reject shallow references +8/-1

Cover nested credentials and reject shallow references

• Updates the KEDA fixture to include a nested Secret name and key. Adds a case confirming that the previously assumed shallow name produces no reference.

internal/audit/crd_config_refs_test.go

KedaCredentials.test.tsxTest credential navigation and cluster-authentication display +89/-0

Test credential navigation and cluster-authentication display

• Tests navigation to a namespaced GCP credential Secret and display of its key. Also verifies that cluster-authentication Secret names remain unlinked and that the shallow GCP field is ignored.

packages/k8s-ui/src/components/resources/renderers/KedaCredentials.test.tsx

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗