19.5. 구성 요소에 대한 단기 인증 정보가 있는 수동 모드

AWS STS(Security Token Service) 및 AssumeRole API 작업을 사용하면 Pod에서 IAM 역할 정책에서 정의한 액세스 키를 검색할 수 있습니다.

OpenShift Container Platform 클러스터에는 Kubernetes 서비스 계정 서명 서비스가 포함되어 있습니다. 이 서비스는 개인 키를 사용하여 서비스 계정 JSON 웹 토큰(JWT)에 서명합니다. 서비스 계정 토큰이 필요한 Pod는 Pod 사양을 통해 하나씩 요청합니다. Pod가 생성되어 노드에 할당되면 노드는 서비스 계정 서명 서비스에서 서명된 서비스 계정을 검색하여 Pod에 마운트합니다.

STS를 사용하는 클러스터에는 Kubernetes 구성 시크릿에 IAM 역할 ID가 포함됩니다. 워크로드에서는 이 IAM 역할 ID의 ID를 가정합니다. 워크로드에 발행된 서명된 서비스 계정 토큰은 AWS의 구성과 일치하여 AWS STS가 지정된 IAM 역할의 액세스 키를 워크로드에 부여할 수 있습니다.

AWS STS는 다음 조건을 충족하는 서비스 계정 토큰이 포함된 요청에만 액세스 키를 부여합니다.

클러스터에서 사용하는 서비스 계정 서명 키의 공개 키 쌍은 AWS S3 버킷에 저장됩니다. AWS STS 페더레이션은 서비스 계정 토큰 서명이 S3 버킷에 저장된 공개 키와 일치하는지 확인합니다.

19.5.1.1.1. AWS STS의 인증 흐름

다음 다이어그램은 AWS STS를 사용할 때 AWS와 OpenShift Container Platform 클러스터 간의 인증 흐름을 보여줍니다.

• 토큰 서명 은 OpenShift Container Platform 클러스터의 Kubernetes 서비스 계정 서명 서비스입니다.
• Pod의 Kubernetes 서비스 계정 은 서명된 서비스 계정 토큰입니다.

그림 19.2. AWS 보안 토큰 서비스 인증 흐름

새로운 인증 정보 및 새로 고침 인증 정보에 대한 요청은 AWS IAM 역할과 결합된 적절하게 구성된 AWS IAM OIDC(OpenID Connect) ID 공급자를 사용하여 자동화됩니다. AWS IAM에서 신뢰하는 서비스 계정 토큰은 OpenShift Container Platform에서 서명하고 Pod에 프로젝션하고 인증에 사용할 수 있습니다.

AWS STS(보안 토큰 서비스)와 함께 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 AWS 인증 정보의 콘텐츠가 변경됩니다. 다음 보안 형식을 비교합니다.

apiVersion: v1
kind: Secret
metadata:
  namespace: <target_namespace> 1
  name: <target_secret_name> 2
data:
  aws_access_key_id: <base64_encoded_access_key_id>
  aws_secret_access_key: <base64_encoded_secret_access_key>

apiVersion: v1
kind: Secret
metadata:
  namespace: <target_namespace> 1
  name: <target_secret_name> 2
stringData:
  credentials: |-
    [default]
    sts_regional_endpoints = regional
    role_name: <operator_role_name> 3
    web_identity_token_file: <path_to_token> 4

OpenShift Container Platform 구성 요소에는 다음과 같은 권한이 필요합니다. 이러한 값은 각 구성 요소의 CredentialsRequest CR(사용자 정의 리소스)에 있습니다.

AWS 클러스터의 OLM(Operator Lifecycle Manager)에서 관리하는 특정 Operator는 STS를 사용하여 수동 모드를 사용할 수 있습니다. 이러한 Operator는 클러스터 외부에서 관리되는 제한된 권한의 단기 인증 정보로 인증합니다. Operator가 AWS STS를 통한 인증을 지원하는지 확인하려면 OperatorHub에서 Operator 설명을 참조하십시오.

새로운 인증 정보 및 새로 고침 인증 정보에 대한 요청은 IAM 서비스 계정과 결합된 적절하게 구성된 OpenID Connect(OIDC) ID 공급자를 사용하여 자동화됩니다. GCP에서 신뢰하는 서비스 계정 토큰은 OpenShift Container Platform에서 서명하고 Pod에 프로젝션하고 인증에 사용할 수 있습니다. 토큰은 1시간 후에 새로 고쳐집니다.

