The authentication process in Kubernetes relies on
KubernetesAuthProviders, which are
not the same as the application's auth providers, the default providers are defined in
plugins/kubernetes/src/kubernetes-auth-provider/KubernetesAuthProviders.ts, you can
add custom providers there if needed.
These providers are configured so your Kubernetes plugin can locate and access the clusters you have access to, some of them have special requirements in the third party in question, like Microsoft Entra ID (formerly Azure Active Directory) subscription or Azure RBAC support active on the cluster.
The providers currently available are divided into server side and client side.
Server Side Providers
These providers authenticate your application with the cluster, meaning anyone that is logged in into your backstage app will be granted the same access to Kubernetes objects, including guest users.
The providers available as server side are:
For AWS, in addition to the "kubernetes" configuration, you will have to set up AWS authentication. The AWS server-side authentication provider uses AWS Identity and Access Management (IAM) to authenticate to the target Account(s), you can read more about it on the page for the Integration AWS node.
Using the plugin, you can authenticate to several AWS accounts using either static AWS Access keys or short-lived Access keys generated by assuming a role, for either case you will need to install the AWS CLI utility and set it up following the steps in the linked documentation.
If you have generated static AWS security credentials, the configuration block for AWS will look like this:
- accountId: '<account-number>'
If your environment is set up to assume a role, the configuration would instead look like this:
Either of these sections needs to be present for the Kubernetes configuration to use the
authProvider. The Kubernetes configuration looks like this:
- type: 'config'
- url: https://<unique-identifier>.<region>.eks.amazonaws.com
You get both, the cluster
caData directly from the AWS console by going to
Your cluster >
Details. You will find them under 'API server endpoint' and 'Certificate authority' respectively.
The Azure server side authentication provider works by authenticating on the server with the Azure CLI, please note that Microsoft Entra authentication is a requirement and has to be enabled in your AKS cluster, then follow these steps:
- Install the Azure CLI in the environment where the backstage application will run.
- Login with your Azure/Microsoft account with
az loginin the server's terminal.
- Go to your AKS cluster's resource page in Azure Console and follow the steps in the
Connecttab to set the subscription and get your credentials for
- Configure your cluster to use the
azureauth provider like this:
- type: 'config'
- name: My AKS cluster
To get the API server address for your Azure cluster, go to the Azure console page for the
cluster resource, go to
Properties tab >
Networking section and copy paste
the API server address directly in that
Client Side Providers
These providers authenticate your user with the cluster. Each Backstage user will be
prompted for credentials and will have access to the clusters as long as the user has been
authorized to access said cluster. If the cluster is listed in the
but the user hasn't been authorized to access, the user will see the cluster listed but
will not see any resources in the plugin page for that cluster, and the error will show
401 or similar.
The providers available as client side are: