Using Kargo Cluster Secret for Github Authentication

[nat-ray]

I am trying to use a Github App configured as a cluster secret and created it like this:

apiVersion: v1
kind: Secret
metadata:
  name: akuity-github-app
  namespace: kargo-cluster-secrets
  labels:
    kargo.akuity.io/cred-type: git
stringData:
  githubAppClientID: "redacted"
  githubAppPrivateKey: |
    -----BEGIN RSA PRIVATE KEY-----
    -----END RSA PRIVATE KEY-----
  githubAppInstallationID: "redacted"
  repoURL: "https://github.com/myorg/my-repo.git"
  repoURLIsRegex: "false"

kargo apply -f secret.yml is successful, and I can see the cluster secret in Kargo. My promotion task does not seem to automatically use the cluster secret. Promotion task example:

spec:
  steps:
    - config:
        checkout:
          - branch: master
            path: ./src
        repoURL: https://github.com/myorg/my-repo.git
      uses: git-clone

Error seen in Kargo: ... fatal: could not read Username for 'https://github.com': No such device or address.

If I add the project git secret, then the git-clone is successful. Is there something missing?

[csz-akuity]

@nat-ray your credentials and promotion task look fine, but I think you may need to enable the Global Namespace Settings for the kargo-cluster-secrets namespace.

[krancour]

Authentication errors from GitHub can be cryptic at times. In my experience, the error you are seeing is actually indicative of no credentials at all having been supplied, which in turn, means they were probably not found. If you were to enable debug logging, the logs would probably reflect this.

@csz-akuity's guidance is putting you on the right track, although I will add...

kargo-cluster-secrets (or whatever one's "cluster Secrets namespace" happens to be named) is not a location that is intended for you to put Secrets that you wish to "share." That namespace exists for one, extremely specific purpose: Sometimes a cluster-scoped resource must reference a Secret, and because Kubernetes lacks any such thing as a "ClusterSecret," some namespace must exist as a home for such things. That is what kargo-cluster-secrets is for. It isn't for sharing Secrets.

@csz-akuity, once again, is putting you on the right track. You do indeed configure Kargo to look in one or more specific namespaces for shared credentials by adding them to the list of "global credentials namespaces." However, since "cluster secrets namespace" and "global credentials namespaces" have distinctly different purposes, as described above, I would highly discourage the recommendation that kargo-cluster-secrets be added to the list of global credentials namespaces.

The correct thing to do is dedicate one namespace as the one for "sharable" credentials, configure Kargo to be aware of that, and then put your Secret there.

Aside: In an upcoming release, we will be removing support for multiple "global credentials namespaces" and allowing just one, so do keep that in mind as you set this up, and definitely allocate just one namespace for those sharable credentials and not multiples.