[kubernetes-backend] support caFile on clusters defined in app-config

[jamieklassen]

Hey, I just made a Pull Request!

Resolves #13768

I tested this out locally using the following steps:

1. I created a kind cluster with kind create cluster
2. I wrote out the CA for that cluster to a local file with

   kubectl config view --raw -o jsonpath='{.clusters[?(@.name == "kind-kind")].cluster.certificate-authority-data}' | base64 -d > kind.pem

3. I ran kubectl apply -f backstage.yml where backstage.yml is:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: backstage
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: backstage
     template:
       metadata:
         labels:
           app: backstage
       spec:
         containers:
         - image: nginx
           imagePullPolicy: Always
           name: nginx

4. I created kubernetes.yaml in the root of this repo:

   apiVersion: backstage.io/v1alpha1
   kind: Component
   metadata:
     name: demo-backstage
     annotations:
       'backstage.io/kubernetes-label-selector': 'app=backstage'
   spec:
     type: service
     lifecycle: stable
     owner: user:guest

5. I have app-config.local.yaml:

   kubernetes:
     clusterLocatorMethods:
       - type: config
         clusters:
           - url: https://127.0.0.1:<port of kind apiserver>
             name: kind
             authProvider: serviceAccount
             serviceAccountToken: <token for SA with the role at https://backstage.io/docs/features/kubernetes/configuration#role-based-access-control>
             caFile: ../../kind.pem
   catalog:
     locations:
       - type: file
         target: ../../kubernetes.yaml

6. I run yarn start-backend
7. In another terminal, I run

   curl localhost:7007/api/kubernetes/services/demo-backstage \
     -H 'content-type: application/json' \
     -d '{"entity":{"metadata":{"annotations":{"backstage.io/kubernetes-label-selector":"app=backstage"}}}}'

   And objects are successfully returned!

Before this change, the same sequence of steps would result in

{
  "error": "unable to verify the first certificate"
}

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes) backend only
• All your commits have a Signed-off-by line in the message. (more info)

[github-actions]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@backstage/plugin-kubernetes-backend	plugins/kubernetes-backend	patch	v0.8.1-next.1

[jamieklassen]

@jpeach interested to know if this satisfies your intended use case -- if so, is it clear enough how to do so (e.g. mounting k8s secrets into the pod where Backstage is running, pointing to those mount points in the app-config appropriately)? Do you think there should be any further docs or contrib/ examples?

@mclarke47 I only have the config clusterLocator reading this property -- somehow this feels like more of a "static config"-type feature and it seemed weird for entities in the catalog to contain references to filesystem paths on the Backstage host. It wouldn't be hard to add this to the catalog clusterLocator too though.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

[freben]

Thanks!

[freben]

Maybe didn't have to make the path as such be a secret? 🤔 But I'm fine either way, not sure that it's anybody's business to see this outside of the backend code that actually needs it

[jamieklassen]

I actually don't really understand how these comments work and was following my nose LOL. Is there a value for "only the backend needs it but it's not necessarily secret"?

[github-actions]

Thank you for contributing to Backstage! The changes in this pull request will be part of the 1.9.0 release, scheduled for Tue, 20 Dec 2022.

[jhested]

I will just allow myself to make a little comment here, as I was struggling for days to get the plugin to use the correct certificate.

It turned out that the environment variable 'GLOBAL_AGENT_FORCE_GLOBAL_AGENT' defaults to true which resulted in the certificate never being used, because the global-agent was used instead.

Everything worked after setting GLOBAL_AGENT_FORCE_GLOBAL_AGENT to false