feat: use vals for secret decryption

[rajiteh]

Refers to #2407

Introduces the ability for the fleet.yaml to specify vals secret strings, which then will be decrypted at bundle processing time by the fleet operator.

Fleet operator deployment is responsible for configuring the appropriate environment variables for vals to decrypt secrets using the correct backend.

See #2407 for more context.

[weyfonk]

Thank you for this contribution :)
Leaving a couple of comments. One of our main concerns here is having all Helm values sent to an external library, perhaps we could filter values to only pre-process those bearing the known vals pattern.
We are currently assessing possible security implications of this feature.

[weyfonk]

Should all Helm values be forwarded to vals? Or would we rather want to filter values based on a known pattern (eg. ref+<provider>://) and send only those to the library?

[weyfonk]

nit: this would also work:

Suggested change

	t.Fatalf("key %s was not the expected value. Expected: '%s' Actual: '%s'", testCase.Key, field, testCase.ExpectedValue)
	t.Fatalf("key %s does not have the expected value. Expected: %q Actual: %q", testCase.Key, field, testCase.ExpectedValue)

[manno]

I think I would prefer an approach similiar to how nginx handles env vars from secrets:

## @param extraEnvVarsSecret Secret with extra environment variables
##
extraEnvVarsSecret: ""

However, the secret would have to be created manually in this case. Which is not as automatic/user friendly?

Additionally we're adding extraEnvs, like Rancher, to allow users to specify non-secret env vars as helm values.

[rajiteh]

@weyfonk I think you raise a valid concern. I could imagine we introduce a new gotpl helper that wraps the secret ref as an argument?

${ decodeSecretRef "ref+foo://my/secret" }

[weyfonk]

We have discussed this approach and will not be merging this in Fleet, because storing confidential values in etcd by means of custom resources (bundles in this case) is not secure by default.

An alternative to this could be using Kubernetes secrets, as @manno noted here.

[weyfonk]

@rajiteh Please feel free to reopen this PR to further discuss this.

[manno]

An alternative to this could be using Kubernetes secrets, as @manno noted here.

That's the first part, to have the credentials used to access the vals provider in a secret, which the original PR did. Second part is to keep the response from vals out of the bundledeployment options and in a secret instead. We want to avoid storing sensitive material in our CRDs. secrets.
Doing so would make it more difficult to harden the cluster. E.g. https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ would need to include bundledeployments.fleet.cattle.io. However, the RKE2 guide only encrypts secrets.

We are still discussing a possible solution in #2375. That involves creating a secret in the bundledeployment's namespace (see "cluster namespace" in docs) and allowing the downstream agent to fetch it:

When targeting, it also clones the secret containing all the OCI values, just changing the namespace to match the bundledeployment's namespace. (This way the agents will be able to obtain the OCI values) It will also flag the bundledeployment to state that the content is stored in the OCI registry instead to a content resource.

We could do the same for sensitive helm values?