다음 다이어그램에서는 GCP 워크로드 ID를 사용할 때 GCP와 OpenShift Container Platform 클러스터 간의 인증 흐름을 자세히 설명합니다.

그림 19.3. GCP 워크로드 ID 인증 흐름

GCP 워크로드 ID로 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 GCP 인증 정보의 내용이 변경됩니다. 다음 시크릿 콘텐츠를 비교합니다.

apiVersion: v1
kind: Secret
metadata:
  namespace: <target_namespace> 1
  name: <target_secret_name> 2
data:
  service_account.json: <service_account> 3

{
   "type": "service_account", 1
   "project_id": "<project_id>",
   "private_key_id": "<private_key_id>",
   "private_key": "<private_key>", 2
   "client_email": "<client_email_address>",
   "client_id": "<client_id>",
   "auth_uri": "https://accounts.google.com/o/oauth2/auth",
   "token_uri": "https://oauth2.googleapis.com/token",
   "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
   "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/<client_email_address>"
}

{
   "type": "external_account", 1
   "audience": "//iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/test-pool/providers/test-provider", 2
   "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
   "token_url": "https://sts.googleapis.com/v1/token",
   "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<client_email_address>:generateAccessToken", 3
   "credential_source": {
      "file": "<path_to_token>", 4
      "format": {
         "type": "text"
      }
   }
}

GCP 클러스터의 OLM(Operator Lifecycle Manager)에서 관리하는 특정 Operator는 GCP 워크로드 ID와 함께 수동 모드를 사용할 수 있습니다. 이러한 Operator는 클러스터 외부에서 관리되는 제한된 권한의 단기 인증 정보로 인증합니다. Operator가 GCP 워크로드 ID로 인증을 지원하는지 확인하려면 OperatorHub의 Operator 설명을 참조하십시오.

Google Cloud Platform Workload Identity를 사용하는 OpenShift Container Platform 클러스터의 고객 워크로드의 애플리케이션은 GCP Workload Identity를 사용하여 인증할 수 있습니다. 애플리케이션과 함께 이 인증 방법을 사용하려면 클라우드 공급자 콘솔 및 OpenShift Container Platform 클러스터에서 구성 단계를 완료해야 합니다.

다음 다이어그램에서는 Microsoft Entra Workload ID를 사용할 때 Azure와 OpenShift Container Platform 클러스터 간의 인증 흐름을 자세히 설명합니다.

그림 19.4. 워크로드 ID 인증 흐름

Microsoft Entra Workload ID로 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 Azure 인증 정보의 콘텐츠가 변경됩니다. 다음 보안 형식을 비교합니다.

apiVersion: v1
kind: Secret
metadata:
  namespace: <target_namespace> 1
  name: <target_secret_name> 2
data:
  azure_client_id: <client_id> 3
  azure_client_secret: <client_secret> 4
  azure_region: <region>
  azure_resource_prefix: <resource_group_prefix> 5
  azure_resourcegroup: <resource_group_prefix>-rg 6
  azure_subscription_id: <subscription_id>
  azure_tenant_id: <tenant_id>
type: Opaque

apiVersion: v1
kind: Secret
metadata:
  namespace: <target_namespace> 1
  name: <target_secret_name> 2
data:
  azure_client_id: <client_id> 3
  azure_federated_token_file: <path_to_token_file> 4
  azure_region: <region>
  azure_subscription_id: <subscription_id>
  azure_tenant_id: <tenant_id>
type: Opaque

OpenShift Container Platform 구성 요소에는 다음과 같은 권한이 필요합니다. 이러한 값은 각 구성 요소의 CredentialsRequest CR(사용자 정의 리소스)에 있습니다.

Azure 클러스터의 OLM(Operator Lifecycle Manager)에서 관리하는 특정 Operator는 Microsoft Entra Workload ID와 함께 수동 모드를 사용할 수 있습니다. 이러한 Operator는 클러스터 외부에서 관리되는 단기 인증 정보로 인증합니다. Operator가 Workload ID로 인증을 지원하는지 확인하려면 OperatorHub에서 Operator 설명을 참조하십시오.