refactor kubernetes auth docs
some grammar/wordsmithing and formatting Signed-off-by: Jamie Klassen <jamie.klassen@broadcom.com>
This commit is contained in:
Jamie Klassen
@@ -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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user