워크로드 아이덴티티 제휴

이 문서에서는 워크로드 아이덴티티 제휴에 대해 간략하게 설명합니다. 워크로드 아이덴티티 제휴를 사용하면 서비스 계정 키 대신 제휴 ID를 사용하여 온프레미스 또는 멀티 클라우드 워크로드에 Google Cloud 리소스에 대한 액세스 권한을 제공할 수 있습니다.

Amazon Web Services(AWS) 및 Azure, 온프레미스 Active Directory, GitHub 및 GitLab과 같은 배포 서비스, OpenID Connect(OIDC) 또는 보안 보장 마크업 언어(SAML) V2.0을 지원하는 ID 공급업체(IdP)에서 실행되는 워크로드에 워크로드 아이덴티티 제휴를 사용할 수 있습니다.

워크로드 아이덴티티 제휴를 사용해야 하는 이유

일반적으로 Google Cloud 외부에서 실행되는 애플리케이션이 Google Cloud 리소스에 액세스하려면 서비스 계정 키를 사용할 수 있습니다. 그러나 서비스 계정 키는 강력한 사용자 인증 정보이며 제대로 관리하지 않을 경우 보안상 위험할 수 있습니다. 워크로드 아이덴티티 제휴를 사용하면 서비스 계정 키와 관련된 유지보수 및 보안 부담이 사라집니다.

워크로드 아이덴티티 제휴를 사용하면 Identity and Access Management(IAM)를 사용해 Google Cloud 리소스에 대한 직접 액세스 권한인 IAM 역할을 외부 ID에 부여할 수 있습니다. 서비스 계정 가장을 통해 액세스 권한을 부여할 수도 있습니다.

워크로드 아이덴티티 풀

워크로드 아이덴티티 풀은 외부 ID를 관리할 수 있는 항목입니다.

일반적으로 개발, 스테이징, 프로덕션 환경과 같은 Google Cloud 리소스에 액세스해야 하는 Google Cloud 이외의 환경마다 새로운 풀을 만드는 것이 좋습니다.

워크로드 아이덴티티 풀 공급업체

워크로드 아이덴티티 풀 공급업체는 다음을 포함하여 Google Cloud와 IdP 사이의 관계를 기술하는 항목입니다.

  • AWS
  • Azure AD
  • GitHub
  • GitLab
  • Kubernetes 클러스터
  • Okta
  • 온프레미스 Active Directory Federation Services(AD FS)
  • Terraform

워크로드 아이덴티티 제휴는 OAuth 2.0 토큰 교환 사양을 따릅니다. IdP의 사용자 인증 정보를 보안 토큰 서비스에 제공하면, 보안 토큰 서비스는 사용자 인증 정보에서 ID를 확인한 후에 대가로 제휴 토큰을 반환합니다.

로컬 JWK를 사용하는 OIDC 공급업체

공개 OIDC 엔드포인트가 없는 워크로드를 제휴하려면 OIDC JSON 웹 키 세트(JWKS)를 풀에 직접 업로드하면 됩니다. Terraform 또는 GitHub Enterprise가 자체 환경에서 호스팅되거나 공개 URL을 노출하지 않도록 하는 규제 요구사항이 있는 경우에 일반적입니다. 자세한 내용은 OIDC JWK 관리(선택사항)를 참조하세요.

속성 매핑

외부 IdP에서 발급된 토큰에는 하나 이상의 속성이 포함됩니다. 일부 IdP는 이러한 속성을 클레임이라고 부릅니다.

또한 Google 보안 토큰 서비스 토큰에는 다음 표에 나열된 하나 이상의 속성이 포함됩니다.

속성 설명
google.subject 필수. 사용자의 고유 식별자입니다. 이 속성은 IAM principal:// 역할 바인딩에 사용되며 Cloud Logging 로그에 표시됩니다. 값은 고유해야 하며 127자를 초과할 수 없습니다.
google.groups 선택사항입니다. ID가 속하는 그룹 집합입니다. 이 속성은 IAM principalSet:// 역할 바인딩에서 그룹의 모든 구성원에게 액세스 권한을 부여하는 데 사용됩니다.
attribute.NAME 선택사항입니다. 최대 50개의 커스텀 속성을 정의하고 IAM principalSet:// 역할 바인딩에서 이러한 속성을 사용하여 특정 속성이 있는 모든 ID에 액세스 권한을 부여할 수 있습니다.

속성 매핑은 외부 토큰에서 Google 보안 토큰 서비스 토큰 속성의 값을 추출하는 방법을 정의합니다. 각 Google 보안 토큰 서비스 토큰 속성에 대해 다음과 같은 형식으로 속성 매핑을 정의할 수 있습니다.

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

다음을 바꿉니다.

  • TARGET_ATTRIBUTE: Google 보안 토큰 서비스 토큰의 속성
  • SOURCE_EXPRESSION: 외부 IdP에서 발급한 토큰에서 하나 이상의 속성을 변환하는 Common Expression Language(CEL) 표현식

