5장. Operator 개발
5.1. 토큰 인증 링크 복사링크가 클립보드에 복사되었습니다!
5.1.1. 클라우드 공급자의 Operator에 대한 토큰 인증 링크 복사링크가 클립보드에 복사되었습니다!
많은 클라우드 공급자는 단기적이고 제한된 권한 보안 인증 정보를 제공하는 계정 토큰을 사용하여 인증을 활성화할 수 있습니다.
OpenShift Container Platform에는 클라우드 공급자 인증 정보를 CRD(사용자 정의 리소스 정의)로 관리하는 CCO(Cloud Credential Operator)가 포함되어 있습니다. CCO는 CredentialsRequest
CR(사용자 정의 리소스)에서 동기화되므로 OpenShift Container Platform 구성 요소가 필요한 특정 권한으로 클라우드 공급자 인증 정보를 요청할 수 있습니다.
이전 버전에서는 CCO가 수동 모드인 클러스터에서 OLM(Operator Lifecycle Manager)에서 관리하는 Operator에 종종 사용자가 필요한 클라우드 인증 정보를 수동으로 프로비저닝하는 방법에 대한 자세한 지침이 제공되었습니다.
OpenShift Container Platform 4.14부터 CCO는 특정 클라우드 공급자에서 단기 인증 정보를 사용하도록 활성화된 클러스터에서 실행되는 시기를 감지할 수 있습니다. 그러면 Operator 작성자가 Operator에서 업데이트된 CCO를 지원할 수 있는 경우 특정 인증 정보를 반자동으로 프로비저닝할 수 있습니다.
5.1.2. AWS STS를 사용하여 OLM 관리 Operator의 CCO 기반 워크플로 링크 복사링크가 클립보드에 복사되었습니다!
AWS에서 실행되는 OpenShift Container Platform 클러스터가 STS(Security Token Service) 모드인 경우 클러스터가 AWS 및 OpenShift Container Platform의 기능을 사용하여 애플리케이션 수준에서 IAM 역할을 사용하고 있음을 의미합니다. STS를 사용하면 애플리케이션에서 IAM 역할을 가정할 수 있는 JSON 웹 토큰(JWT)을 제공할 수 있습니다.
JWT에는 서비스 계정에 대한 임시 부여 권한을 허용하는 sts:AssumeRoleWithWebIdentity
IAM 작업에 대한 Amazon Resource Name(ARN)이 포함됩니다. JWT에는 AWS IAM에서 검증할 수 있는 ProjectedServiceAccountToken
의 서명 키가 포함되어 있습니다. 서명된 서비스 계정 토큰 자체는 AWS 역할을 가정하는 데 필요한 JWT로 사용됩니다.
CCO(Cloud Credential Operator)는 기본적으로 클라우드 공급자에서 실행되는 OpenShift Container Platform 클러스터에 설치된 클러스터 Operator입니다. STS의 목적을 위해 CCO는 다음 기능을 제공합니다.
- STS 지원 클러스터에서 실행 중인 시기 감지
-
AWS 리소스에 대한 Operator 액세스 권한을 부여하는 데 필요한 정보를 제공하는 필드가 있는지
CredentialsRequest
오브젝트를 확인합니다.
CCO는 수동 모드에서도 이 탐지를 수행합니다. 올바르게 구성되면 CCO는 Operator 네임스페이스에 필요한 액세스 정보가 있는 Secret
오브젝트를 생성합니다.
OpenShift Container Platform 4.14부터 CCO는 STS 워크플로우에 필요한 정보가 포함된 시크릿
생성을 요청할 수 있는 CredentialsRequest
오브젝트의 확장된 사용을 통해 이 작업을 반자동화할 수 있습니다. 사용자는 웹 콘솔 또는 CLI에서 Operator를 설치할 때 역할 ARN을 제공할 수 있습니다.
업데이트에 대한 자동 승인이 있는 서브스크립션은 업데이트하기 전에 권한을 변경할 수 있으므로 권장되지 않습니다. 업데이트에 대한 수동 승인이 있는 서브스크립션을 통해 관리자는 최신 버전의 권한을 확인하고 필요한 단계를 수행한 다음 업데이트할 수 있습니다.
OpenShift Container Platform 4.14 이상에서 업데이트된 CCO와 함께 Operator를 사용할 수 있도록 Operator 작성자로서 STS 토큰 인증을 처리하는 것 외에도 사용자와 이전 CCO 버전의 차이점을 처리하도록 코드를 추가해야 합니다(Operator가 STS 활성화되지 않은 경우). 권장되는 방법은 올바르게 채워진 STS 필드를 사용하여 CredentialsRequest
오브젝트를 제공하고 CCO가 시크릿
을 생성하도록 하는 것입니다.
버전 4.14 이전의 OpenShift Container Platform 클러스터를 지원하려는 경우 CCO 유틸리티(ccoctl
)를 사용하여 STS-enabling 정보를 사용하여 시크릿을 수동으로 생성하는 방법에 대한 지침을 사용자에게 제공하는 것이 좋습니다. 이전 CCO 버전은 클러스터에서 STS 모드를 인식하지 못하며 시크릿을 생성할 수 없습니다.
코드는 나타나지 않는 시크릿을 확인하고 사용자가 제공한 대체 지침을 따르도록 경고해야 합니다. 자세한 내용은 "Alternative Method" 하위 섹션을 참조하십시오.
5.1.2.1. Operator가 AWS STS를 사용하여 CCO 기반 워크플로우를 지원하도록 활성화 링크 복사링크가 클립보드에 복사되었습니다!
OLM(Operator Lifecycle Manager)에서 프로젝트를 실행하도록 프로젝트를 설계하는 Operator 작성자는 CCO(Cloud Credential Operator)를 지원하도록 프로젝트를 사용자 정의하여 Operator를 STS 사용 OpenShift Container Platform 클러스터에서 AWS에 대해 인증할 수 있습니다.
이 방법을 사용하면 Operator에서 CredentialsRequest
오브젝트를 생성하고 결과 Secret
오브젝트를 읽는 데 필요한 RBAC 권한이 필요합니다.
기본적으로 Operator 배포와 관련된 Pod는 serviceAccountToken
볼륨을 마운트하여 결과 Secret
오브젝트에서 서비스 계정 토큰을 참조할 수 있습니다.
전제 조건
- OpenShift Container Platform 4.14 이상
- STS 모드의 클러스터
- OLM 기반 Operator 프로젝트
프로세스
Operator 프로젝트의 CSV(
ClusterServiceVersion
) 오브젝트를 업데이트합니다.Operator에
CredentialsRequests
오브젝트를 생성할 수 있는 RBAC 권한이 있는지 확인합니다.예 5.1.
clusterPermissions
목록의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow AWS STS를 사용하여 이 CCO 기반 워크플로우 방법에 대한 지원을 클레임하려면 다음 주석을 추가합니다.
# ... metadata: annotations: features.operators.openshift.io/token-auth-aws: "true"
# ... metadata: annotations: features.operators.openshift.io/token-auth-aws: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator 프로젝트 코드를 업데이트합니다.
Subscription
오브젝트를 통해 Pod에 설정된 환경 변수에서 ARN 역할을 가져옵니다. 예를 들면 다음과 같습니다.// Get ENV var roleARN := os.Getenv("ROLEARN") setupLog.Info("getting role ARN", "role ARN = ", roleARN) webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"
// Get ENV var roleARN := os.Getenv("ROLEARN") setupLog.Info("getting role ARN", "role ARN = ", roleARN) webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CredentialsRequest
개체를 패치하고 적용할 준비가 되었는지 확인합니다. 예를 들면 다음과 같습니다.예 5.2.
CredentialsRequest
오브젝트 생성 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또는 YAML 형식의
CredentialsRequest
오브젝트(예: Operator 프로젝트 코드의 일부)에서 시작하는 경우 다르게 처리할 수 있습니다.예 5.3. YAML 형식의
CredentialsRequest
오브젝트 생성 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Operator 번들에
CredentialsRequest
오브젝트를 추가하는 것은 현재 지원되지 않습니다.인증 정보 요청에 ARN 및 웹 ID 토큰 경로를 추가하고 Operator 초기화 중에 적용합니다.
예 5.4. Operator 초기화 중
CredentialsRequest
오브젝트 적용 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator에서 조정 중인 다른 항목과 함께 호출되는 다음 예와 같이 Operator가 CCO에서
Secret
오브젝트가 표시될 때까지 기다릴 수 있습니다.예 5.5.
Secret
오브젝트 대기의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
시간 초과
값은 CCO에서 추가된CredentialsRequest
오브젝트를 감지하고Secret
오브젝트를 생성하는 속도의 추정치를 기반으로 합니다. Operator가 아직 클라우드 리소스에 액세스하지 않는 이유를 확인할 수 있는 클러스터 관리자에게 시간을 낮추거나 사용자 정의 피드백을 생성하는 것을 고려할 수 있습니다.
인증 정보 요청에서 CCO에서 생성한 보안을 읽고 해당 시크릿의 데이터가 포함된 AWS 구성 파일을 생성하여 AWS 구성을 설정합니다.
예 5.6. AWS 구성 생성 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요시크릿은 존재하는 것으로 가정되지만 Operator 코드는 이 시크릿을 사용할 때 대기하고 재시도하여 CCO에 시간을 할애하여 보안을 생성해야 합니다.
또한 대기 기간은 결국 OpenShift Container Platform 클러스터 버전 및 CCO가 STS 탐지를 사용하여
CredentialsRequest
오브젝트 워크플로를 지원하지 않는 이전 버전일 수 있음을 사용자에게 시간 초과하고 경고해야 합니다. 이러한 경우 다른 방법을 사용하여 시크릿을 추가해야 함을 사용자에게 지시합니다.AWS SDK 세션을 구성합니다. 예를 들면 다음과 같습니다.
예 5.7. AWS SDK 세션 구성 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.2.2. 역할 사양 링크 복사링크가 클립보드에 복사되었습니다!
Operator 설명에는 설치 전에 생성하는 데 필요한 역할의 세부 정보가 포함되어야 합니다. 이는 관리자가 실행할 수 있는 스크립트 형태로 이상적입니다. 예를 들면 다음과 같습니다.
예 5.8. 역할 생성 스크립트의 예
5.1.2.3. 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
5.1.2.3.1. 인증 실패 링크 복사링크가 클립보드에 복사되었습니다!
인증이 실패하면 Operator에 제공된 토큰을 사용하여 웹 ID가 있는 역할을 가정할 수 있는지 확인합니다.
프로세스
Pod에서 토큰을 추출합니다.
oc exec operator-pod -n <namespace_name> \ -- cat /var/run/secrets/openshift/serviceaccount/token
$ oc exec operator-pod -n <namespace_name> \ -- cat /var/run/secrets/openshift/serviceaccount/token
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod에서 ARN 역할을 추출합니다.
oc exec operator-pod -n <namespace_name> \ -- cat /<path>/<to>/<secret_name>
$ oc exec operator-pod -n <namespace_name> \ -- cat /<path>/<to>/<secret_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 경로에 root를 사용하지 마십시오.
웹 ID 토큰을 사용하여 역할을 가정합니다.
aws sts assume-role-with-web-identity \ --role-arn $ROLEARN \ --role-session-name <session_name> \ --web-identity-token $TOKEN
$ aws sts assume-role-with-web-identity \ --role-arn $ROLEARN \ --role-session-name <session_name> \ --web-identity-token $TOKEN
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.2.3.2. secret이 올바르게 마운트되지 않음 링크 복사링크가 클립보드에 복사되었습니다!
루트가 아닌 사용자로 실행되는 Pod는 기본적으로 AWS 공유 인증 정보 파일이 존재하는 /root
디렉토리에 쓸 수 없습니다. 보안이 AWS 인증 정보 파일 경로에 올바르게 마운트되지 않은 경우 시크릿을 다른 위치에 마운트하고 AWS SDK에서 공유 인증 정보 파일 옵션을 활성화하는 것이 좋습니다.
5.1.2.4. 대체 방법 링크 복사링크가 클립보드에 복사되었습니다!
Operator 작성자의 대체 방법으로는 Operator를 설치하기 전에 사용자가 CCO(Cloud Credential Operator)에 대한 CredentialsRequest
오브젝트를 생성해야 함을 나타낼 수 있습니다.
운영자 지침에는 사용자에게 다음 내용이 명시되어야 합니다.
-
지침에 YAML을 인라인으로 제공하거나 사용자에게 다운로드 위치를 지정하여
CredentialsRequest
개체의 YAML 버전을 제공합니다. -
사용자에게
CredentialsRequest
객체를 생성하도록 지시합니다.
OpenShift Container Platform 4.14 이상에서는 CredentialsRequest
객체가 적절한 STS 정보가 추가된 클러스터에 나타난 후, 운영자가 CCO에서 생성된 비밀을
읽거나 클러스터 서비스 버전(CSV)에서 마운트를 정의한 후 이를 마운트할 수 있습니다.
이전 버전의 OpenShift Container Platform의 경우 운영자 지침에는 사용자에게 다음 내용도 명시되어야 합니다.
-
CCO 유틸리티(
ccoctl
)를 사용하여CredentialsRequest
객체에서Secret
YAML 객체를 생성합니다. -
적절한 네임스페이스의 클러스터에
Secret
객체를 적용합니다.
운영자는 클라우드 API와 통신하기 위해 결과적인 비밀을 사용할 수 있어야 합니다. 이 경우 비밀은 운영자가 설치되기 전에 사용자에 의해 생성되므로 운영자는 다음 중 하나를 수행할 수 있습니다.
-
CSV 내의
배포
개체에 명시적 마운트를 정의합니다. -
AWS STS를 사용하여 CCO 기반 워크플로를 지원하도록 운영자 활성화" 권장 방법에 표시된 대로 API 서버에서
Secret
객체를 프로그래밍 방식으로 읽습니다.
5.1.3. Microsoft Entra Workload ID가 있는 OLM 관리 Operator의 CCO 기반 워크플로 링크 복사링크가 클립보드에 복사되었습니다!
Azure에서 실행되는 OpenShift Container Platform 클러스터가 Workload Identity/Federated Identity 모드인 경우, 해당 클러스터는 Azure 및 OpenShift Container Platform의 기능을 활용하여 애플리케이션 수준에서 Microsoft Entra Workload ID에 사용자가 할당한 관리 ID 또는 앱 등록을 적용합니다.
CCO(Cloud Credential Operator)는 클라우드 공급자에서 실행되는 OpenShift Container Platform 클러스터에 기본적으로 설치되는 클러스터 운영자입니다. OpenShift Container Platform 4.14.8부터 CCO는 워크로드 ID를 사용하여 OLM 관리 운영자의 워크플로를 지원합니다.
워크로드 ID의 목적을 위해 CCO는 다음과 같은 기능을 제공합니다.
- Workload ID가 활성화된 클러스터에서 실행 중인지 감지합니다.
-
Azure 리소스에 대한 액세스 권한을 운영자에게 부여하는 데 필요한 정보를 제공하는 필드가 있는지
CredentialsRequest
개체를 확인합니다.
CCO는 CredentialsRequest
객체를 확장하여 이 프로세스를 반자동화할 수 있으며, 이를 통해 워크로드 ID 워크플로에 필요한 정보가 포함된 비밀을
생성하도록 요청할 수 있습니다.
업데이트에 대한 자동 승인 기능이 있는 구독은 업데이트하기 전에 권한을 변경해야 할 수 있으므로 권장하지 않습니다. 업데이트에 대한 수동 승인 기능이 있는 구독을 통해 관리자는 이후 버전의 권한을 확인하고, 필요한 조치를 취한 다음 업데이트할 수 있습니다.
OpenShift Container Platform 4.14 이상에서 업데이트된 CCO와 함께 사용할 Operator를 준비하는 Operator 작성자는 사용자에게 지침을 제공하고 이전 CCO 버전과의 차이점을 처리하는 코드를 추가해야 하며, (Operator가 아직 활성화되지 않은 경우) 워크로드 ID 토큰 인증도 처리해야 합니다. 권장되는 방법은 올바르게 채워진 워크로드 ID 필드가 있는 CredentialsRequest
객체를 제공하고 CCO가 사용자를 위해 Secret
객체를 생성하도록 하는 것입니다.
4.14 버전 이전의 OpenShift Container Platform 클러스터를 지원할 계획이라면 CCO 유틸리티( ccoctl
)를 사용하여 워크로드 ID 활성화 정보로 비밀을 수동으로 생성하는 방법에 대한 지침을 사용자에게 제공하는 것을 고려하세요. 이전 CCO 버전에서는 클러스터의 워크로드 ID 모드를 인식하지 못해 비밀을 생성할 수 없습니다.
귀하의 코드는 결코 나타나지 않는 비밀을 확인하고 사용자에게 제공된 대체 지침을 따르도록 경고해야 합니다.
워크로드 ID를 통한 인증에는 다음 정보가 필요합니다.
-
azure_client_id
-
azure_tenant_id
-
azure_region
-
azure_subscription_id
-
azure_federated_token_file
웹 콘솔의 Install Operator 페이지를 통해 클러스터 관리자는 설치 시 이 정보를 제공할 수 있습니다. 그런 다음 이 정보는 Operator Pod의 환경 변수로 Subscription
객체에 전파됩니다.
5.1.3.1. Microsoft Entra Workload ID를 사용하여 운영자가 CCO 기반 워크플로를 지원할 수 있도록 지원 링크 복사링크가 클립보드에 복사되었습니다!
프로젝트를 Operator Lifecycle Manager(OLM)에서 실행하도록 설계하는 Operator 작성자는 프로젝트를 사용자 지정하여 Cloud Credential Operator(CCO)를 지원하도록 하여 Operator가 Microsoft Entra Workload ID 지원 OpenShift Container Platform 클러스터에 대해 인증하도록 할 수 있습니다.
이 방법을 사용하면 운영자는 CredentialsRequest
객체를 생성하고 결과 Secret
객체를 읽기 위한 RBAC 권한이 필요하며 이에 대한 책임이 있습니다.
기본적으로 Operator 배포와 관련된 Pod는 serviceAccountToken
볼륨을 마운트하여 서비스 계정 토큰을 결과 Secret
객체에서 참조할 수 있도록 합니다.
필수 조건
- OpenShift Container Platform 4.14 이상
- 워크로드 ID 모드의 클러스터
- OLM 기반 운영자 프로젝트
프로세스
Operator 프로젝트의
ClusterServiceVersion
(CSV) 객체를 업데이트하세요.운영자가
CredentialsRequests
객체를 생성할 수 있는 RBAC 권한이 있는지 확인하세요.예 5.9.
clusterPermissions
목록 예시Copy to Clipboard Copied! Toggle word wrap Toggle overflow 워크로드 ID를 사용하여 CCO 기반 워크플로의 이 방법에 대한 지원을 주장하려면 다음 주석을 추가하세요.
# ... metadata: annotations: features.operators.openshift.io/token-auth-azure: "true"
# ... metadata: annotations: features.operators.openshift.io/token-auth-azure: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator 프로젝트 코드를 업데이트하세요.
Subscription
객체에 의해 Pod에 설정된 환경 변수에서 클라이언트 ID, 테넌트 ID, 구독 ID를 가져옵니다. 예를 들면 다음과 같습니다.// Get ENV var clientID := os.Getenv("CLIENTID") tenantID := os.Getenv("TENANTID") subscriptionID := os.Getenv("SUBSCRIPTIONID") azureFederatedTokenFile := "/var/run/secrets/openshift/serviceaccount/token"
// Get ENV var clientID := os.Getenv("CLIENTID") tenantID := os.Getenv("TENANTID") subscriptionID := os.Getenv("SUBSCRIPTIONID") azureFederatedTokenFile := "/var/run/secrets/openshift/serviceaccount/token"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 패치 및 적용할
CredentialsRequest
개체가 준비되었는지 확인하세요.참고현재 Operator 번들에
CredentialsRequest
객체를 추가하는 것은 지원되지 않습니다.Azure 자격 증명 정보와 웹 ID 토큰 경로를 자격 증명 요청에 추가하고 운영자 초기화 중에 적용합니다.
예 5.10. Operator 초기화 중
CredentialsRequest
객체 적용 예제Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예에서 보듯이, Operator가 CCO에서
Secret
객체가 나타날 때까지 기다릴 수 있는지 확인하세요. 이 객체는 Operator에서 조정 중인 다른 항목과 함께 호출됩니다.예 5.11.
Secret
객체를 기다리는 예제Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
시간 초과
값은 CCO가 추가된CredentialsRequest
객체를 얼마나 빨리 감지하고Secret
객체를 생성하는지에 대한 추정치에 따라 결정됩니다. 운영자가 아직 클라우드 리소스에 액세스하지 못하는 이유가 무엇인지 궁금해하는 클러스터 관리자를 위해 시간을 줄이거나 맞춤형 피드백을 만드는 것을 고려해 볼 수 있습니다.
-
CredentialsRequest
개체에서 CCO가 생성한 비밀을 읽어 Azure에 인증하고 필요한 자격 증명을 받습니다.
5.1.4. GCP 워크로드 ID를 사용하는 OLM 관리 운영자를 위한 CCO 기반 워크플로 링크 복사링크가 클립보드에 복사되었습니다!
Google Cloud Platform(GCP)에서 실행되는 OpenShift Container Platform 클러스터가 GCP 워크로드 ID/페더레이션 ID 모드인 경우, 해당 클러스터는 Google Cloud Platform(GCP) 및 OpenShift Container Platform의 기능을 활용하여 애플리케이션 수준에서 GCP 워크로드 ID의 권한을 적용하고 있음을 의미합니다.
CCO(Cloud Credential Operator)는 클라우드 공급자에서 실행되는 OpenShift Container Platform 클러스터에 기본적으로 설치되는 클러스터 운영자입니다. OpenShift Container Platform 4.17부터 CCO는 GCP Workload Identity를 사용하여 OLM 관리 운영자의 워크플로를 지원합니다.
GCP 워크로드 ID의 목적을 위해 CCO는 다음과 같은 기능을 제공합니다.
- GCP Workload Identity가 활성화된 클러스터에서 실행 중인지 감지합니다.
-
GCP 리소스에 대한 운영자 액세스 권한을 부여하는 데 필요한 정보를 제공하는 필드가 있는지
CredentialsRequest
객체를 확인합니다.
CCO는 CredentialsRequest
객체를 확장하여 이 프로세스를 반자동화할 수 있으며, 이를 통해 GCP 워크로드 ID 워크플로에 필요한 정보가 포함된 비밀을
생성하도록 요청할 수 있습니다.
업데이트에 대한 자동 승인 기능이 있는 구독은 업데이트하기 전에 권한을 변경해야 할 수 있으므로 권장하지 않습니다. 업데이트에 대한 수동 승인 기능이 있는 구독을 통해 관리자는 이후 버전의 권한을 확인하고, 필요한 조치를 취한 다음 업데이트할 수 있습니다.
OpenShift Container Platform 4.17 이상에서 업데이트된 CCO와 함께 사용할 Operator를 준비하는 Operator 작성자는 사용자에게 지침을 제공하고 이전 CCO 버전과의 차이점을 처리하는 코드를 추가해야 하며, GCP 워크로드 ID 토큰 인증도 처리해야 합니다(Operator가 아직 활성화되지 않은 경우). 권장되는 방법은 올바르게 채워진 GCP 워크로드 ID 필드가 있는 CredentialsRequest
객체를 제공하고 CCO가 사용자를 위해 Secret
객체를 생성하도록 하는 것입니다.
4.17 버전 이전의 OpenShift Container Platform 클러스터를 지원할 계획이라면 CCO 유틸리티( ccoctl
)를 사용하여 GCP 워크로드 ID 활성화 정보로 수동으로 비밀을 생성하는 방법에 대한 지침을 사용자에게 제공하는 것을 고려하세요. 이전 CCO 버전에서는 클러스터의 GCP 워크로드 ID 모드를 인식하지 못해 사용자를 위한 비밀을 생성할 수 없습니다.
귀하의 코드는 결코 나타나지 않는 비밀을 확인하고 사용자에게 제공된 대체 지침을 따르도록 경고해야 합니다.
Google Cloud Platform 워크로드 ID를 통해 단기 토큰을 사용하여 GCP에 인증하려면 운영자가 다음 정보를 제공해야 합니다.
청중
관리자가 GCP 워크로드 ID를 설정할 때 GCP에 생성한
AUDIENCE
값은 다음 형식의 미리 포맷된 URL이어야 합니다.//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SERVICE_ACCOUNT_EMAIL
SERVICE_ACCOUNT_EMAIL
값은 Operator 작업 중에 가장되는 GCP 서비스 계정 이메일입니다. 예:<service_account_name>@<project_id>.iam.gserviceaccount.com
<service_account_name>@<project_id>.iam.gserviceaccount.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
웹 콘솔의 Install Operator 페이지를 통해 클러스터 관리자는 설치 시 이 정보를 제공할 수 있습니다. 그런 다음 이 정보는 Operator Pod의 환경 변수로 Subscription
객체에 전파됩니다.
5.1.4.1. GCP 워크로드 ID를 사용하여 운영자가 CCO 기반 워크플로를 지원하도록 지원 링크 복사링크가 클립보드에 복사되었습니다!
프로젝트를 Operator Lifecycle Manager(OLM)에서 실행하도록 설계하는 Operator 작성자는 프로젝트를 사용자 지정하여 Cloud Credential Operator(CCO)를 지원함으로써 Operator가 OpenShift Container Platform 클러스터에서 Google Cloud Platform 워크로드 ID에 대해 인증하도록 할 수 있습니다.
이 방법을 사용하면 운영자는 CredentialsRequest
객체를 생성하고 결과 Secret
객체를 읽기 위한 RBAC 권한이 필요하며 이에 대한 책임이 있습니다.
기본적으로 Operator 배포와 관련된 Pod는 serviceAccountToken
볼륨을 마운트하여 서비스 계정 토큰을 결과 Secret
객체에서 참조할 수 있도록 합니다.
필수 조건
- OpenShift 컨테이너 플랫폼 4.17 이상
- GCP 워크로드 ID/페더레이션 ID 모드의 클러스터
- OLM 기반 운영자 프로젝트
프로세스
Operator 프로젝트의
ClusterServiceVersion
(CSV) 객체를 업데이트하세요.CSV에서 운영자 배포에 다음의
volumeMounts
및volumes
필드가 있는지 확인하여 운영자가 웹 ID로 역할을 수행할 수 있도록 합니다.예 5.12. 예제
volumeMounts
및volumes
필드Copy to Clipboard Copied! Toggle word wrap Toggle overflow 운영자가
CredentialsRequests
객체를 생성할 수 있는 RBAC 권한이 있는지 확인하세요.예 5.13.
clusterPermissions
목록 예시Copy to Clipboard Copied! Toggle word wrap Toggle overflow GCP 워크로드 ID를 사용하여 CCO 기반 워크플로의 이 방법에 대한 지원을 주장하려면 다음 주석을 추가하세요.
# ... metadata: annotations: features.operators.openshift.io/token-auth-gcp: "true"
# ... metadata: annotations: features.operators.openshift.io/token-auth-gcp: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator 프로젝트 코드를 업데이트하세요.
구독 구성에서 포드에 설정된 환경 변수에서
Audience
및serviceAccountEmail
값을 가져옵니다.// Get ENV var audience := os.Getenv("AUDIENCE") serviceAccountEmail := os.Getenv("SERVICE_ACCOUNT_EMAIL") gcpIdentityTokenFile := "/var/run/secrets/openshift/serviceaccount/token"
// Get ENV var audience := os.Getenv("AUDIENCE") serviceAccountEmail := os.Getenv("SERVICE_ACCOUNT_EMAIL") gcpIdentityTokenFile := "/var/run/secrets/openshift/serviceaccount/token"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 패치 및 적용할
CredentialsRequest
개체가 준비되었는지 확인하세요.참고현재 Operator 번들에
CredentialsRequest
객체를 추가하는 것은 지원되지 않습니다.자격 증명 요청에 GCP 워크로드 ID 변수를 추가하고 운영자 초기화 중에 적용합니다.
예 5.14. Operator 초기화 중
CredentialsRequest
객체 적용 예제Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예에서 보듯이, Operator가 CCO에서
Secret
객체가 나타날 때까지 기다릴 수 있는지 확인하세요. 이 객체는 Operator에서 조정 중인 다른 항목과 함께 호출됩니다.예 5.15.
Secret
객체를 기다리는 예제Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
시간 초과
값은 CCO가 추가된CredentialsRequest
객체를 얼마나 빨리 감지하고Secret
객체를 생성하는지에 대한 추정치에 따라 결정됩니다. 운영자가 아직 클라우드 리소스에 액세스하지 못하는 이유가 무엇인지 궁금해하는 클러스터 관리자를 위해 시간을 줄이거나 맞춤형 피드백을 만드는 것을 고려해 볼 수 있습니다.
비밀에서
service_account.json
필드를 읽고 이를 사용하여 GCP 클라이언트를 인증합니다.service_account_json := secret.StringData["service_account.json"]
service_account_json := secret.StringData["service_account.json"]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow