이 페이지에서는 주 구성원 또는 리소스가 Identity and Access Management(IAM) 서비스 계정을 가장하거나 IAM 서비스 계정으로 작동하도록 허용하는 방법을 설명합니다. 또한 제공된 IAM 서비스 계정을 가장할 수 있는 주 구성원을 확인하는 방법도 설명합니다.
시작하기 전에
API IAM and Resource Manager 사용 설정
IAM에서 서비스 계정 작동 방법을 이해해야 합니다.
주 구성원의 서비스 계정 가장 허용
주 구성원이 서비스 계정을 가장하도록 허용하는 사전 정의된 역할이 몇 가지 있습니다.
서비스 계정 사용자(
roles/iam.serviceAccountUser
): 주 구성원이 서비스 계정에서 액세스할 수 있는 모든 리소스에 간접적으로 액세스할 수 있게 해주는iam.serviceAccounts.actAs
권한을 포함합니다. 예를 들어 주 구성원에게 서비스 계정에 대한 서비스 계정 사용자 역할이 있고 서비스 계정에 프로젝트에 대한 Cloud SQL 관리자 역할(roles/cloudsql.admin
)이 있으면 주 구성원이 서비스 계정을 가장하여 Cloud SQL 인스턴스를 만들 수 있습니다.이 역할을 사용하면 이 페이지에 설명된 대로 주 구성원이 리소스에 서비스 계정을 연결할 수 있습니다.
이 역할을 사용하면 주 구성원이 서비스 계정의 단기 사용자 인증 정보를 만들거나 Google Cloud CLI에
--impersonate-service-account
플래그를 사용할 수 없습니다. 이러한 태스크를 완료하려면 서비스 계정 토큰 생성자 역할도 필요합니다.서비스 계정 토큰 생성자(
roles/iam.serviceAccountTokenCreator
): 주 구성원이 서비스 계정을 가장하여 Google API로 인증하는 데 사용할 수 있는 OAuth 2.0 액세스 토큰을 만들 수 있습니다. 또한 주 구성원은 JSON 웹 토큰(JWT)을 서명하고 바이너리 blob을 서명하여 인증에 사용할 수 있습니다. 자세한 내용은 단기 서비스 계정 사용자 인증 정보 만들기를 참조하세요.워크로드 아이덴티티 사용자(
roles/iam.workloadIdentityUser
): 주 구성원이 GKE 워크로드에서 서비스 계정을 가장하도록 허용합니다.
또는 사전 정의된 역할이나 이러한 역할과 동일한 권한을 갖는 다른 커스텀 역할을 부여할 수 있습니다.
다음 섹션에서는 프로젝트, 폴더, 조직에 이러한 역할을 부여하는 방법과 개별 서비스 계정에 부여하는 방법을 설명합니다. 부여하려는 액세스 권한의 양에 따라 수준을 선택합니다.
- 주 구성원이 프로젝트, 폴더, 조직에 생성된 모든 서비스 계정을 가장하도록 허용하려면 프로젝트, 폴더, 조직에 역할을 부여합니다.
- 주 구성원이 단일 서비스 계정을 가장하도록 허용하려면 서비스 계정에 역할을 부여합니다.
주 구성원이 여러 서비스 계정을 가장하도록 허용
주 구성원이 프로젝트, 폴더, 조직에 생성된 모든 서비스 계정을 가장하도록 허용하려면 프로젝트, 폴더, 조직에 역할을 부여합니다.
Console
Cloud Console에서 IAM 페이지로 이동합니다.
페이지 상단의 프로젝트 선택기에서 역할을 부여하려는 프로젝트, 폴더, 조직을 선택합니다.
추가를 클릭합니다.
주 구성원의 이메일 주소를 입력합니다.
주 구성원이 서비스 계정을 가장하도록 허용하는 역할을 선택합니다. 서비스 계정 가장을 위한 역할 목록을 참조하세요.
저장을 클릭합니다.
gcloud
주 구성원이 서비스 계정을 가장하도록 허용하는 역할을 구성원에게 부여하려면 프로젝트, 폴더, 조직에 대해 허용 정책을 수정합니다.
리소스에 대한 허용 정책을 읽습니다.
gcloud resource get-iam-policy resource-id \ --format=json > policy.json
다음 값을 바꿉니다.
-
resource
: 허용 정책을 설정하려는 리소스 유형. 이 값은projects
,resource-manager folders
,organizations
중 하나여야 합니다. -
resource-id
: 허용 정책을 설정하려는 리소스의 ID입니다.
이 명령어는 리소스의 허용 정책을
policy.json
파일에 저장합니다.허용 정책이 리소스에 이미 설정되어 있으면
policy.json
파일이 다음과 비슷합니다.{ "bindings": [ { "members": [ "user:hollis@example.com" ], "role": "roles/owner" } ], "etag": "BwUqLaVeua8=", "version": 1 }
리소스에 허용 정책이 없으면
policy.json
파일에 기본etag
만 포함됩니다.기존 허용 정책이 없으면 다음 단계에서 JSON을 템플릿으로 사용해서 허용 정책을 만듭니다.
-
적절한 역할을 주 구성원에 부여하도록 허용 정책을 수정합니다. 역할을 부여하려면 다음 중 하나를 수행합니다.
- 역할에 대해 바인딩이 존재하지 않으면 부여하려는 역할 및 이를 부여할 주 구성원을 나타내는
bindings
배열에 객체를 추가합니다. - 역할에 대해 바인딩이 존재하면 기존 주 구성원 목록에 새 주 구성원을 추가합니다. 또한 허용 정책에 조건부 역할 바인딩이 포함된 경우 주 구성원을 추가하기 전 바인딩의 조건이 적절한지 확인합니다.
bindings
배열이 존재하지 않으면 만들 수 있습니다.예시
서비스 계정 사용자 역할(
roles/iam.serviceAccountUser
)을robin@example.com
에 부여하려면 이전 단계에 표시된 예시를 다음과 같이 변경합니다.{ "bindings": [ { "role": "roles/iam.serviceAccountUser", "members": [ "user:robin@example.com" ] }, { "role": "roles/owner", "members": [ "user:hollis@example.com" ] } ], "etag": "BwUqLaVeua8=", "version": 1 }
- 역할에 대해 바인딩이 존재하지 않으면 부여하려는 역할 및 이를 부여할 주 구성원을 나타내는
업데이트된 허용 정책을 작성합니다.
gcloud resource set-iam-policy resource-id \ policy-file
다음 값을 바꿉니다.
-
resource
: 허용 정책을 설정하려는 리소스 유형. 이 값은projects
,resource-manager folders
,organizations
중 하나여야 합니다. -
resource-id
: 허용 정책을 설정하려는 리소스의 ID입니다. policy-file
: 업데이트된 허용 정책이 포함된 파일의 경로입니다.
이 명령어는 업데이트된
etag
값으로 업데이트된 허용 정책을 출력합니다.-
REST
Resource Manager REST API를 사용하여 역할을 부여하려면 프로젝트, 폴더, 조직에 대해 현재 허용 정책을 읽고, 원하는 역할을 부여하도록 허용 정책을 수정하고, 업데이트된 허용 정책을 기록해야 합니다.
리소스에 대한 허용 정책을 읽습니다.
Resource Manager API의 getIamPolicy
메서드는 프로젝트, 폴더, 조직의 허용 정책을 가져옵니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
API_VERSION
: 사용할 API 버전입니다. 프로젝트 및 조직에v1
을 사용합니다. 폴더에는v2
를 사용합니다.RESOURCE_TYPE
: 정책을 관리할 리소스 유형입니다.projects
,folders
또는organizations
값을 사용합니다.RESOURCE_ID
: Google Cloud 프로젝트, 조직, 폴더 ID. 프로젝트 ID는my-project
같은 영숫자 문자열입니다. 폴더 및 조직 ID는123456789012
와 같은 숫자입니다.POLICY_VERSION
: 반환할 정책 버전입니다. 요청에는 정책 버전 3인 최신 정책 버전이 지정되어야 합니다. 자세한 내용은 정책을 가져올 때 정책 버전 지정을 참조하세요.
HTTP 메서드 및 URL:
POST https://cloudresourcemanager.googleapis.com/API_VERSION/RESOURCE_TYPE/RESOURCE_ID:getIamPolicy
JSON 요청 본문:
{ "options": { "requestedPolicyVersion": POLICY_VERSION } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
응답에는 리소스의 허용 정책이 포함됩니다. 예를 들면 다음과 같습니다.
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/owner", "members": [ "user:owner@example.com" ] } ] }
기존 허용 정책이 없는 경우 응답에 기본 etag
만 포함됩니다. 이 응답을 받으면 version
필드를 추가하고 3으로 설정하고 bindings
필드를 빈 배열로 설정합니다.
적절한 역할을 주 구성원에 부여하도록 허용 정책을 수정합니다.
역할을 부여하려면 다음 중 하나를 수행합니다.
- 역할에 대해 바인딩이 존재하지 않으면 부여하려는 역할 및 이를 부여할 주 구성원을 나타내는
bindings
배열에 객체를 추가합니다. - 역할에 대한 바인딩이 존재하면 새 주 구성원을 기존 주 구성원 목록에 추가합니다.
예시:
서비스 계정 사용자 역할(roles/iam.serviceAccountUser
)을 robin@example.com
에 부여하려면 이전 단계에 표시된 예시를 다음과 같이 변경합니다.
{ "version": 1, "etag": "BwUqLaVeua8=", "bindings": [ { "role": "roles/iam.serviceAccountUser", "members": [ "user:robin@example.com" ] }, { "role": "roles/owner", "members": [ "user:owner@example.com" ] } ] }
업데이트된 허용 정책을 작성합니다.
Resource Manager API의 setIamPolicy
메서드는 요청의 정책을 프로젝트, 폴더, 조직의 새 허용 정책으로 설정합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
API_VERSION
: 사용할 API 버전입니다. 프로젝트 및 조직에v1
을 사용합니다. 폴더에는v2
를 사용합니다.RESOURCE_TYPE
: 정책을 관리할 리소스 유형입니다.projects
,folders
또는organizations
값을 사용합니다.RESOURCE_ID
: Google Cloud 프로젝트, 조직, 폴더 ID. 프로젝트 ID는my-project
같은 영숫자 문자열입니다. 폴더 및 조직 ID는123456789012
와 같은 숫자입니다.-
POLICY
: 설정하려는 정책의 JSON 표현입니다. 정책 형식에 대한 자세한 내용은 정책 참조를 확인하세요.예를 들어 이전 단계에 표시된 허용 정책을 설정하려면
POLICY
를 다음으로 바꿉니다.{ "version": 1, "etag": "BwUqLaVeua8=", "bindings": [ { "role": "roles/iam.serviceAccountUser", "members": [ "user:robin@example.com" ] }, { "role": "roles/owner", "members": [ "user:owner@example.com" ] } ] }
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/API_VERSION/RESOURCE_TYPE/RESOURCE_ID:setIamPolicy
JSON 요청 본문:
{ "policy": POLICY }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
응답에는 업데이트된 허용 정책이 포함됩니다.
주 구성원이 단일 서비스 계정을 가장하도록 허용
주 구성원이 단일 서비스 계정을 가장하도록 허용하려면 서비스 계정에 역할을 부여합니다.
Console
Cloud Console에서 서비스 계정 페이지로 이동합니다.
프로젝트를 선택합니다.
주 구성원이 가장하도록 허용할 서비스 계정의 이메일 주소를 클릭합니다.
권한 탭을 클릭합니다.
이 서비스 계정에 대한 액세스 권한이 있는 주 구성원에서
액세스 권한 부여를 클릭합니다.주 구성원의 이메일 주소를 입력합니다.
주 구성원에게 서비스 계정 가장 권한을 부여하는 역할을 선택합니다. 서비스 계정 가장을 위한 역할 목록을 참조하세요.
저장을 클릭하여 주 구성원에 역할을 적용합니다.
여러 서비스 계정에 대해 역할을 부여하려면 각 서비스 계정에 대해 이 단계를 반복합니다.
gcloud
주 구성원이 서비스 계정을 가장하도록 허용하는 역할을 부여하려면 서비스 계정에 대해 허용 정책을 수정합니다.
service-accounts get-iam-policy
명령어를 사용하여 현재 허용 정책을 읽습니다.gcloud iam service-accounts get-iam-policy sa-id \ --format=json > policy.json
다음 값을 바꿉니다.
sa-id
: 서비스 계정의 ID입니다. sa-name@project-id.iam.gserviceaccount.com 형식의 서비스 계정 이메일 주소 또는 서비스 계정의 고유한 숫자 ID일 수 있습니다.
이 명령어는 서비스 계정의 허용 정책을
policy.json
파일에 저장합니다.허용 정책이 서비스 계정에 이미 설정되어 있으면
policy.json
파일이 다음과 비슷합니다.{ "bindings": [ { "members": [ "user:hollis@example.com" ], "role": "roles/iam.serviceAccountAdmin" } ], "etag": "BwUqLaVeua8=", "version": 1 }
서비스 계정에 설정된 허용 정책이 없으면
policy.json
파일에 기본etag
만 포함됩니다.기존 허용 정책이 없으면 다음 단계에서 JSON을 템플릿으로 사용해서 허용 정책을 만듭니다.
텍스트 편집기에서 주 구성원에 적절한 역할을 부여하도록 policy.json 파일에서 binding 배열을 수정합니다. 역할을 부여하려면 다음 중 하나를 수행합니다.
- 역할에 대해 바인딩이 존재하지 않으면 부여하려는 역할 및 이를 부여할 주 구성원을 정의하는
bindings
배열에 새 객체를 추가합니다. - 역할에 대해 바인딩이 존재하면 기존 주 구성원 목록에 새 주 구성원을 추가합니다. 또한 허용 정책에 조건부 역할 바인딩이 포함된 경우 주 구성원을 추가하기 전 바인딩의 조건이 적절한지 확인합니다.
bindings
배열이 존재하지 않으면 만들 수 있습니다.예시
서비스 계정 사용자 역할(
roles/iam.serviceAccountUser
)을robin@example.com
에 부여하려면 이전 단계에 표시된 예시를 다음과 같이 변경합니다.{ "bindings": [ { "role": "roles/iam.serviceAccountUser", "members": [ "user:robin@example.com" ] }, { "role": "roles/iam.serviceAccountAdmin", "members": [ "user:hollis@example.com" ] } ], "etag": "BwUqLaVeua8=", "version": 1 }
- 역할에 대해 바인딩이 존재하지 않으면 부여하려는 역할 및 이를 부여할 주 구성원을 정의하는
service-accounts set-iam-policy
명령어를 사용하여 업데이트된 허용 정책을 작성합니다.gcloud iam service-accounts set-iam-policy sa-id \ policy-file
다음 값을 바꿉니다.
sa-id
: 서비스 계정의 ID입니다. sa-name@project-id.iam.gserviceaccount.com 형식의 서비스 계정 이메일 주소 또는 서비스 계정의 고유한 숫자 ID일 수 있습니다.policy-file
: 업데이트된 허용 정책이 포함된 파일의 경로입니다.
이 명령어는 업데이트된
etag
값으로 업데이트된 허용 정책을 출력합니다.
REST
IAM REST API를 사용하여 역할을 부여하려면 서비스 계정의 현재 허용 정책을 읽고, 원하는 역할을 부여하도록 이를 수정하고, 업데이트된 허용 정책을 기록해야 합니다.
서비스 계정의 허용 정책을 읽습니다.
serviceAccounts.getIamPolicy
메서드는 서비스 계정의 허용 정책을 가져옵니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
PROJECT_ID
: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project
같은 영숫자 문자열입니다.SA_ID
: 서비스 계정의 ID입니다.SA_NAME@PROJECT_ID.iam.gserviceaccount.com
형식의 서비스 계정 이메일 주소이거나 서비스 계정의 고유 숫자 ID일 수 있습니다.POLICY_VERSION
: 반환할 정책 버전입니다. 요청에는 정책 버전 3인 최신 정책 버전이 지정되어야 합니다. 자세한 내용은 정책을 가져올 때 정책 버전 지정을 참조하세요.
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:getIamPolicy
JSON 요청 본문:
{ "options": { "requestedPolicyVersion": POLICY_VERSION } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
응답에는 서비스 계정의 허용 정책이 포함됩니다. 예를 들면 다음과 같습니다.
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] } ] }
기존 허용 정책이 없는 경우 응답에 기본 etag
만 포함됩니다. 이 응답을 받으면 version
필드를 추가하고 3으로 설정하고 bindings
필드를 빈 배열로 설정합니다.
적절한 역할을 주 구성원에 부여하도록 허용 정책을 수정합니다.
텍스트 편집기에서 응답 본문의 binding 배열을 수정하여 주 구성원에 적절한 역할을 부여합니다. 역할을 부여하려면 다음 중 하나를 수행합니다.
- 역할에 대해 바인딩이 존재하지 않으면 부여하려는 역할 및 이를 부여할 주 구성원을 정의하는
bindings
배열에 새 객체를 추가합니다. - 역할에 대한 바인딩이 존재하면 새 주 구성원을 기존 주 구성원 목록에 추가합니다.
예시:
서비스 계정 사용자 역할(roles/iam.serviceAccountUser
)을 robin@example.com
에 부여하려면 이전 단계에 표시된 예시를 다음과 같이 변경합니다.
{ "version": 1, "etag": "BwUqLaVeua8=", "bindings": [ { "role": "roles/iam.serviceAccountUser", "members": [ "user:robin@example.com" ] }, { "role": "roles/iam.serviceAccountAdmin", "members": [ "user:admin@example.com" ] } ] }
업데이트된 허용 정책을 작성합니다.
serviceAccounts.setIamPolicy
메서드는 서비스 계정의 업데이트된 허용 정책을 설정합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
PROJECT_ID
: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project
같은 영숫자 문자열입니다.SA_ID
: 서비스 계정의 ID입니다.SA_NAME@PROJECT_ID.iam.gserviceaccount.com
형식의 서비스 계정 이메일 주소이거나 서비스 계정의 고유 숫자 ID일 수 있습니다.-
POLICY
: 설정하려는 정책의 JSON 표현입니다. 정책 형식에 대한 자세한 내용은 정책 참조를 확인하세요.예를 들어 이전 단계에 표시된 허용 정책을 설정하려면
policy
를 다음으로 바꿉니다.{ "version": 1, "etag": "BwUqLaVeua8=", "bindings": [ { "role": "roles/iam.serviceAccountUser", "members": [ "user:robin@example.com" ] }, { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] } ] }
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:setIamPolicy
JSON 요청 본문:
{ "policy": POLICY }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
응답에는 업데이트된 허용 정책이 포함됩니다.
서비스 계정에 액세스할 수 있는 주 구성원 나열
Cloud Console을 사용하여 서비스 계정에 부여된 역할 또는 프로젝트, 폴더, 조직에 부여된 역할로 인해 서비스 계정에 액세스할 수 있는 모든 주 구성원을 볼 수 있습니다.
Cloud Console에서 서비스 계정 페이지로 이동합니다.
프로젝트를 선택합니다.
주 구성원이 가장하도록 허용할 서비스 계정의 이메일 주소를 클릭합니다.
권한 탭을 클릭합니다. 이 서비스 계정에 대한 액세스 권한이 있는 주 구성원 섹션에는 서비스 계정에 액세스할 수 있는 주 구성원이 나열됩니다.
리소스에 서비스 계정 연결
일부 Google Cloud 리소스의 경우 리소스가 기본 ID로 사용하는 사용자 관리 서비스 계정을 지정할 수 있습니다. 이 프로세스를 서비스 계정을 리소스에 연결하거나 서비스 계정과 리소스를 연결한다고 합니다.
리소스가 다른 Google Cloud 서비스 및 리소스에 액세스해야 할 경우 자체적으로 연결된 서비스 계정을 가장합니다. 예를 들어 Compute Engine 인스턴스에 서비스 계정을 연결하고 인스턴스의 애플리케이션이 Google Cloud API를 호출하기 위해 클라이언트 라이브러리를 사용하는 경우 이러한 애플리케이션은 연결된 서비스 계정을 자동으로 가장합니다.
대부분의 경우 리소스를 만들 때 서비스 계정을 리소스에 연결해야 합니다. 리소스를 만든 후에는 리소스에 연결된 서비스 계정을 변경할 수 없습니다. Compute Engine 인스턴스에는 이 규칙이 적용되지 않습니다. 필요에 따라 인스턴스에 연결된 서비스 계정을 변경할 수 있습니다.
리소스에 서비스 계정을 연결하기 전에 서비스 계정을 구성해야 합니다. 이 프로세스는 서비스 계정과 리소스가 같은 프로젝트에 있는지 아니면 다른 프로젝트에 있는지에 따라 다릅니다. 서비스 계정을 구성한 후에는 리소스를 만들고 해당 리소스에 서비스 계정을 연결할 수 있습니다.
동일한 프로젝트의 리소스 구성
동일한 프로젝트의 다른 리소스에 서비스 계정을 연결하기 전에 다른 주 구성원에게 역할을 부여하는 것처럼 서비스 계정에 역할을 부여하여 적절한 리소스에 액세스할 수 있도록 합니다.
다른 프로젝트의 리소스 구성
경우에 따라 다른 프로젝트에 있는 리소스에 서비스 계정을 연결해야 할 수도 있습니다. 예를 들어 단일 프로젝트의 모든 서비스 계정을 생성하는 경우 서비스 계정 중 하나를 다른 프로젝트의 새 리소스에 연결해야 할 수 있습니다.
다른 프로젝트의 리소스에 서비스 계정을 연결하기 전에 다음을 수행하세요.
- 서비스 계정이 있는 프로젝트에서 이 페이지의 단계에 따라 프로젝트 간 서비스 계정 가장을 사용 설정합니다.
- 리소스를 만들 프로젝트를 식별합니다.
서비스 계정을 연결할 리소스 유형과 해당 유형의 리소스를 소유한 서비스를 확인합니다.
예를 들어 Pub/Sub 구독을 만드는 경우 Pub/Sub는 리소스를 소유한 서비스입니다.
서비스에 대한 서비스 에이전트의 이메일 주소를 찾습니다.
서비스마다 다른 서비스 에이전트가 사용됩니다. 자세한 내용은 서비스 에이전트를 참조하세요.
서비스 에이전트에 서비스 계정 토큰 생성자 역할(
roles/iam.serviceAccountTokenCreator
)을 부여합니다.Console
Cloud Console에서 서비스 계정 페이지로 이동합니다.
리소스에 연결할 서비스 계정을 소유한 프로젝트를 선택합니다.
리소스에 연결할 서비스 계정을 찾고 체크박스를 선택합니다.
권한 탭에서 주 구성원 추가를 클릭합니다.
새 주 구성원 필드에 서비스 에이전트의 이메일 주소를 입력합니다.
역할 선택 드롭다운 목록에서
Service Account Token Creator
를 입력하고 역할을 클릭합니다.저장을 클릭하여 변경사항을 저장합니다.
선택사항: 다른 서비스 에이전트에 역할을 부여해야 하는 경우 이전 단계를 반복합니다.
gcloud
gcloud iam service-accounts add-iam-policy-binding
명령어를 사용합니다.gcloud iam service-accounts add-iam-policy-binding \ user-sa-name@project-id.iam.gserviceaccount.com \ --member=serviceAccount:service-agent-email \ --role=roles/iam.serviceAccountTokenCreator
다음 값을 바꿉니다.
user-sa-name
: 리소스에 연결할 사용자 관리 서비스 계정의 이름.project-id
: 사용자 관리 서비스 계정이 있는 프로젝트 ID.service-agent-email
: 서비스 에이전트의 이메일 주소.
이 명령어는 사용자 관리 서비스 계정의 업데이트된 허용 정책을 출력합니다.
선택사항: 다른 서비스 에이전트에 역할을 부여해야 하는 경우 명령어를 다시 실행합니다.
REST
이 역할을 부여하려면 읽기-수정-쓰기 패턴을 사용하여 사용자 관리 서비스 계정의 허용 정책을 업데이트합니다.
먼저 사용자 관리 서비스 계정의 허용 정책을 읽습니다.
projects.serviceAccounts.getIamPolicy
메서드는 서비스 계정의 허용 정책을 반환합니다.요청 데이터를 사용하기 전에 다음을 바꿉니다.
PROJECT_ID
: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project
같은 영숫자 문자열입니다.-
USER_SA_NAME
: 리소스에 바인딩할 사용자 관리 서비스 계정의 이름.
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy
JSON 요청 본문:
{ "requestedPolicyVersion": 3 }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
{ "version": 1, "etag": "BwWl3KCTUMY=", "bindings": [ { "role": "roles/iam.serviceAccountUser", "members": [ "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com" ] } ] }
다음으로 서비스 계정 토큰 서비스 생성자 역할을 서비스 에이전트에 부여하도록 허용 정책을 수정합니다.
SERVICE_AGENT_EMAIL
을 서비스 에이전트의 이메일 주소로 바꿉니다.{ "version": 1, "etag": "BwWl3KCTUMY=", "bindings": [ { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SERVICE_AGENT_EMAIL" ] }, { "role": "roles/iam.serviceAccountUser", "members": [ "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com" ] } ] }
마지막으로 업데이트된 허용 정책을 작성합니다.
projects.serviceAccounts.setIamPolicy
메서드는 서비스 계정의 허용 정책을 업데이트합니다.요청 데이터를 사용하기 전에 다음을 바꿉니다.
PROJECT_ID
: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project
같은 영숫자 문자열입니다.-
USER_SA_NAME
: 리소스에 바인딩할 사용자 관리 서비스 계정의 이름. -
SERVICE_AGENT_EMAIL
: 사용자 관리 서비스 계정의 액세스 토큰을 만들 서비스 에이전트의 이메일 주소
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy
JSON 요청 본문:
{ "policy": { "version": 1, "etag": "BwWl3KCTUMY=", "bindings": [ { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SERVICE_AGENT_EMAIL" ] }, { "role": "roles/iam.serviceAccountUser", "members": [ "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com" ] } ] } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
{ "version": 1, "etag": "BwWo331TkHE=", "bindings": [ { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SERVICE_AGENT_EMAIL" ] }, { "role": "roles/iam.serviceAccountUser", "members": [ "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com" ] } ] }
새 리소스에 서비스 계정 연결
사용자 관리 서비스 계정을 구성한 후에는 새 리소스를 만들고 해당 리소스에 서비스 계정을 연결할 수 있습니다. 적절한 프로젝트에 새 리소스를 만들어야 합니다.
만들려는 리소스 유형에 대한 안내를 참조하세요.
리소스를 만들 때 서비스 계정 연결 | |
---|---|
AI Platform Prediction | 모델 버전 |
AI Platform Training | 작업 |
App Engine 표준 환경 | 앱 버전 |
App Engine 가변형 환경 | 앱 버전 |
Cloud Composer | 환경 |
Cloud Functions | Cloud 함수 |
Cloud Life Sciences | 파이프라인 |
Cloud Run | 서비스 |
Cloud Scheduler | 작업 |
Cloud Source Repositories | |
Compute Engine | |
Dataflow | 작업 |
Datalab | 인스턴스 |
Dataproc | 클러스터 |
Google Kubernetes Engine | |
메모장 | 메모장 인스턴스 |
Pub/Sub | 구독 |
Vertex AI |
리소스를 만들고 서비스 계정을 리소스에 연결한 후 서비스 계정에 역할을 부여하여 해당 리소스에 액세스할 수 있습니다. 이 프로세스는 다른 주 구성원에 역할을 부여하는 것과 동일합니다.
역할 부여 방법을 알아보려면 리소스 액세스 권한 부여, 변경, 취소를 참조하세요.
감사 로그 해석
Cloud 감사 로그를 사용하면 Google Cloud 리소스에 대해 '누가, 언제, 어디서, 무엇을 했는지' 파악할 수 있습니다.
단기 사용자 인증 정보를 사용하여 서비스 계정을 가장하면 대부분의 Google Cloud 서비스에서 다음 ID를 보여주는 로그 항목을 만듭니다.
- 단기 사용자 인증 정보로 가장한 서비스 계정
- 단기 사용자 인증 정보를 생성한 ID
이러한 로그 항목을 사용하여 단기 사용자 인증 정보를 만든 주 구성원뿐만 아니라 주 구성원이 가장한 서비스 계정을 식별할 수 있습니다.
서비스 계정 가장을 보여주는 감사 로그 항목의 예시는 Google Cloud에 액세스하기 위해 서비스 계정 가장을 참조하세요.
프로젝트 간 서비스 계정 명의 도용 사용 설정
기본적으로 한 프로젝트에서 서비스 계정을 만들어 다른 프로젝트의 리소스에 연결할 수 없습니다. 한 프로젝트의 모든 서비스 계정을 유지하려면 해당 프로젝트의 조직 정책을 업데이트해야 합니다.
서비스 계정이 있는 프로젝트의 조직 정책에서 다음 부울 제약조건을 확인합니다.
프로젝트에
iam.disableCrossProjectServiceAccountUsage
부울 제약조건이 적용되지 않는지 확인합니다.이 부울 제약조건은 서비스 계정을 다른 프로젝트의 리소스에 연결할 수 있는지 여부를 제어합니다. 기본적으로 제약조건은 적용됩니다.
이 제약조건이 적용되지 않으면 IAM은 프로젝트 삭제를 방지하는 프로젝트 선취권을 추가합니다. 이 선취권에는 원본
iam.googleapis.com/cross-project-service-accounts
가 있습니다. 이 선취권을 삭제하지 않는 것이 좋습니다.권장사항: 프로젝트에
iam.restrictCrossProjectServiceAccountLienRemoval
부울 제약조건이 적용되어 있는지 확인합니다.이 부울 제약조건은 주 구성원이 조직 수준의
resourcemanager.projects.updateLiens
권한이 있는 경우에만 프로젝트 선취권을 삭제할 수 있도록 합니다. 이 제약조건이 적용되지 않은 경우 주 구성원이 프로젝트 수준에서 이 권한을 가지고 있으면 프로젝트 선취권을 삭제할 수 있습니다.
조직 정책에서 부울 제약조건을 보거나 변경하는 방법을 알아보려면 부울 제약조건 설정을 참조하세요.
프로젝트 간 서비스 계정 명의 도용 사용 중지
이전에 프로젝트 간에 서비스 계정 가장을 사용 설정한 경우 특히 프로덕션 환경에서 이 기능을 사용 중지하는 것이 좋습니다.
특히 서비스 계정이 있는 프로젝트에서는 다음 변경사항을 적용해서는 안 됩니다.
iam.disableCrossProjectServiceAccountUsage
부울 제약조건을 적용하기 위해 프로젝트의 조직 정책을 업데이트하지 않습니다.iam.restrictCrossProjectServiceAccountLienRemoval
부울 제약조건을 적용하지 않기 위해 프로젝트의 조직 정책을 업데이트하지 않습니다.- 프로젝트를 삭제하지 않도록 방지하는 원본
iam.googleapis.com/cross-project-service-accounts
가 있는 프로젝트 선취권을 삭제하지 않습니다. - 프로젝트를 삭제하지 않습니다.
이 기능을 사용 중지할 위험을 감수하려는 경우 프로젝트 간에 사용 중인 서비스 계정을 사용 중지한 후 문제에 대해 Google Cloud 환경을 모니터링하여 위험을 줄일 수 있습니다. 문제가 발생하면 서비스 계정을 다시 사용 설정할 수 있습니다. 문제가 발생하지 않으면 다른 프로젝트의 서비스 계정에 의존하는 Google Cloud 리소스가 없는 것일 수 있습니다.
다음 단계
- Compute Engine 인스턴스에 서비스 계정 연결 방법 알아보기
- 서비스 계정 보안을 위한 권장사항 검토 및 적용
- 조건부 역할 바인딩으로 주 구성원의 액세스 조건 생성 방법 알아보기
- IAM의 감사 로깅에 대해 자세히 알아보기