paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 25 Packages Projects Releases Wiki Activity

Merge pull request #22399 from jamieklassen/aws-id-authmetadata-field

Browse Source 
authMetadata field for AWS cluster ID
This commit is contained in:
Jamie Klassen
2024-01-22 13:14:55 -05:00
committed by GitHub
parent 0b1cf22e5e 8754168225
commit 8eb3fd282b
9 changed files with 162 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/features/kubernetes/authentication.md
+62 -33
View File
@@ -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:
@@ -68,23 +81,37 @@ kubernetes:
- type: 'config'
clusters:
- url: https://<unique-identifier>.<region>.eks.amazonaws.com
name: <cluster-name-to-use>
name: ${CLUSTER_NAME_TO_DISPLAY}
authProvider: 'aws'
caData: ${EKS_CA_DATA}
authMetadata:
kubernetes.io/aws-assume-role: ${ROLE_ARN_TO_ASSUME}
kubernetes.io/aws-external-id: ${ID_FROM_AWS_ADMIN}
kubernetes.io/x-k8s-aws-id: ${CLUSTER_NAME_IN_AWS_CONSOLE}
```
You get both, the cluster `url` and `caData` directly from the AWS console by going to `EKS` > `Your cluster` > `Overview` > `Details`. You will find them under 'API server endpoint' and 'Certificate authority' respectively.
You get both the cluster URL and CA directly from the AWS console by going to
`EKS` > `Your cluster` > `Overview` > `Details`. You will find them under 'API
server endpoint' and 'Certificate authority' respectively.
If Backstage needs to assume a role when authenticating with EKS clusters, the
`kubernetes.io/aws-assume-role` parameter can be set to the ARN of the desired
role. the `kubernetes.io/aws-external-id` parameter in the config corresponds to
the `ExternalId` parameter of the [`AssumeRole` API in STS][8].
### 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 +125,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:
@@ -124,3 +152,4 @@ The providers available as client side are:
[5]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
[6]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html
[7]: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
[8]: https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters