Impact

An authenticated user with Kubernetes read permissions could access Kubernetes workload data beyond their intended scope by supplying crafted entity data to the deprecated services endpoint. The exposure is limited to read-only access to Kubernetes object metadata across configured clusters.

Patches

Patched in @backstage/plugin-kubernetes-backend version 0.21.8.

Workarounds

- Disable the deprecated /services/:serviceId route by deploying a custom Kubernetes router that omits it. - Restrict access to the kubernetes.resources.read permission to limit the set of users who can reach the endpoint.

Impact

Deployments using catalog cluster discovery may be affected when catalog contributors can create or modify kubernetes-cluster Resource entities. With the required endpoint permissions and pod RBAC, the backend can use its local in-cluster identity, potentially exposing Kubernetes resources readable by that identity. The credential is used only with the local in-cluster API endpoint and is not sent to the catalog-supplied endpoint.

Patches

Patched in @backstage/plugin-kubernetes-backend version 0.21.10

Workarounds

- Do not configure service account authentication through catalog-provided clusters; use the supported static configuration method when service account authentication is required. - Restrict catalog ingestion so untrusted users cannot create or alter Kubernetes cluster Resource entities.

Impact

An authenticated user holding the standard Kubernetes resource read permission could retrieve sensitive values that the Kubernetes plugin is designed to mask, potentially exposing credentials and other confidential material held in the connected clusters. Exposure is limited to resources that the Backstage service account is permitted to read and that match the targeted catalog entity's namespace and label selector. Deployments whose cluster credentials do not grant read access to these resources are unaffected.

Patches

Fixed in @backstage/plugin-kubernetes-backend version 0.21.9

One behavior change is worth noting for adopters who expose custom resources: a custom resource whose list kind is reported by the API server as SecretList now has the values of its data field masked, matching how core Kubernetes Secrets have always been handled on other query paths.

Workarounds

- Enable the permission framework and restrict kubernetes.resources.read to trusted users. - Scope the RBAC of the service account used to reach each cluster so that it cannot read sensitive resource types. The recommended ClusterRole in the Kubernetes plugin configuration documentation does not grant this access.