제품 또는 서비스에서 고객의 Google Cloud 리소스 액세스 허용

이 문서에서는 고객이 서비스 계정 키를 사용하지 않고도 제품을 사용하여 Google Cloud의 리소스에 액세스할 수 있도록 하기 위해 따를 수 있는 요구사항과 권장사항을 설명합니다.

고객이 데이터 또는 리소스를 분석하거나 관리할 수 있게 해주는 제품을 제공하거나 서비스를 운영하는 경우 고객은 Google 클라우드 환경의 데이터 또는 기타 리소스에 액세스해야 할 수 있습니다. 이러한 제품과 서비스의 예시는 다음과 같습니다.

  • 데이터 분석 제품: 고객은 이러한 제품을 사용하여 BigQuery에서 데이터를 분석할 수 있습니다.
  • CI/CD 제품 및 서비스: 고객은 이러한 서비스를 사용하여 인프라 및 애플리케이션을 Google Cloud 프로젝트에 배포할 수 있습니다.
  • 로보틱 처리 자동화(RPA): 고객이 Google Cloud에서 프로젝트 만들기, 액세스 관리, 관리 작업 자동화와 같은 워크플로에 RPA를 사용할 수 있습니다.

온프레미스 또는 software-as-a-service(SaaS) 제품을 Google Cloud에 인증하기 위해 고객은 일반적으로 서비스 계정 키를 사용하고 있지만 이러한 키는 안전하게 관리하고 저장하기가 어려울 수 있습니다.

온프레미스 또는 SaaS 제품의 공급업체는 고객이 워크로드 아이덴티티 제휴를 통해 Google Cloud 리소스에 액세스하도록 허용하여 Google Cloud 리소스를 보호할 수 있습니다. 고객이 이미 워크로드 아이덴티티 제휴를 사용하도록 허용하는 서비스의 예시로는 Terraform Cloud, GitHub, GitLab이 있습니다.

이 문서에서는 워크로드 아이덴티티 제휴를 지원하도록 제품을 확장하는 방법과 따를 수 있는 권장사항을 설명합니다. 이 문서에서는 사용자가 워크로드 아이덴티티 제휴OpenID Connect에 익숙하다고 가정합니다.

아키텍처

워크로드 아이덴티티 제휴의 목적은 고객이 제품 또는 서비스를 Google Cloud 환경과 제휴할 수 있도록 하여 서비스 계정 키가 필요하지 않도록 하는 데 있습니다. 그러면 고객이 제품 또는 서비스에서 어설션한 ID를 사용하여 Google Cloud 리소스에 액세스할 수 있습니다.

고객이 워크로드 아이덴티티 제휴를 사용할 수 있도록 하려면 제품 또는 서비스가 OpenID Connect의 하위 집합을 구현해야 합니다. 특히 워크로드가 다음 기준을 충족하는 ID 토큰을 가져오도록 허용해야 합니다.

  • 토큰은 제품 또는 플랫폼 내의 워크로드를 식별합니다.
  • 토큰은 제품 또는 플랫폼의 인스턴스, 테넌트 또는 설치를 식별합니다.
  • 토큰에는 워크로드 아이덴티티 제휴가 토큰의 신뢰성을 확인하는 데 사용할 수 있는 암호화 서명이 포함되어 있습니다.

요구사항

워크로드 아이덴티티 제휴를 지원하려면 제품 또는 서비스가 다음 요구사항을 충족하는지 확인해야 합니다.

  1. 워크로드가 유효한 ID 토큰에 액세스할 수 있습니다.

    수명 주기 동안 워크로드는 워크로드 아이덴티티를 어설션하고 OpenID Connect 1.0에서 정의된 요구사항을 준수하는 ID 토큰에 액세스할 수 있어야 합니다.

    ID 토큰의 수명은 제한적이므로 ID 토큰이 워크로드보다 오래 지속되거나 워크로드가 주기적으로 새 ID 토큰을 얻을 수 있는지 확인해야 합니다.

  2. ID 토큰은 워크로드를 고유하게 식별합니다.

    ID 토큰에는 워크로드를 고유하게 식별하는 하나 이상의 클레임이 포함되어야 합니다. 워크로드 식별자는 변경할 수 없어야 합니다.

    멀티테넌시를 지원하는 제품 또는 서비스의 경우 토큰에 테넌트를 고유하게 식별하는 클레임이 하나 이상 포함되어야 합니다. 테넌트 식별자도 변경할 수 없어야 합니다.

  3. ID 토큰이 서명되었지만 암호화되지 않습니다.

  4. OpenID 제공업체 메타데이터는 공개적으로 액세스할 수 있으며 ID 토큰에서 검색할 수 있습니다.

    공개적으로 액세스 가능한 엔드포인트에서 OpenID 발급기관 검색 프로토콜을 사용해 검색할 수 있는 OpenID 제공업체 구성 문서를 제공해야 합니다. 예를 들어 ID 토큰에 https://service.example.com/v1/ 값이 있는 iss 클레임이 포함된 경우 https://service.example.com/v1/.well-known/openid-configuration에 OpenID 제공업체 구성 문서를 제공해야 하고 모든 IP 주소에서 인터넷을 통해 엔드포인트에 공개적으로 액세스할 수 있어야 합니다.

  5. 서명 키는 공개적으로 액세스할 수 있으며 OpenID 제공업체 메타데이터에서 검색할 수 있습니다.

    공개적으로 액세스할 수 있는 엔드포인트에 OpenID 제공업체 메타데이터의 jwks_uri 필드에서 검색할 수 있는 JSON 웹 키 세트(JWKS) 문서를 제공해야 합니다.

