Kubernetes 인증
Kubernetes의 인증 과정은 KubernetesAuthProviders에 의존해요. 이것은 애플리케이션의 인증 프로바이더와 같지 않아요. 기본 프로바이더는 plugins/kubernetes-react/src/kubernetes-auth-provider/KubernetesAuthProviders.ts에 정의되어 있으며, 필요하다면 거기에 사용자 지정 프로바이더를 추가할 수 있어요.
출처: 문서
본문
Kubernetes의 인증 과정은 KubernetesAuthProviders에 의존해요. 이것은 애플리케이션의 인증 프로바이더와 같지 않아요. 기본 프로바이더는 plugins/kubernetes-react/src/kubernetes-auth-provider/KubernetesAuthProviders.ts에 정의되어 있으며, 필요하다면 거기에 사용자 지정 프로바이더를 추가할 수 있어요.
이 프로바이더들은 Kubernetes 플러그인이 여러분이 접근할 수 있는 클러스터를 찾고 접근할 수 있도록 구성돼요. 그중 일부는 Microsoft Entra ID(구 Azure Active Directory) 구독이나 클러스터에서 활성화된 Azure RBAC 지원처럼 해당 제3자에 대한 특별한 요구 사항이 있어요.
현재 사용 가능한 프로바이더는 아래에 요약되어 있어요.
서버 측 프로바이더(Server Side Providers)
이 프로바이더들은 애플리케이션을 클러스터와 함께 인증하며, 즉 Backstage 앱에 로그인한 사람이라면 누구나(게스트 사용자 포함) Kubernetes 객체에 같은 접근 권한을 부여받는다는 뜻이에요.
서버 측 프로바이더는 다음과 같아요.
awsazuregoogleServiceAccountlocalKubectlProxyserviceAccount
AWS
AWS의 경우 Kubernetes 구성 외에도 AWS 인증을 설정해야 해요. AWS 서버 측 인증 프로바이더는 AWS Identity and Access Management(IAM)를 사용해 대상 Account(s)에 인증해요. Integration AWS 노드 페이지에서 더 자세히 읽을 수 있어요.
이 플러그인을 사용하면 정적 AWS Access 키, 역할을 assume해 생성한 단기 Access 키, 또는 OIDC 페더레이션(예: GCP Workload Identity Federation)을 사용하는 환경을 위한 웹 ID 토큰 파일을 사용해 여러 AWS 계정에 인증할 수 있어요. 정적 키나 역할 assume의 경우 AWS CLI 유틸리티를 설치하고 연결된 문서의 단계를 따라 설정해야 해요.
정적 AWS 보안 자격 증명을 생성했다면 AWS 구성 블록은 다음과 같을 거예요.
aws:
mainAccount:
accounts:
- accountId: '<account-number>'
accessKeyId: ${AWS_ACCESS_KEY_ID}
secretAccessKey: ${AWS_SECRET_ACCESS_KEY}
region: <region>
accountDefaults:
환경이 역할을 assume하도록 설정되어 있다면 구성은 대신 다음과 같을 거예요.
aws:
mainAccount:
roleName: <name-of-the-role-to-assume>
region: <region>
accounts:
accountDefaults:
비-AWS 환경에서 Backstage를 실행하고 OIDC 페더레이션(예: GCP Workload Identity Federation)을 사용한다면 웹 ID 토큰 파일을 사용할 수 있어요. 이것을 모든 계정에 적용하려면 accountDefaults로 구성하거나, 특정 계정에는 개별 accounts 항목을 사용하세요.
aws:
accountDefaults:
roleName: <name-of-the-role-to-assume>
webIdentityTokenFile: <path-to-token-file>
또는 특정 계정의 경우:
aws:
accounts:
- accountId: '<account-number>'
roleName: <name-of-the-role-to-assume>
webIdentityTokenFile: <path-to-token-file>
kubernetes.io/aws-assume-role이 설정되면 역할 ARN의 계정 ID를 사용해 일치하는 accounts 또는 accountDefaults 구성을 찾아요. 찾으면 그 자격 증명이 주석에 지정된 역할을 assume하기 위한 소스 자격 증명으로 사용돼요.
Kubernetes 구성이 aws authProvider를 사용하려면 이 두 섹션 중 하나가 존재해야 해요. Kubernetes 구성은 다음과 같아요.
kubernetes:
serviceLocatorMethod:
type: 'multiTenant'
clusterLocatorMethods:
- type: 'config'
clusters:
- url: https://<unique-identifier>.<region>.eks.amazonaws.com
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}
클러스터 URL과 CA는 모두 AWS 콘솔에서 EKS > Your cluster > Overview > Details로 가서 얻을 수 있어요. 각각 'API server endpoint'와 'Certificate authority' 아래에서 찾을 수 있어요.
Backstage가 EKS 클러스터로 인증할 때 역할을 assume해야 한다면 kubernetes.io/aws-assume-role 매개변수를 원하는 역할의 ARN으로 설정할 수 있어요. 구성의 kubernetes.io/aws-external-id 매개변수는 STS의 AssumeRole API의 ExternalId 매개변수에 해당해요.
Azure
Azure 프로바이더는 Azure CLI로 서버에서 인증하여 작동해요. Microsoft Entra 인증이 요구 사항이며 AKS 클러스터에서 활성화되어 있어야 한다는 점에 유의하세요. 그런 다음 다음 단계를 따르세요.
- backstage 애플리케이션이 실행될 환경에 Azure CLI 설치.
- 서버의 터미널에서
az login으로 Azure/Microsoft 계정으로 로그인. - Azure 콘솔의 AKS 클러스터 리소스 페이지로 이동해
Connect탭의 단계를 따라kubectl통합을 위한 구독을 설정하고 자격 증명을 얻기. - 클러스터를
azure인증 프로바이더를 사용하도록 이렇게 구성:
kubernetes:
clusterLocatorMethods:
- type: 'config'
clusters:
- name: My AKS cluster
url: ${AZURE_CLUSTER_API_SERVER_ADDRESS}
authProvider: azure
skipTLSVerify: true
Azure 클러스터의 API 서버 주소를 얻으려면 Azure 콘솔의 클러스터 리소스 페이지로 가서 Overview > Properties 탭 > Networking 섹션으로 이동해 API 서버 주소를 복사해 그 url 필드에 직접 붙여넣으세요.
클라이언트 측 프로바이더(Client Side Providers)
이 프로바이더들은 사용자를 클러스터와 함께 인증해요. 각 Backstage 사용자는 자격 증명을 요구받으며, 사용자가 해당 클러스터에 접근하도록 권한이 부여된 한 클러스터에 접근할 수 있어요. Backstage가 클러스터와 통신하도록 구성되었지만 사용자가 그 클러스터에 접근할 권한이 없다면, 사용자는 클러스터가 목록에 표시되는 것을 보지만 해당 클러스터의 플러그인 페이지에서 리소스는 보지 못해요. 오류는 401 또는 그와 비슷하게 표시될 거예요.
클라이언트 측으로 사용 가능한 프로바이더는 다음과 같아요.
aksgoogleoidc