Enable Server Side Authentication when using the Kubernetes Proxy

[RubenV-dev]

Hey, I just made a Pull Request!

Current State:

The Kubernetes Proxy requires authentication headers as part of its request in order to display k8s resource information.
The KubernetesAuthTranslatorGenerator class uses a static class method to instantiate a variety of different auth translators depending on the authProvider that is provided.

Suggested Change:

Move the dependency of kubernetesAuthTranslator creation to the plugin that requires it and provide it via a translatorMap parameter to the KubernetesAuthTranslatorGenerator
Provide Backstages Integrator access to k8s operations by default without the need to negotiate k8s tokens client-side. This will allow users to consume plugins with complex k8s logic without having kubectl access themselves.

With these suggested changes a user can create a kind cluster to test. Provision a high powered service account token.

and use:

curl -H 'X-Kubernetes-Cluster: kind-cluster' localhost:7007/api/kubernetes/proxy/api/v1/namespaces

to see all the namespaces on that kind cluster without the need of supplying authentication headers.

✔️ 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)
• All your commits have a Signed-off-by line in the message. (more info)

[backstage-goalie]

Changed Packages

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

[github-actions]

Uffizzi Ephemeral Environment Deploying

☁️ https://app.uffizzi.com/github.com/backstage/backstage/pull/16649

⚙️ Updating now by workflow run 4558169106.

What is Uffizzi? Learn more!

[jamieklassen]

A neat improvement here that might be nice to declare in a changeset is that KubernetesBuilder now has a method (currently named setAuthTranslatorMap) which allows integrators to bring their own KubernetesAuthTranslators without forking this plugin.

Furthermore, can we maybe rename KubernetesAuthTranslatorGenerator? Since it's no longer a factory function, it's not really "generating" anything -- rather it's dispatching calls to its decorateClusterDetailsWithAuth method to particular translators based on their name. Maybe DispatchingKubernetesAuthTranslator, DelegatingKubernetesAuthTranslator, or maybe even just the plural KubernetesAuthTranslators in keeping with the plural KubernetesAuthProviders in the frontend?

[benjdlambert]

@mclarke47 do you wanna take a look at this? 🙏

[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!

[RubenV-dev]

@benjdlambert @mclarke47 removing stale label?

[benjdlambert]

Looking pretty good to me, just one thing to fix.

I wonder if any of these docs need updating https://github.com/backstage/backstage/blob/36e81329174addc261646bae19eeead8d5a0fd93/docs/features/kubernetes/proxy.md also?

[jamieklassen]

While we're here, it does seem like a good idea to remove this disclaimer in the docs:

backstage/docs/features/kubernetes/proxy.md

Lines 65 to 71 in aefc5a2

	Until some security and permission decisions are made (see [this
	conversation](https://github.com/backstage/backstage/pull/13026/files#r1029376939)
	for context), contributors consuming the proxy endpoint in their plugin code are
	responsible for negotiating their own bearer token out-of-band. This requires
	knowing some auth details about the cluster being contacted -- in practice, only
	clusters with [client side auth
	providers](https://backstage.io/docs/features/kubernetes/authentication#client-side-providers) can reasonably be reached.

And maybe add some discussion of KubernetesAuthTranslator in the 'How it works' section:

backstage/docs/features/kubernetes/proxy.md

Lines 49 to 61 in aefc5a2

	## How it works
	The proxy will interpret the
	[`X-Kubernetes-Cluster`
	header](https://backstage.io/docs/reference/plugin-kubernetes-backend.header_kubernetes_cluster)
	as the name of the cluster to target. This name will be compared to each cluster
	returned by all the configured [cluster
	locators](https://backstage.io/docs/features/kubernetes/configuration#clusterlocatormethods)
	-- the first cluster whose [`name` field](https://backstage.io/docs/features/kubernetes/configuration#clustersname) matches
	the value in the header will be targeted.
	Then the request will be forwarded verbatim (but with the endpoint's base URL
	prefix stripped) to the cluster.

[RubenV-dev]

I added a small section under 'How it works' to explain that each request is now decorated with auth by default in this current state. Also removed disclaimer under the 'Authentication section'.

[RubenV-dev]

@benjdlambert just wanted to check in to see if there were any other changes you wanted me to address?

[benjdlambert]

Thanks! Seems like @backstage/kubernetes-maintainers are happy so gonna merge this and get it in the -next release today! 🙏

[github-actions]

Thank you for contributing to Backstage! The changes in this pull request will be part of the 1.13.0 release, scheduled for Tue, 18 Apr 2023.