권장사항

워크로드 아이덴티티 제휴를 지원하도록 제품 또는 서비스를 확장할 때는 다음 권장사항을 고려하세요.

ID와 액세스 토큰 구별

워크로드 아이덴티티 제휴의 컨텍스트에서 ID 토큰의 목적은 워크로드 아이덴티티를 어설션하는 것입니다. 토큰에는 워크로드를 식별하고 다른 워크로드와 구별하기 위해 워크로드 아이덴티티 제휴에 대한 충분한 정보가 포함되어야 합니다.

ID 토큰과 달리 액세스 토큰은 일반적으로 다른 용도로 사용됩니다. 액세스 결정을 내리기 위해 사용되며, 워크로드에 포함된 권한 또는 액세스가 허용되는 API에 대한 정보를 포함할 수 있습니다.

워크로드가 제품의 API를 호출하도록 허용하는 등의 목적으로 현재 제품 또는 서비스가 액세스 토큰을 사용하는 경우 이러한 액세스 토큰은 워크로드 아이덴티티 제휴에 적합하지 않을 수 있습니다. 액세스 토큰을 ID 토큰으로 용도를 변경하는 대신 ID 토큰의 정의와 일치하는 두 번째 유형의 토큰을 도입하고 워크로드에서 워크로드 아이덴티티 제휴에 ID 토큰을 사용하는 것이 좋습니다.

클라이언트 라이브러리와 호환되는 방식으로 ID 토큰 노출

Google Cloud 클라이언트 라이브러리는 다음을 포함한 여러 소스에서 ID 토큰을 자동으로 가져올 수 있습니다.

  • HTTP 엔드포인트(URL 소스 사용자 인증 정보)
  • 로컬 파일(파일 소스 사용자 인증 정보)

다른 소스에서 ID 토큰을 얻으려면 고객이 코드를 수정하거나 추가 도구 또는 라이브러리를 배포해야 할 수 있습니다. 클라이언트 라이브러리와 호환되는 방식으로 ID 토큰을 노출하면 이러한 추가 복잡성을 피하고 고객이 워크로드 아이덴티티 제휴를 더 쉽게 채택할 수 있습니다.

테넌트별 발급기관 URL 사용

워크로드의 ID 토큰에 포함된 클레임은 제품 또는 서비스의 특정 인스턴스 내에서 고유할 수 있지만 제품 또는 서비스의 여러 인스턴스 간에 고유하지는 않을 수 있습니다. 예를 들어 두 고객이 제품 또는 서비스를 사용하여 워크로드를 배포하고 실수로 해당 워크로드에 동일한 이름과 ID를 할당할 수 있습니다.

워크로드 아이덴티티 제휴는 ID 토큰의 발급기관 URL(iss)을 확인하고 워크로드 아이덴티티 풀당 단일 발급기관의 토큰만 허용하여 가능한 고유성 부족을 보완하려고 시도합니다.

제품 또는 서비스가 멀티테넌시를 지원하면 여러 고객이 제품 또는 서비스의 단일 인스턴스를 공유할 수 있으며 워크로드의 ID 토큰이 동일한 발급기관 URL을 사용할 수 있습니다. 여러 테넌트에서 동일한 발급기관 URL을 사용하면 고객이 스푸핑 공격에 노출될 수 있습니다. 예를 들어 악의적인 행위자가 자체 테넌트에 워크로드를 만들어 공격 대상 테넌트의 워크로드와 동일한 ID 또는 이름을 할당하고 워크로드의 ID 토큰을 사용하여 공격 대상 워크로드의 ID를 스푸핑할 수 있습니다.