다음 목록은 속성 매핑 예시를 제공합니다.

  • 어설션 속성 subgoogle.subject에 할당합니다.

    google.subject=assertion.sub
    
  • 여러 어설션 속성을 연결합니다.

    google.subject="myprovider::" + assertion.aud + "::" + assertion.sub
    
  • GUID 값 어설션 속성 workload_id를 이름에 매핑하고 결과를 attribute.my_display_name이라는 커스텀 속성에 할당합니다.

    attribute.my_display_name={
      "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
      "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
    }[assertion.workload_id]
    
  • ID의 Amazon 리소스 이름(ARN)에 따라 CEL 논리 연산자 및 함수를 사용하여 attribute.environment라는 커스텀 속성을 prod 또는 test로 설정합니다.

    attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"
    
  • extract 함수를 사용하여 가정된 역할의 이름(또는 역할이 가정되지 않은 경우 ID의 ARN)과 함께 커스텀 속성 aws_role을 입력할 수 있습니다.

    attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn
    
  • split 함수는 제공된 구분 기호 값에서 문자열을 분할합니다. 예를 들어 @에서 값을 분할하고 첫 번째 문자열을 사용하여 이메일 주소 속성에서 username 속성을 추출하려면 다음 속성 매핑을 사용합니다.

    attribute.username=assertion.email.split("@")[0]
    

  • join 함수는 제공된 구분 기호 값으로 문자열 목록을 조인합니다. 예를 들어 문자열 목록을 구분 기호 .로 연결하여 커스텀 속성 department를 채우려면 다음 속성 매핑을 사용합니다.

    attribute.department=assertion.department.join(".")
    

AWS의 경우 Google에서는 가장 일반적인 시나리오에 적용되는 기본 매핑을 제공합니다. 사용자는 커스텀 매핑을 제공할 수도 있습니다.

OIDC 공급업체의 경우 사용자는 매핑을 제공합니다. 매핑을 구성하려면 공급업체의 사용자 인증 정보의 속성 목록에 대한 문서를 참조하세요.

자세한 내용은 [attributeMapping field][attribute-mapping-field]에 대한 API 참고 리소스를 참조하세요.

속성 조건

속성 조건은 어설션 속성 및 대상 속성을 확인할 수 있는 CEL 표현식입니다. 어설션 조건이 특정 사용자 인증 정보에 대해 true로 평가되면 해당 사용자 인증 정보가 수락됩니다. 그렇지 않으면 사용자 인증 정보가 거부됩니다.

속성 조건을 사용하여 워크로드 아이덴티티 풀을 통해 인증할 수 있는 ID를 제한할 수 있습니다.

속성 조건은 다음과 같은 시나리오에서 유용합니다.

  • 워크로드가 일반 대중이 이용할 수 있는 IdP를 사용하면 선택한 ID만 워크로드 아이덴티티 풀에 액세스하도록 액세스를 제한할 수 있습니다.

  • 여러 클라우드 플랫폼에서 IdP를 사용하는 경우 다른 플랫폼에서 사용하기 위한 사용자 인증 정보가 Google Cloud에서 사용되는 것을 방지할 수 있으며 그 반대의 경우도 마찬가지입니다. 이는 혼동된 대리인 문제를 피하는 데 도움이 됩니다.

워크로드 아이덴티티 풀 공급업체의 속성 조건은 IdP에서 발급한 사용자 인증 정보를 나타내는 지도를 표현하는 assertion 키워드를 사용할 수 있습니다. 점 표기법을 사용하여 지도의 값에 액세스할 수 있습니다. 예를 들어 AWS 사용자 인증 정보는 assertion.arn으로 액세스할 수 있는 arn 값을 포함합니다. 또한 해당 속성 조건은 공급업체의 속성 매핑에 정의된 모든 속성을 사용할 수 있습니다.

다음 예시에서는 특정 AWS 역할이 있는 ID의 요청만 허용합니다.

attribute.aws_role == "ROLE_MAPPING"

자세한 내용은 attributeCondition 필드의 API 참고 리소스를 참조하세요.

액세스 관리

토큰 교환 흐름은 제휴 액세스 토큰을 반환합니다. 이 제휴 액세스 토큰을 사용하면 주 구성원 ID 대신 워크로드에 Google Cloud 리소스에 대한 액세스 권한을 부여하고 단기 OAuth 2.0 액세스 토큰을 가져올 수 있습니다.

이 액세스 토큰을 사용하여 IAM 액세스 권한을 제공할 수 있습니다.

워크로드 아이덴티티 제휴를 사용하여 Google Cloud 리소스에 대한 액세스 권한을 제공하는 것이 좋습니다. 대부분의 Google Cloud API는 워크로드 아이덴티티 제휴를 지원하지만 일부 API에는 제한사항이 있습니다. 대신 서비스 계정 가장을 사용하면 됩니다.

단기 액세스 토큰을 사용하면 리소스 또는 서비스 계정이 액세스할 수 있는 모든 Google Cloud API를 호출할 수 있습니다.

직접 리소스 액세스

직접 리소스 액세스를 사용하면 리소스별 역할을 사용하여 외부 ID에 직접 Google Cloud 리소스에 대한 액세스 권한을 부여할 수 있습니다.

대안: 서비스 계정 가장

직접 리소스 액세스를 제공하는 대신 서비스 계정 가장을 사용할 수 있습니다.

서비스 계정에 워크로드 아이덴티티 사용자 역할(roles/iam.workloadIdentityUser)을 부여해야 합니다.

주 구성원 범위 및 보안

주 구성원 유형을 사용하여 주 구성원 또는 주 구성원 하위 집합에 액세스 권한을 부여합니다.

주 구성원 유형

다음 표에서는 주 구성원을 개인 및 ID 그룹으로 정의하는 방법을 설명합니다.

ID 식별자 형식
단일 ID principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
그룹의 모든 ID principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP_ID
특정 속성값의 모든 ID principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE

다음 단계