Support passing credentials to Composition Functions

[negz]

What problem are you facing?

When reviewing the Composition Functions design @turkenh pointed out that we don't currently have a secure way for a Composition Function to authenticate to an external system. We don't expect Composition Functions to orchestrate external systems directly - we expect them to produce composed resources for Crossplane to orchestrate. We do however expect that Composition Functions might need to query external systems in order to determine what Crossplane should do.

It's currently possible to specify an arbitrary config object for a function. This object will be copied verbatim to the config object of FunctionIO. This is not appropriate for passing credentials because the Composition is available as plaintext to any one with RBAC access to view them.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: example
spec:
  compositeTypeRef:
    apiVersion: database.example.org/v1alpha1
    kind: XPostgreSQLInstance
  functions:
  - name: my-cool-Function
    type: Container
    container:
      image: xkpg.io/my-cool-Function:0.1.0
    config:
      apiVersion: database.example.org/v1alpha1
      kind: Config
      metadata:
        name: cloudsql
      spec:
        version: POSTGRES_9_6

I can't think of any other good alternatives, either.

• It's not a good idea to bake your credentials into your function's OCI image, especially because we don't yet support private OCI images per Implement imagePullSecrets for Composition Functions #3717.
• Composition Functions aren't run as Pods, so there's no way to inject credentials e.g. via a volume or environment variable.

How could Crossplane help solve your problem?

We should make it possible to securely specify credentials. One option might be to support loading the entire config object from a (more) secure source such as a Kubernetes secret or a Secret Store (#3670). Something like:

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: example
spec:
  compositeTypeRef:
    apiVersion: database.example.org/v1alpha1
    kind: XPostgreSQLInstance
  functions:
  - name: my-cool-Function
    type: Container
    container:
      image: xkpg.io/my-cool-Function:0.1.0
    config:
      source: Secret
      secretRef:
        namespace: crossplane-system
        name: my-cool-config

[negz]

CC @turkenh and @ezgidemirel. I feel like this is related to the broader question of how we would read secrets from a secret store (e.g. to use those secrets to set a database password or similar).

[negz]

I put this into the v1.12 milestone but now I'm thinking there's too much of a dependency on secret stores, and I'm reluctant to target both for v1.12. I'd be happy to re-add this if secret stores is trending to move out of alpha.

[blakebarnett]

FWIW I think it'd be totally fine to only support reading from k8s Secrets, given that things like https://external-secrets.io exist and it's probably not in scope to support writing to external secrets stores right?

[negz]

I think the updated design (#4306) gives us some more flexibility here. For example if we also move forward with something like the Package Runtime Config proposal (#4322) it will be possible to inject credentials into a Function by adding files or env vars to its container. That might not be the ideal UX, but it will at least make referencing credentials possible.