스푸핑 공격을 방지하려면 여러 테넌트에서 동일한 발급기관 URL을 사용하지 않고 발급기관 URL에 고유한 테넌트 ID를 삽입합니다(예: https://saas.example.com/tenant-123/).

사용자가 ID 토큰 대상을 지정하도록 허용

고객의 워크로드 일부가 Google Cloud와 다른 타사 서비스에 액세스해야 할 수 있습니다. 고객이 제품 또는 서비스를 여러 신뢰 당사자와 제휴하기로 한 경우 워크로드의 ID 토큰이 의도치 않게 또는 악의적으로 잘못된 신뢰 당사자에게 사용되는 상황을 겪을 수 있습니다. 예를 들어 악의적인 행위자가 워크로드를 속여 타사 서비스용 ID 토큰을 노출하도록 유도한 다음 워크로드 아이덴티티 제휴에 해당 ID 토큰을 사용할 수 있습니다.

고객이 혼동된 대리인 공격을 당하지 않도록 하려면 ID 토큰에 정적 대상(aud 클레임)을 사용하지 않는 것이 좋습니다. 대신 워크로드가 ID 토큰을 가져올 때 대상을 지정하도록 허용하며, 선택적으로 워크로드가 요청할 수 있는 대상의 허용 목록을 유지 관리할 수 있습니다.

기본적으로 워크로드 아이덴티티 제휴는 ID 토큰의 대상이 URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID와 일치할 것으로 예상합니다. 워크로드가 URL을 ID 토큰의 대상으로 사용할 수 있고 대상의 최대 길이가 최대 180자(영문 기준)여야 합니다.

ID 토큰 클레임에 변경할 수 없는 재사용 불가능한 식별자 사용

고객이 워크로드 중 하나에 Google Cloud 리소스에 대한 액세스 권한을 부여하려는 경우 제목, 그룹 또는 커스텀 속성별로 워크로드 아이덴티티를 참조하는 IAM 바인딩을 만들어야 합니다. 워크로드 ID의 제목, 그룹, 커스텀 속성은 워크로드의 ID 토큰의 클레임에서 파생됩니다.

고객이 변경 가능한 클레임을 참조하는 IAM 바인딩을 만드는 경우 클레임 값이 변경될 때 워크로드에 액세스할 수 없게 될 수 있습니다. 예를 들어 고객이 워크로드 이름을 참조하는 IAM 바인딩을 만들 수 있습니다. 이후에 워크로드의 이름을 변경하면 IAM 바인딩이 더 이상 적용되지 않을 수 있습니다.

더 나쁜 경우에는 악의적인 행위자가 고의로 워크로드의 이름을 변경하거나 워크로드의 환경을 수정하여 다른 워크로드의 ID를 스푸핑하여 다른 리소스에 대한 무단 액세스를 시도할 수 있습니다.

고객이 이러한 스푸핑 문제를 방지할 수 있도록 ID 토큰에 변경할 수 없고 재사용할 수 없는 식별자가 포함되어 있는지 확인합니다.

ID 토큰에 컨텍스트 정보 포함

워크로드에 Google Cloud 리소스에 대한 비조건부 액세스 권한을 부여하는 대신 워크로드가 특정 추가 기준이 충족될 때만 Google 사용자 인증 정보를 가져올 수 있도록 액세스를 제한할 수 있습니다.

고객이 이러한 제한을 구성할 수 있도록 하려면 컨텍스트 정보가 포함된 ID 토큰에 추가 클레임을 포함합니다. 컨텍스트 정보의 예시는 다음과 같습니다.

  • 워크로드를 소유하거나 시작한 사용자에 대한 정보
  • 워크로드가 시작된 이유 및 방법
  • 현재 워크로드에서 처리 중인 요청

고객은 이러한 클레임을 사용하여 속성 조건 또는 주 구성원 식별자를 구성할 수 있습니다.

ID 토큰 수명을 60분으로 제한

ID 토큰의 수명은 exp 클레임에 의해 제한됩니다. 워크로드가 ID 토큰을 사용하여 토큰 교환을 수행하면 워크로드 아이덴티티 제휴가 ID 토큰의 exp 클레임을 검증하고 입력 토큰 동안(최대 1시간) 유효한 STS 토큰을 발급합니다.

1시간 이상 유효한 ID 토큰을 사용해도 워크로드 아이덴티티 제휴에는 영향을 미치지 않지만 ID 토큰이 실수로 유출되는 경우 위험이 증가할 수 있습니다. 1시간 미만의 수명을 사용하면 이러한 위험을 줄이는 데 도움이 될 수 있지만 토큰이 자주 교환되고 성능이 저하될 수 있습니다.

다음 단계