diff --git a/docs/features/kubernetes/authentication.md b/docs/features/kubernetes/authentication.md index e0cddefbcf..beec5d2950 100644 --- a/docs/features/kubernetes/authentication.md +++ b/docs/features/kubernetes/authentication.md @@ -4,23 +4,26 @@ title: Kubernetes Authentication description: Authentication in Kubernetes plugin --- -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. +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-react/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. +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. +The providers currently available are summarized below: ## 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. +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: +The server side providers are: - `aws` - `azure` @@ -30,11 +33,19 @@ The providers available as server side are: ### AWS -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)][3] to authenticate to the target Account(s), you can read more about it on the page for the [Integration AWS node][4]. +For AWS, in addition to Kubernetes configuration, you will have to set up +AWS authentication. The AWS server-side authentication provider uses [AWS +Identity and Access Management (IAM)][3] to authenticate to the target +Account(s); you can read more about it on the page for the [Integration AWS +node][4]. -Using the plugin, you can authenticate to several AWS accounts using either [static AWS Access keys][5] or short-lived Access keys generated by [assuming a role][6], for either case you will need to install the [AWS CLI utility][7] and set it up following the steps in the linked documentation. +Using the plugin, you can authenticate to several AWS accounts using either +[static AWS Access keys][5] or short-lived Access keys generated by [assuming a +role][6], for either case you will need to install the [AWS CLI utility][7] 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: +If you have generated static AWS security credentials, the configuration block +for AWS will look like this: ```yaml aws: @@ -47,7 +58,8 @@ aws: accountDefaults: ``` -If your environment is set up to assume a role, the configuration would instead look like this: +If your environment is set up to assume a role, the configuration would instead +look like this: ```yaml aws: @@ -58,7 +70,8 @@ aws: accountDefaults: ``` -Either of these sections needs to be present for the Kubernetes configuration to use the `aws` `authProvider`. The Kubernetes configuration looks like this: +Either of these sections needs to be present for the Kubernetes configuration to +use the `aws` `authProvider`. The Kubernetes configuration looks like this: ```yaml kubernetes: @@ -77,14 +90,17 @@ You get both, the cluster `url` and `caData` directly from the AWS console by go ### Azure -The Azure server side authentication provider works by authenticating on the server with -the Azure CLI, please note that [Microsoft Entra authentication][1] is a requirement and has to +The Azure provider works by authenticating on the server with the Azure CLI, +please note that [Microsoft Entra authentication][1] is a requirement and has to be enabled in your AKS cluster, then follow these steps: -- [Install the Azure CLI][2] in the environment where the backstage application will run. -- Login with your Azure/Microsoft account with `az login` in the server's terminal. -- Go to your AKS cluster's resource page in Azure Console and follow the steps in the - `Connect` tab to set the subscription and get your credentials for `kubectl` integration. +- [Install the Azure CLI][2] in the environment where the backstage application + will run. +- Login with your Azure/Microsoft account with `az login` in the server's + terminal. +- Go to your AKS cluster's resource page in Azure Console and follow the steps + in the `Connect` tab to set the subscription and get your credentials for + `kubectl` integration. - Configure your cluster to use the `azure` auth provider like this: ```yaml @@ -98,18 +114,19 @@ kubernetes: skipTLSVerify: true ``` -To get the API server address for your Azure cluster, go to the Azure console page for the -cluster resource, go to `Overview` > `Properties` tab > `Networking` section and copy paste -the API server address directly in that `url` field. +To get the API server address for your Azure cluster, go to the Azure console +page for the cluster resource, go to `Overview` > `Properties` tab > +`Networking` section and copy paste the API server address directly in that +`url` field. ## 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 `clusterLocatorMethods`, -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 -as `401` or similar. +These providers authenticate a _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 Backstage is configured to +communicate with a cluster but the user isn't authorized to access it, they will +see the cluster listed but will not see any resources in the plugin page for +that cluster. The error will show as `401` or similar. The providers available as client side are: