19.5. 구성 요소에 대한 단기 인증 정보가 있는 수동 모드
설치하는 동안 수동 모드에서 작동하도록 CCO(Cloud Credential Operator)를 구성하고 CCO 유틸리티(ccoctl
)를 사용하여 OpenShift Container Platform 클러스터 외부에서 생성 및 관리되는 개별 구성 요소에 대한 단기 보안 인증 정보를 구현할 수 있습니다.
이 인증 정보 전략은 AWS(Amazon Web Services), GCP(Google Cloud Platform) 및 글로벌 Microsoft Azure에서만 지원됩니다. 새 OpenShift Container Platform 클러스터를 설치하는 동안 전략을 구성해야 합니다. 이 기능을 사용하기 위해 다른 인증 정보 전략을 사용하는 기존 클러스터를 구성할 수 없습니다.
클라우드 공급자는 이 인증 방법을 구현하는 데 다른 용어를 사용합니다.
클라우드 공급자 | 공급자 nomenclature |
---|---|
AWS(Amazon Web Services) | AWS STS(보안 토큰 서비스) |
GCP(Google Cloud Platform) | GCP 워크로드 ID |
Global Microsoft Azure | Microsoft Entra Workload ID |
19.5.1. AWS 보안 토큰 서비스
STS를 사용하는 수동 모드에서 개별 OpenShift Container Platform 클러스터 구성 요소는 AWS STS(보안 토큰 서비스)를 사용하여 단기적이고 제한된 권한 보안 인증 정보를 제공하는 IAM 역할을 할당합니다. 이러한 인증 정보는 AWS API 호출을 수행하는 각 구성 요소에 특정적인 IAM 역할과 연결됩니다.
추가 리소스
19.5.1.1. AWS 보안 토큰 서비스 인증 프로세스
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에 프로젝션하고 인증에 사용할 수 있습니다.
19.5.1.1.2. AWS STS의 토큰 새로 고침
Pod에서 사용하는 서명된 서비스 계정 토큰이 일정 기간 후에 만료됩니다. AWS STS를 사용하는 클러스터의 경우 이 기간은 3600초 또는 1시간입니다.
토큰이 새로 고쳐지도록 Pod가 할당된 노드의 kubelet입니다. kubelet은 토큰이 수명의 80%보다 오래되면 토큰을 교체하려고 시도합니다.
19.5.1.1.3. AWS STS의 OpenID Connect 요구 사항
OIDC 구성에 대한 암호화 키의 공개 부분을 공개 또는 개인 S3 버킷에 저장할 수 있습니다.
OIDC 사양은 HTTPS를 사용해야 합니다. AWS 서비스에는 JWKS(JSON 웹 키 세트) 공개 키 형식의 OIDC 문서를 노출하려면 공개 끝점이 필요합니다. 이를 통해 AWS 서비스는 Kubernetes에서 서명한 바인딩된 토큰의 유효성을 검사하고 인증서를 신뢰할지 여부를 확인할 수 있습니다. 결과적으로 S3 버킷 옵션에는 공용 HTTPS 끝점과 프라이빗 끝점이 모두 지원되지 않습니다.
AWS STS를 사용하려면 AWS STS 서비스의 공용 AWS 백본이 공용 S3 버킷 또는 공용 CloudFront 엔드포인트가 있는 프라이빗 S3 버킷과 통신할 수 있어야 합니다. 설치 중에 CredentialsRequest
오브젝트를 처리할 때 사용할 버킷 유형을 선택할 수 있습니다.
-
기본적으로 CCO 유틸리티(
ccoctl
)는 OIDC 구성 파일을 공용 S3 버킷에 저장하고 S3 URL을 공용 OIDC 엔드포인트로 사용합니다. -
또는
ccoctl
유틸리티에서 공개 CloudFront 배포 URL을 통해 IAM ID 공급자가 액세스하는 프라이빗 S3 버킷에 OIDC 구성을 저장할 수 있습니다.
19.5.1.2. AWS 구성 요소 시크릿 형식
AWS STS(보안 토큰 서비스)와 함께 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 AWS 인증 정보의 콘텐츠가 변경됩니다. 다음 보안 형식을 비교합니다.
장기 인증 정보를 사용하는 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>
AWS STS를 사용하는 AWS 시크릿 형식
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
19.5.1.3. AWS 구성 요소 시크릿 권한 요구사항
OpenShift Container Platform 구성 요소에는 다음과 같은 권한이 필요합니다. 이러한 값은 각 구성 요소의 CredentialsRequest
CR(사용자 정의 리소스)에 있습니다.
이러한 권한은 모든 리소스에 적용됩니다. 지정하지 않는 한 이러한 권한에 대한 요청 조건이 없습니다.
Component | 사용자 정의 리소스 | 서비스에 필요한 권한 |
---|---|---|
Cluster CAPI Operator |
| EC2
Elastic 로드 밸런싱
IAM(Identity and Access Management)
키 관리 서비스(Key Management Service)
|
Machine API Operator |
| EC2
Elastic 로드 밸런싱
IAM(Identity and Access Management)
키 관리 서비스(Key Management Service)
|
Cloud Credential Operator |
| IAM(Identity and Access Management)
|
Cluster Image Registry Operator |
| S3
|
Ingress Operator |
| Elastic 로드 밸런싱
Route 53
Tag
STS(Security Token Service)
|
CNO(Cluster Network Operator) |
| EC2
|
AWS Elastic Block Store CSI Driver Operator |
| EC2
키 관리 서비스(Key Management Service)
|
-
요청 조건:
kms:GrantIsForAWSResource: true
19.5.1.4. AWS STS를 통한 인증에 대한 OLM 관리 Operator 지원
OpenShift Container Platform 클러스터 구성 요소 외에도 AWS 클러스터의 OLM(Operator Lifecycle Manager)에서 관리하는 일부 Operator는 STS를 사용하여 수동 모드를 사용할 수 있습니다. 이러한 Operator는 클러스터 외부에서 관리되는 제한된 권한의 단기 인증 정보로 인증합니다. Operator가 AWS STS를 통한 인증을 지원하는지 확인하려면 OperatorHub에서 Operator 설명을 참조하십시오.
19.5.2. GCP 워크로드 ID
GCP 워크로드 ID가 있는 수동 모드에서 개별 OpenShift Container Platform 클러스터 구성 요소는 GCP 워크로드 ID 공급자를 사용하여 구성 요소가 단기적이고 제한된 권한 인증 정보를 사용하여 GCP 서비스 계정을 가장할 수 있습니다.
추가 리소스
19.5.2.1. GCP 워크로드 ID 인증 프로세스
새로운 인증 정보 및 새로 고침 인증 정보에 대한 요청은 IAM 서비스 계정과 결합된 적절하게 구성된 OpenID Connect(OIDC) ID 공급자를 사용하여 자동화됩니다. GCP에서 신뢰하는 서비스 계정 토큰은 OpenShift Container Platform에서 서명하고 Pod에 프로젝션하고 인증에 사용할 수 있습니다. 토큰은 1시간 후에 새로 고쳐집니다.
다음 다이어그램에서는 GCP 워크로드 ID를 사용할 때 GCP와 OpenShift Container Platform 클러스터 간의 인증 흐름을 자세히 설명합니다.
그림 19.3. GCP 워크로드 ID 인증 흐름
19.5.2.2. GCP 구성 요소 시크릿 형식
GCP 워크로드 ID로 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 GCP 인증 정보의 내용이 변경됩니다. 다음 시크릿 콘텐츠를 비교합니다.
GCP 시크릿 형식
apiVersion: v1 kind: Secret metadata: namespace: <target_namespace> 1 name: <target_secret_name> 2 data: service_account.json: <service_account> 3
장기 인증 정보를 사용하여 Base64로 인코딩된 service_account.json
파일의 콘텐츠
{ "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>" }
GCP Workload ID를 사용하여 Base64로 인코딩된 service_account.json
파일의 내용
{ "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" } } }
19.5.3. Microsoft Entra Workload ID
Microsoft Entra Workload ID가 있는 수동 모드에서 개별 OpenShift Container Platform 클러스터 구성 요소는 Workload ID 공급자를 사용하여 구성 요소를 단기 보안 인증 정보를 할당합니다.
19.5.3.1. Microsoft Entra Workload ID 인증 프로세스
다음 다이어그램에서는 Microsoft Entra Workload ID를 사용할 때 Azure와 OpenShift Container Platform 클러스터 간의 인증 흐름을 자세히 설명합니다.
그림 19.4. 워크로드 ID 인증 흐름
19.5.3.2. Azure 구성 요소 시크릿 형식
Microsoft Entra Workload ID로 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 Azure 인증 정보의 콘텐츠가 변경됩니다. 다음 보안 형식을 비교합니다.
장기 인증 정보를 사용하는 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
Microsoft Entra Workload ID를 사용하는 Azure 시크릿 형식
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
19.5.3.3. Azure 구성 요소 시크릿 권한 요구사항
OpenShift Container Platform 구성 요소에는 다음과 같은 권한이 필요합니다. 이러한 값은 각 구성 요소의 CredentialsRequest
CR(사용자 정의 리소스)에 있습니다.
Component | 사용자 정의 리소스 | 서비스에 필요한 권한 |
---|---|---|
Cloud Controller Manager Operator |
|
|
Cluster CAPI Operator |
|
역할: |
Machine API Operator |
|
|
Cluster Image Registry Operator |
| 데이터 권한
일반 권한
|
Ingress Operator |
|
|
CNO(Cluster Network Operator) |
|
|
Azure File CSI Driver Operator |
|
|
Azure Disk CSI Driver Operator |
|
|
- 이 구성 요소에는 권한 세트가 아닌 역할이 필요합니다.
19.5.3.4. Microsoft Entra Workload ID를 사용한 인증에 대한 OLM 관리형 Operator 지원
OpenShift Container Platform 클러스터 구성 요소 외에도 Azure 클러스터의 OLM(Operator Lifecycle Manager)에서 관리하는 일부 Operator는 Microsoft Entra Workload ID와 함께 수동 모드를 사용할 수 있습니다. 이러한 Operator는 클러스터 외부에서 관리되는 단기 인증 정보로 인증합니다. Operator가 Workload ID로 인증을 지원하는지 확인하려면 OperatorHub에서 Operator 설명을 참조하십시오.