20.5. 구성 요소에 대한 단기 자격 증명을 사용하는 수동 모드
설치하는 동안 CCO(Cloud Credential Operator)를 수동 모드로 작동하도록 구성하고 CCO 유틸리티( ccoctl )를 사용하여 OpenShift Container Platform 클러스터 외부에서 생성 및 관리되는 개별 구성 요소에 대한 단기 보안 자격 증명을 구현할 수 있습니다.
이 자격 증명 전략은 Amazon Web Services(AWS), Google Cloud 및 글로벌 Microsoft Azure에서만 지원됩니다.
AWS 및 Google Cloud 클러스터의 경우 새로운 OpenShift Container Platform 클러스터를 설치하는 동안 이 전략을 사용하도록 클러스터를 구성해야 합니다. 다른 자격 증명 전략을 사용하는 기존 AWS 또는 Google Cloud 클러스터에서는 이 기능을 사용하도록 구성할 수 없습니다.
설치 중에 Microsoft Entra Workload ID를 사용하도록 Azure 클러스터를 구성하지 않은 경우 기존 클러스터에서 이 인증 방법을 활성화 할 수 있습니다.
클라우드 제공자는 이 인증 방법을 구현하기 위해 서로 다른 용어를 사용합니다.
| 클라우드 공급자 | 공급자 명명법 |
|---|---|
| AWS(Amazon Web Services) | AWS STS(보안 토큰 서비스) |
| Google Cloud | GCP 워크로드 ID |
| Global Microsoft Azure | Microsoft Entra Workload ID |
20.5.1. AWS 보안 토큰 서비스 링크 복사링크가 클립보드에 복사되었습니다!
STS를 사용하는 수동 모드에서 개별 OpenShift Container Platform 클러스터 구성 요소는 AWS STS(Security Token Service)를 사용하여 단기적이고 제한된 권한 보안 인증 정보를 제공하는 구성 요소 IAM 역할을 할당합니다. 이러한 인증 정보는 AWS API 호출을 수행하는 각 구성 요소에 특정적인 IAM 역할과 연결됩니다.
20.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 버킷에 저장된 공개 키와 일치하는지 확인합니다.
20.5.1.1.1. AWS STS의 인증 흐름 링크 복사링크가 클립보드에 복사되었습니다!
다음 다이어그램은 AWS STS를 사용할 때 AWS와 OpenShift Container Platform 클러스터 간의 인증 흐름을 보여줍니다.
- 토큰 서명 은 OpenShift Container Platform 클러스터의 Kubernetes 서비스 계정 서명 서비스입니다.
- Pod의 Kubernetes 서비스 계정 은 서명된 서비스 계정 토큰입니다.
그림 20.2. AWS 보안 토큰 서비스 인증 흐름
새로운 인증 정보 및 새로 고침 인증 정보에 대한 요청은 AWS IAM 역할과 결합된 적절하게 구성된 AWS IAM OIDC(OpenID Connect) ID 공급자를 사용하여 자동화됩니다. AWS IAM에서 신뢰하는 서비스 계정 토큰은 OpenShift Container Platform에서 서명하고 Pod에 프로젝션하고 인증에 사용할 수 있습니다.
20.5.1.1.2. AWS STS의 토큰 새로 고침 링크 복사링크가 클립보드에 복사되었습니다!
Pod에서 사용하는 서명된 서비스 계정 토큰이 일정 기간 후에 만료됩니다. AWS STS를 사용하는 클러스터의 경우 이 기간은 3600초 또는 1시간입니다.
토큰이 새로 고쳐지도록 Pod가 할당된 노드의 kubelet입니다. kubelet은 토큰이 수명의 80%보다 오래되면 토큰을 교체하려고 시도합니다.
20.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 구성을 저장할 수 있습니다.
20.5.1.2. AWS 구성 요소 비밀 형식 링크 복사링크가 클립보드에 복사되었습니다!
AWS 보안 토큰 서비스(STS)에서 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 AWS 자격 증명의 내용이 변경됩니다. 다음 비밀 형식을 비교해 보세요.
장기 자격 증명을 사용하는 AWS 비밀 형식
AWS STS를 사용한 AWS 비밀 형식
20.5.1.3. AWS 구성 요소 비밀 권한 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 구성 요소에는 다음 권한이 필요합니다. 이러한 값은 각 구성 요소의 CredentialsRequest 사용자 정의 리소스(CR)에 있습니다.
이러한 권한은 모든 리소스에 적용됩니다. 별도로 지정하지 않는 한 이러한 권한에는 요청 조건이 없습니다.
| Component | 사용자 정의 리소스 | 서비스에 필요한 권한 |
|---|---|---|
| cluster-capi-operator |
| EC2
탄력적 부하 분산
IAM(ID 및 액세스 관리) API
키 관리 서비스(KMS)
|
| Machine API Operator |
| EC2
탄력적 부하 분산
IAM(ID 및 액세스 관리) API
키 관리 서비스(KMS)
|
| Cloud Credential Operator |
| IAM(ID 및 액세스 관리) API
|
| Cluster Image Registry Operator |
| S3
|
| Ingress Operator |
| 탄력적 부하 분산
라우트
Tag
AWS STS(보안 토큰 서비스)
|
| CNO(Cluster Network Operator) |
| EC2
|
| AWS Elastic Block Store CSI Driver Operator |
| EC2
키 관리 서비스(KMS)
|
-
요청 조건:
kms:GrantIsForAWSResource: true
20.5.1.4. AWS STS 인증을 위한 OLM 관리 운영자 지원 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클러스터의 Operator Lifecycle Manager(OLM)가 관리하는 특정 운영자는 STS에서 수동 모드를 사용할 수 있습니다. 이러한 운영자는 클러스터 외부에서 관리되는 제한된 권한의 단기 자격 증명을 사용하여 인증합니다. 운영자가 AWS STS를 통한 인증을 지원하는지 확인하려면 OperatorHub에서 운영자 설명을 참조하세요.
20.5.2. GCP 워크로드 ID 링크 복사링크가 클립보드에 복사되었습니다!
GCP 워크로드 ID를 사용하는 수동 모드에서 개별 OpenShift Container Platform 클러스터 구성 요소는 Google Cloud 워크로드 ID 공급자를 사용하여 구성 요소가 단기적이고 권한이 제한된 자격 증명을 사용하여 Google Cloud 서비스 계정을 가장할 수 있도록 허용합니다.
20.5.2.1. Google Cloud Workload Identity 인증 프로세스 링크 복사링크가 클립보드에 복사되었습니다!
새로운 인증 정보 및 새로 고침 인증 정보에 대한 요청은 IAM 서비스 계정과 결합된 적절하게 구성된 OpenID Connect(OIDC) ID 공급자를 사용하여 자동화됩니다. Google Cloud에서 신뢰하는 서비스 계정 토큰은 OpenShift Container Platform에서 서명되며 Pod에 투영되어 인증에 사용될 수 있습니다. 토큰은 1시간 후에 새로 고쳐집니다.
다음 다이어그램은 Google Cloud Workload Identity를 사용할 때 Google Cloud와 OpenShift Container Platform 클러스터 간의 인증 흐름을 자세히 보여줍니다.
그림 20.3. Google Cloud Workload Identity 인증 흐름
20.5.2.2. Google Cloud 구성 요소 비밀 형식 링크 복사링크가 클립보드에 복사되었습니다!
Google Cloud Workload Identity에서 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 Google Cloud 자격 증명의 내용이 변경됩니다. 다음의 비밀 내용을 비교해 보세요.
Google Cloud 비밀 형식
수명이 긴 자격 증명을 사용하는 Base64로 인코딩된 service_account.json 파일의 내용
Google Cloud Workload Identity를 사용하여 Base64로 인코딩된 service_account.json 파일의 내용
20.5.2.3. GCP 워크로드 ID 인증을 위한 OLM 관리 운영자 지원 링크 복사링크가 클립보드에 복사되었습니다!
Google Cloud 클러스터의 Operator Lifecycle Manager(OLM)에서 관리하는 특정 운영자는 GCP 워크로드 ID와 함께 수동 모드를 사용할 수 있습니다. 이러한 운영자는 클러스터 외부에서 관리되는 제한된 권한의 단기 자격 증명을 사용하여 인증합니다. 운영자가 GCP 워크로드 ID를 통한 인증을 지원하는지 확인하려면 OperatorHub에서 운영자 설명을 참조하세요.
20.5.2.4. GCP 워크로드 ID 서비스 계정 토큰에 대한 애플리케이션 지원 링크 복사링크가 클립보드에 복사되었습니다!
Google Cloud Platform 워크로드 ID를 사용하는 OpenShift Container Platform 클러스터의 고객 워크로드에 있는 애플리케이션은 GCP 워크로드 ID를 사용하여 인증할 수 있습니다. 애플리케이션에서 이 인증 방법을 사용하려면 클라우드 공급자 콘솔과 OpenShift Container Platform 클러스터에서 구성 단계를 완료해야 합니다.
20.5.3. Microsoft Entra Workload ID 링크 복사링크가 클립보드에 복사되었습니다!
Microsoft Entra Workload ID를 사용하는 수동 모드에서는 개별 OpenShift Container Platform 클러스터 구성 요소가 Workload ID 공급자를 사용하여 구성 요소에 단기 보안 자격 증명을 할당합니다.
20.5.3.1. Microsoft Entra Workload ID 인증 프로세스 링크 복사링크가 클립보드에 복사되었습니다!
다음 다이어그램은 Microsoft Entra Workload ID를 사용할 때 Azure와 OpenShift Container Platform 클러스터 간의 인증 흐름을 자세히 보여줍니다.
그림 20.4. 워크로드 ID 인증 흐름
20.5.3.2. Azure 구성 요소 시크릿 형식 링크 복사링크가 클립보드에 복사되었습니다!
Microsoft Entra Workload ID를 사용하여 수동 모드를 사용하면 개별 OpenShift Container Platform 구성 요소에 제공되는 Azure 자격 증명의 내용이 변경됩니다. 다음 비밀 형식을 비교해 보세요.
장기 자격 증명을 사용하는 Azure 비밀 형식
Microsoft Entra Workload ID를 사용한 Azure 비밀 형식
20.5.3.3. Azure 구성 요소 비밀 권한 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 구성 요소에는 다음 권한이 필요합니다. 이러한 값은 각 구성 요소의 CredentialsRequest 사용자 정의 리소스(CR)에 있습니다.
| Component | 사용자 정의 리소스 | 서비스에 필요한 권한 |
|---|---|---|
| 클라우드 컨트롤러 관리자 운영자 |
|
|
| 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 |
|
|
- 이 구성 요소에는 권한 집합보다는 역할이 필요합니다.
20.5.3.4. Microsoft Entra Workload ID 인증을 위한 OLM 관리 운영자 지원 링크 복사링크가 클립보드에 복사되었습니다!
Azure 클러스터의 OLM(Operator Lifecycle Manager)에서 관리하는 특정 운영자는 Microsoft Entra Workload ID를 사용하여 수동 모드를 사용할 수 있습니다. 이러한 운영자는 클러스터 외부에서 관리되는 단기 자격 증명을 사용하여 인증합니다. 운영자가 워크로드 ID를 통한 인증을 지원하는지 확인하려면 OperatorHub에서 운영자 설명을 참조하세요.