정책 및 역할 바인딩에서 'withcond' 문제해결

허용 정책에서 뒤에 해시 값이 오는 문자열 withcond가 포함된 역할 이름이 표시될 수 있습니다. 예를 들어 roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8과 같은 역할 이름이 표시될 수 있습니다.

이 페이지에서는 허용 정책에서 문자열 withcond가 표시되는 시기와 이유를 설명합니다. 또한 이 문자열이 표시되는 경우 수행해야 하는 작업도 권장합니다.

정책 버전 및 조건부 역할 binding

정책은 여러 가지 다른 형태로 표현될 수 있습니다. 각 양식은 허용 정책 버전이라고 합니다.

버전 1을 사용하는 허용 정책에서 일부 역할 binding은 그 뒤에 해시 값이 오는 문자열 withcond을 역할 이름에 포함할 수 있습니다.

{
  "bindings": [
    {
      "members": [
        "user:dana@example.com"
      ],
      "role": "roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

이 형식은 역할 binding이 조건부임을 나타냅니다. 즉, 특정 조건이 충족되는 경우에만 역할이 부여됩니다.

버전 1 허용 정책에는 이러한 조건이 표시되지 않습니다. withcond 문자열과 해시 값이 표시되면 역할 binding에 표시되지 않는 조건이 포함됩니다.

솔루션: 정책 버전 3 지정

조건을 포함하여 전체 허용 정책을 보고 업데이트할 수 있도록 하려면 허용 정책을 가져오거나 설정할 때 항상 3 버전을 지정해야 합니다. 버전 3을 지정하려면 다음 섹션의 작업을 완료하세요.

gcloud 도구 업데이트

Google Cloud CLI를 사용하는 경우 gcloud version을 실행해서 해당 버전 번호를 확인합니다. 출력에는 Google Cloud CLI 279.0.0과 유사한 문자열이 포함됩니다.

버전 번호가 263.0.0보다 낮은 경우 gcloud components update를 실행하여 gcloud CLI를 업데이트합니다. 버전 263.0.0 이상에서 gcloud CLI는 조건을 지원하는 허용 정책 버전을 자동으로 지정합니다.

클라이언트 라이브러리 업데이트

애플리케이션이 클라이언트 라이브러리를 사용하는 경우 다음 단계를 따르세요.

  1. 클라이언트 라이브러리의 이름과 버전 번호를 찾은 다음 허용 정책 버전을 지원하는 클라이언트 라이브러리 목록을 확인합니다.

    • 클라이언트 라이브러리의 최신 버전을 이미 사용하고 있으며 허용 정책 버전을 지원하는 경우 클라이언트 라이브러리를 업데이트할 필요가 없습니다. 다음 단계로 넘어갑니다.

    • 이전 버전의 클라이언트 라이브러리를 사용하고 최신 버전이 허용 정책 버전을 지원하는 경우 클라이언트 라이브러리를 최신 버전으로 업데이트합니다.

    • 허용 정책 버전을 지원하지 않는 클라이언트 라이브러리를 사용하는 경우 허용 정책 버전을 지원하는 다른 클라이언트 라이브러리를 애플리케이션에 추가할 수 있습니다. 허용 정책을 이용하려면 해당 클라이언트 라이브러리를 사용합니다. 또는 IAM REST API를 직접 사용할 수 있습니다.

  2. 허용 정책을 가져오고 설정하는 애플리케이션의 코드를 업데이트합니다.

REST API 호출 업데이트

애플리케이션이 IAM REST API를 직접 사용하는 경우 허용 정책을 가져오고 설정하는 모든 코드를 업데이트합니다.

정책 관리 도구 업데이트

허용 정책의 로컬 사본을 보관하는 경우(예: 버전 제어 시스템에 저장하여 코드로 취급하는 경우) 사용하는 모든 도구가 다음 기준을 충족하는지 확인합니다.

  • 허용 정책을 가져오거나 설정하기 위한 모든 요청은 3 버전을 지정합니다.
  • 허용 정책을 설정하기 위한 모든 요청은 요청에 etag 필드가 포함됩니다.

도구가 이러한 기준을 충족하지 않으면 도구의 업데이트된 버전이 있는지 확인합니다.

또한 조건이 없는 중복 역할 부여를 추가하는 대신, 관리 도구에서 조건부 역할 부여를 유지해야 합니다. 예를 들어 다음 시나리오를 고려해 보세요.

  1. 폴더 my-folder에서 사용자 vikram@example.com에게 서비스 계정 만들기 역할(roles/iam.serviceAccountCreator)을 부여합니다. 폴더의 허용 정책은 다음 예시와 비슷합니다.

    {
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BuFmmMhCsNY=",
  "version": 1
}

  2. 도구를 사용하여 허용 정책을 검색하고 버전 제어 시스템에 저장합니다.

  3. 조건을 추가하면 vikram@example.com은 독일의 베를린 날짜 및 시간을 기준으로 일반 업무 시간에만 서비스 계정을 만들 수 있습니다. 업데이트된 허용 정책은 다음 예시와 비슷합니다.

    {
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator",
      "condition": {
        "title": "work_week_only",
        "expression": "request.time.getDayOfWeek('Europe/Berlin') >= 1 && request.time.getDayOfWeek('Europe/Berlin') <= 5"
      }
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 3
}

  4. 도구를 사용하여 업데이트된 허용 정책을 검색합니다. 이 도구는 허용 정책을 요청할 때 허용 정책 버전을 지정하지 않으므로 수정된 역할 이름의 버전 1 허용 정책을 받습니다. 

    {
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 1
}

이 시점에서 관리 도구는 역할 roles/iam.serviceAccountCreator에 대한 vikram@example.com의 binding이 사라지고 허용 정책에 대한 기존 역할 binding을 복원해야 한다고 결정할 수 있습니다.

조건 없는 추가 역할 binding은 피하세요.

{
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    },
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BwWd3HjhKxE=",
  "version": 1
}

이 변경사항이 잘못되었습니다. 요일에 관계없이 roles/iam.serviceAccountCreator 역할을 vikram@example.com에 부여합니다. 따라서 첫 번째 역할 binding의 조건은 영향을 미치지 않습니다.

관리 도구에서 이러한 유형의 변경을 시도하는 경우 변경사항을 승인하지 마세요. 대신 요청에서 버전 3을 지정하도록 관리 도구를 업데이트해야 합니다.

다음 단계