Display crosslinks from CR additional printercolumns to secrets

[gberche-orange]

Secrets are heavily used in k8s resources including CR. Being able to quicly navigate from a resource (including CRs) to a secret is important.

As an headlamp user, in order to easily inspect secrets referenced in k8s CRs, I need hyperlinks to the secret page to be added in

• the page c/<ns</crds/<crd-name> in the objects table when the secret is referenced as an additional printer column ("test-remote-k8s-secret" in screenshot below)
  
• the page c/<ns</customresources/<crd-name>/<cr-name> in the objects table when the secret is referenced as an additional printer column ("test-remote-k8s-secret" in screenshot below)
  

Identifying that an additional printed column field describes a secret can not be systematic (see backlground below)

A first approach is to apply a simple heuristic: if the printer column name contains the "secret" keyword, then display an hyperlink to the secret page in the same namespace.

A 2nd more robust solution could be to provide ability to configure patterns that should trigger then an additional printer column should be displayed asa secret.

General Background on secret references

Outside of fields highlighted as additional printer colums, references to secrets are common in K8s CR resources. However, headlamp does not yet display the CR outside of the plain yaml or the web form in #2087 This section could potentially be useful in the future to extend crosslinks to fields beyond those highlighted in additional printer columns

Some examples of such references from CR to secrets

• https://external-secrets.io/latest/api/externalsecret/
• https://docs.crossplane.io/latest/concepts/connection-details/#secret-objects

  Crossplane saves the resource secret objects in the location defined by the resource’s writeConnectionSecretToRef
  If a Claim uses a secret, it’s stored in the same namespace as the Claim with the name defined in the Claim’s writeConnectionSecretToRef.

• https://fluxcd.io/flux/components/source/gitrepositories/#secret-reference

  .spec.secretRef.name is an optional field to specify a name reference to a Secret in the same namespace as the GitRepository

• https://github.com/servicebinding/spec?tab=readme-ov-file#direct-secret-reference

  A ServiceBinding SHOULD reflect the secret projected into the workload as .status.binding.name

Examples:

status:
  binding:
    name: prod-account-service-reference
  conditions:
  - type: Ready
    status: 'True'
    reason: 'Projected'
    message: ''
    lastTransitionTime: '2021-01-20T17:00:00Z'

There are no consistently applied naming conventions that enable identifying that a field within a k8s resource correspond to a secret. Some CR choose to make explicit the actual link within the status. Some CRs rather use the spec to describe the expected secret source, or a secret that should be generated as an outcome of the CR.

The api naming conventions can provide heuristics for common cases of detecting Objects fields as secrets such as the following examples

secretRef:
    name: foo
    # namespace would generally not be needed and is discouraged,
    # as explained above.
    namespace: foo-namespace

Co authored with @Guilamb

[illume]

So... where is this up to?

We have the PR which is in draft mode still (There is an open question on if this PR #2482 approach could be wrong for some CRs)

• frontend: Render links for CR's columns that point to k8s resources #2482