Invalid Registry in Credentials

[markphillips100]

What happened?

KCLInput credentials with a url, username and password fail in v0.12.2 with "Invalid registry ". This worked for v0.12.1 and all versions below to v0.11.2 (the last version I've been using for over a year now).

I was attempting to test out new OCI cache behaviour introduced in v0.12.3 (#282) but the function failed to load my usual OCIs. No other environment changes. So I iterated a version of function-kcl from v0.11.2 upwards until this failure occurs, and it hits at v0.12.2.

How can we reproduce it?

Use v0.12.2 or the latest v0.12.3 and attempt to source from an oci url to Azure Container Registry using a username/password with registry pull permissions:

Relevant part of composition:

  - functionRef:
      name: kcl-function
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLInput
      metadata:
        name: basic
      spec:
        credentials:
          password: <password>
          url: https://<acrname>.azurecr.io
          username: <username>
        source: oci://<acrname>.azurecr.io/<imagename>?tag=<some-tag>

What environment did it happen in?

Function version: v0.12.2+

Kind cluster running:
Client Version: v1.29.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.35.5

[markphillips100]

A bit more investigation and it seems omitting the https:// from the url gets me past the invalid registry error. This is undocumented I believe, and I've always used the scheme in the url before.

I was also getting the "putting plaintext credentials is disabled" error which I believe is resolve by a fix in kpm. This occurs due to the forced plain http default being true and used to determine if the credential store can persist on put. This can be circumvented by setting OCI_REG_PLAIN_HTTP to off in either vscode launch config if debugging locally, or in DeploymentRuntimeConfig.

Whilst the env var gets around the cred persistence issue, the flag is still required anyway even if credentials aren't used, like say for debugging locally. This is due to oras-go v2.6.2 having an issue not sending an Authorization header on a http->https redirect. This oras-go issue explains that detail. It impacts us because of ForceOciPlainHttp default being true sets plain http true for kcl mod deps, like for ghcr.io k8s. Net result is 401 Not Authorized when fetching those v2 manifests. So I suspect even when kpm is released and updated here there will still be a problem with mod deps, and require the env var still.

So in summary, I've managed to get function-kcl v0.12.3 working by first ensuring I don't add a url scheme to credentials urls, and also ensuring I add OCI_REG_PLAIN_HTTP is off in the function's DeploymentRuntimeConfig:

apiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
  name: function-kcl-debug-config
spec:
  deploymentTemplate:
    spec:
      selector: {}
      template:
        spec:
          containers:
            - name: package-runtime
              env:
              - name: OCI_REG_PLAIN_HTTP
                value: "off"
              args:
              - --debug

For debugging this version locally where insecure urls are involved with port numbers, I raised issue #450 for that.