이 페이지에서는 서비스 계정의 위임 체인에 따라 서비스 계정에 대해 단기 사용자 인증 정보를 만드는 방법을 설명합니다. 이 방법은 태스크 수행에 필요한 권한이 있는 토큰을 얻기 위해 일련의 토큰 생성 호출을 실행해야 할 때 사용할 수 있습니다.
단기 사용자 인증 정보를 얻은 후에는 이를 사용해서 서비스 계정을 가장할 수 있습니다.
단일 토큰 생성 호출로 필요한 권한이 있는 토큰을 생성할 수 있으면 해당 서비스 계정에 대해 직접 단기 사용자 인증 정보를 만들어야 합니다.
단기 사용자 인증 정보 만들기 정보
만드는 토큰 유형에 따라 단기 사용자 인증 정보를 사용하여 Google API, 제3자 API 또는 ID 토큰이 필요한 애플리케이션에 대한 호출을 인증할 수 있습니다. 단기 사용자 인증 정보는 수명이 몇 시간 이내로 제한되며 자동으로 새로고침되지 않습니다. 단기 서비스 계정 사용자 인증 정보는 신뢰할 수 있는 서비스 계정에 리소스에 대한 제한적 액세스 권한을 부여해야 하는 경우에 유용합니다. 또한 서비스 계정 키와 같은 장기 사용자 인증 정보보다 위험성이 적습니다.
서비스 계정에 대해 다음 유형의 단기 사용자 인증 정보를 만들 수 있습니다.
OAuth 2.0 액세스 토큰
대부분의 Google API 인증에서는 액세스 토큰을 수용합니다. 서비스 계정에 대해 액세스 토큰을 생성할 때 액세스 토큰은 갱신 토큰 없이 제공됩니다. 즉, 토큰이 만료되면 토큰 생성 프로세스를 반복하여 새 토큰을 생성해야 합니다.
자세한 내용은 액세스 토큰을 참조하세요.
OpenID Connect(OIDC) ID 토큰
ID 토큰은 OpenID Connect(OIDC) 사양을 따릅니다. ID 토큰은 제한된 수의 서비스와 애플리케이션에서 허용됩니다.
자세한 내용은 ID 토큰 및 Cloud Run 또는 Cloud Run Functions에서 호스팅되는 애플리케이션의 인증을 참조하세요.
자체 서명 JSON 웹 토큰(JWT)
승인 서버에서 액세스 토큰을 가져오지 않아도 자체 서명 JWT를 사용하여 일부 Google API를 인증할 수 있습니다. API 게이트웨이로 배포된 API에는 다음이 필요합니다.
자체 서명 바이너리 blob
자체 서명 blob은 일반적으로 인증을 위해 임의 바이너리 데이터를 안전하게 전송해야 하는 시나리오에서 유용하게 사용됩니다.
위임 요청 흐름
위임된 요청 흐름을 사용하면 여러 직접 요청을 순차적으로 수행할 필요 없이 단일 요청을 사용하여 직접 요청을 연결할 수 있습니다. 이 흐름에서는 서비스 계정 사용자 인증 정보에 대한 요청이 최종 서비스 계정의 사용자 인증 정보를 생성하기 전에 위임 체인에 있는 1개 이상의 서비스 계정에 위임됩니다. 결과 사용자 인증 정보는 최종 서비스 계정만 나타내며 위임 체인의 중간 서비스 계정은 나타내지 않습니다.
위임 체인에 속하는 각 서비스 계정에는 체인에 속한 다음 서비스 계정에 필요한 권한이 있어야 요청을 전달할 수 있습니다.
서비스 계정 하나에서 필요한 모든 권한을 제공하는 경우 서비스 계정에서 단기 사용자 인증 정보 만들기에 설명된 더 간단한 흐름을 사용해야 합니다.
시작하기 전에
Enable the IAM and Service Account Credentials APIs.
IAM 서비스 계정 이해
아직 이해가 부족하면 빠른 시작의 단계를 수행하여 결제와 IAM API를 사용 설정합니다.
위임 체인에서 사용할 서비스 계정을 식별합니다.
새 서비스 계정을 만들고 필요한 경우 위임 체인에 포함할 수 있습니다.
필수 권한 제공
위임 요청에는 호출자, 위임 체인에 있는 하나 이상의 서비스 계정, 사용자 인증 정보가 생성된 서비스 계정까지 2개 이상의 ID가 포함됩니다. 이 흐름에서는 다음 ID를 고려하세요.
- 서비스 계정 1(
SA_1) - 단기 사용자 인증 정보를 요청하는 호출자입니다. - 서비스 계정 2(
SA_2) - 최초 요청을SA_3에 위임하는 중개자 역할을 하는 서비스 계정입니다. 이 계정은 요청만 전달하며SA_1또는SA_3에 추가 액세스 권한을 부여하지 않습니다. - 서비스 계정 3(
SA_3) - 사용자 인증 정보가 생성되는 제한적 권한 계정입니다.
위임을 허용하려면 각 계정이 체인에 속한 이전 계정에 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여해야 합니다.
이 특정 예시에서 SA_2에 대한 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 SA_1에 부여해야 합니다. 다음은 리소스로 처리되는 SA_2 서비스 계정의 예시입니다. SA_2에 역할을 부여할 때 다른 리소스를 업데이트하는 것과 동일한 방식으로 허용 정책을 업데이트합니다.
이 흐름 예시에서는 중개자 역할을 하는 서비스 계정이 하나뿐입니다. 서비스 계정 두 개 이상을 통해 액세스 권한을 위임하려면 체인에 속한 다른 서비스 계정에도 이 역할을 할당해야 합니다.
다음으로 SA_3에 대한 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)도 SA_2에 부여해야 합니다. 이렇게 하면 SA_2에서 SA_3의 단기 사용자 인증 정보를 만들 수 있습니다.
다음 단계에서는 REST API를 사용하여 역할을 부여합니다. 하지만 Google Cloud 콘솔 또는 gcloud CLI를 사용할 수도 있습니다.
API
먼저 SA_2(중개 서비스 계정)의 허용 정책을 가져옵니다.
serviceAccounts.getIamPolicy 메서드는 서비스 계정의 허용 정책을 가져옵니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
PROJECT_ID: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project같은 영숫자 문자열입니다.SA_2: 서비스 계정 2의 이름입니다.POLICY_VERSION: 반환할 정책 버전입니다. 요청에는 정책 버전 3인 최신 정책 버전이 지정되어야 합니다. 자세한 내용은 정책을 가져올 때 정책 버전 지정을 참조하세요.
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy
JSON 요청 본문:
{
"options": {
"requestedPolicyVersion": POLICY_VERSION
}
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
{
"version": 1,
"etag": "BwWKmjvelug=",
"bindings": [
{
"role": "roles/serviceAccountAdmin",
"members": [
"user:my-user@example.com"
]
}
]
}
서비스 계정에 역할을 부여하지 않은 경우 응답에 etag 값만 포함됩니다. 다음 단계에서 해당 etag 값을 포함합니다.
다음으로 SA_1에 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여하도록 허용 정책을 수정합니다.
예를 들어 이전 단계의 샘플 응답을 수정하려면 다음을 추가합니다.
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:my-user@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com" ] } ] }
그런 다음 SA_2의 업데이트된 허용 정책을 작성합니다.
serviceAccounts.setIamPolicy 메서드는 서비스 계정에 대한 업데이트된 허용 정책을 설정합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
PROJECT_ID: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project같은 영숫자 문자열입니다.SA_2: 서비스 계정 2의 이름입니다.-
POLICY: 설정하려는 정책의 JSON 표현입니다. 정책 형식에 대한 자세한 내용은 정책 참조를 확인하세요.예를 들어 이전 단계에 표시된 허용 정책을 설정하려면
POLICY를 다음으로 바꿉니다.{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com" ] } ] }
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy
JSON 요청 본문:
{
"policy": POLICY
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
응답에는 업데이트된 허용 정책이 포함됩니다.
이제 SA_3(사용자 인증 정보가 생성되는 서비스 계정)의 허용 정책을 가져옵니다.
serviceAccounts.getIamPolicy 메서드는 서비스 계정의 허용 정책을 가져옵니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
PROJECT_ID: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project같은 영숫자 문자열입니다.SA_3: 서비스 계정 3의 이름입니다.POLICY_VERSION: 반환할 정책 버전입니다. 요청에는 정책 버전 3인 최신 정책 버전이 지정되어야 합니다. 자세한 내용은 정책을 가져올 때 정책 버전 지정을 참조하세요.
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy
JSON 요청 본문:
{
"options": {
"requestedPolicyVersion": POLICY_VERSION
}
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
{
"version": 1,
"etag": "BwWKmjvelug=",
"bindings": [
{
"role": "roles/serviceAccountAdmin",
"members": [
"user:my-user@example.com"
]
}
]
}
서비스 계정에 역할을 할당하지 않았으면 응답에 etag 값만 포함됩니다. 다음 단계에서 해당 etag 값을 포함합니다.
다음으로 SA_2에 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여하도록 허용 정책을 수정합니다.
예를 들어 이전 단계의 샘플 응답을 수정하려면 다음을 추가합니다.
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:my-user@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com" ] } ] }
마지막으로 업데이트된 허용 정책을 작성합니다.
serviceAccounts.setIamPolicy 메서드는 서비스 계정에 대한 업데이트된 허용 정책을 설정합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
PROJECT_ID: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project같은 영숫자 문자열입니다.SA_3: 서비스 계정 3의 이름입니다.-
POLICY: 설정하려는 정책의 JSON 표현입니다. 정책 형식에 대한 자세한 내용은 정책 참조를 확인하세요.예를 들어 이전 단계에 표시된 허용 정책을 설정하려면
POLICY를 다음으로 바꿉니다.{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:my-user@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com" ] } ] }
HTTP 메서드 및 URL:
POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy
JSON 요청 본문:
{
"policy": POLICY
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
응답에는 업데이트된 허용 정책이 포함됩니다.
단기 사용자 인증 정보 요청
각 ID에 적절한 역할을 부여했으면 원하는 서비스 계정에 단기 사용자 인증 정보를 요청할 수 있습니다. 지원되는 사용자 인증 정보 유형은 다음과 같습니다.
이러한 요청에 위임 체인을 지정하는 방법을 알아보려면 이 페이지의 위임 체인 지정 섹션을 참조하세요.
OAuth 2.0 액세스 토큰 생성
기본적으로 OAuth 2.0 액세스 토큰은 최대 1시간(3,600초) 동안 유효합니다. 하지만 이 토큰의 최대 수명을 12시간(43,200초)까지 연장할 수 있습니다. 이렇게 하려면 토큰의 수명을 연장해야 할 서비스 계정을 파악한 후 constraints/iam.allowServiceAccountCredentialLifetimeExtension 목록 제약조건이 포함된 조직 정책에 이러한 서비스 계정을 추가합니다. 그런 다음 이러한 서비스 계정의 토큰을 만들 때 수명을 최대 43,200초까지 지정할 수 있습니다.
서비스 계정용 OAuth 2.0 액세스 토큰을 생성하려면 다음 안내를 따르세요.
API
Service Account Credentials API의 serviceAccounts.generateAccessToken 메서드는 서비스 계정의 OAuth 2.0 액세스 토큰을 생성합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
SA_NAME: 토큰을 만들 서비스 계정의 이름입니다.PROJECT_ID: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project같은 영숫자 문자열입니다.DELEGATES: 위임된 요청 흐름을 사용 중인 경우 이 페이지의 위임 체인 지정을 참조하세요. 위임 없이 직접 요청 흐름을 사용할 경우 요청 본문에서delegates필드를 생략합니다.-
LIFETIME: 액세스 토큰이 만료될 때까지의 시간(초)입니다. 예를 들면300s입니다.기본적으로 토큰 최대 수명은 1시간(3,600초)입니다. 이 토큰의 최대 수명을 12시간(43,200초)까지 연장하려면
constraints/iam.allowServiceAccountCredentialLifetimeExtension목록 제약조건이 포함된 조직 정책에 서비스 계정을 추가합니다.
HTTP 메서드 및 URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken
JSON 요청 본문:
{
"delegates": [
DELEGATES
],
"scope": [
"https://www.googleapis.com/auth/cloud-platform"
],
"lifetime": "LIFETIME"
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
generateAccessToken 요청이 성공하면 응답 본문에 OAuth 2.0 액세스 토큰과 만료 시간이 포함됩니다. 그런 다음 accessToken을 expireTime에 도달할 때까지 서비스 계정 대신 요청을 인증하는 데 사용할 수 있습니다.
{
"accessToken": "eyJ0eXAi...NiJ9",
"expireTime": "2020-04-07T15:01:23.045123456Z"
}
OpenID Connect ID 토큰 생성
OpenID Connect ID 토큰은 1시간(3,600초) 동안 유효합니다. 서비스 계정의 ID 토큰을 생성하려면 다음 안내를 따르세요.
API
Service Account Credentials API의 serviceAccounts.generateIdToken 메서드는 서비스 계정의 OIDC ID 토큰을 생성합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
-
PRIV_SA: 단기 토큰이 생성된 권한 보유 서비스 계정의 이메일 주소입니다. -
AUDIENCE_NAME: 토큰의 대상이며, 일반적으로 토큰이 액세스하는 데 사용될 애플리케이션 또는 서비스의 URL입니다.
HTTP 메서드 및 URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/PRIV_SA:generateIdToken
JSON 요청 본문:
{
"audience": "AUDIENCE_NAME",
"includeEmail": "true"
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
generateId 요청이 성공하면 다음과 같이 응답 본문에 1시간 동안 유효한 ID 토큰이 포함됩니다. 이후 token은 서비스 계정 대신 요청을 인증하는 데 사용할 수 있습니다.
{
"token": "eyJ0eXAi...NiJ9"
}
자체 서명 JSON 웹 토큰(JWT) 생성
자체 서명 JSON 웹 토큰(JWT)은 다음과 같은 다양한 시나리오에서 유용합니다.
- Google의 인증 가이드에서 설명하는 대로 Google API 호출을 인증하는 시나리오
- Google Cloud 또는 App Engine 애플리케이션 같이 Google 외의 서비스 사이에서 안전하게 통신하는 시나리오. 이 시나리오에서는 특정 애플리케이션이 다른 애플리케이션에서 인증 목적으로 확인할 수 있는 토큰에 서명할 수 있습니다.
- 사용자, 계정 또는 기기에 관한 임의 클레임이 포함된 JWT에 서명하여 서비스 계정을 ID 공급업체로 처리하는 시나리오
서비스 계정용 자체 서명 JWT를 생성하려면 다음 안내를 따르세요.
API
Service Account Credentials API의 serviceAccounts.signJwt 메서드는 서비스 계정의 시스템 관리 비공개 키를 사용하여 JWT에 서명합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
SA_NAME: 토큰을 만들 서비스 계정의 이름입니다.PROJECT_ID: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project같은 영숫자 문자열입니다.DELEGATES: 위임된 요청 흐름을 사용 중인 경우 이 페이지의 위임 체인 지정을 참조하세요. 위임 없이 직접 요청 흐름을 사용할 경우 요청 본문에서delegates필드를 생략합니다.-
JWT_PAYLOAD: 서명할 JWT 페이로드로, JWT 클레임 집합이 저장되는 JSON 객체이기도 합니다. 원하는 사용 사례에 필요하고 호출 중인 서비스의 검증 요구사항을 충족하는 클레임을 포함합니다. Google API를 호출하는 경우 클레임 요건은 Google의 인증 가이드를 참조하세요.exp(만료 시간) 클레임은 향후 12시간을 초과할 수 없습니다. Google API를 호출하는 경우exp클레임은 향후 1시간 이하로 설정해야 합니다.다음 페이로드 예시에는 Google API를 호출하는 클레임이 포함되어 있습니다. 여기서
EXP는 만료 시간을 나타내는 정수 타임스탬프입니다.{ \"iss\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"sub\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"aud\": \"https://firestore.googleapis.com/\", \"iat\": 1529350000, \"exp\": EXP }
HTTP 메서드 및 URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:signJwt
JSON 요청 본문:
{
"delegates": [
DELEGATES
],
"payload": "JWT_PAYLOAD"
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
signJwt 요청이 성공하면 다음과 같이 응답 본문에 서명된 JWT와 JWT에 서명할 때 사용된 서명 키 ID가 포함됩니다. signedJwt 값을 Bearer 토큰으로 사용하여 서비스 계정 대신 요청을 직접 인증할 수 있습니다. 토큰은 요청에서 지정한 만료 시간까지만 유효합니다.
{
"keyId": "42ba1e...fc0a",
"signedJwt": "eyJ0eXAi...NiJ9"
}
자체 서명 blob 만들기
자체 서명 blob은 일반적으로 인증을 위해 임의 바이너리 데이터를 안전하게 전송해야 하는 시나리오에서 유용하게 사용됩니다. 예를 들어 커스텀 프로토콜/토큰 유형(JWT 아님)을 사용하려면 다운스트림 서비스에서 사용할 수 있도록 이 데이터를 서명된 blob에 포함해야 합니다.
서비스 계정용 자체 서명 blob을 생성하려면 다음 안내를 따르세요.
API
Service Account Credentials API의 serviceAccounts.signBlob 메서드는 서비스 계정의 시스템 관리 비공개 키를 사용하여 blob에 서명합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
SA_NAME: 토큰을 만들 서비스 계정의 이름입니다.PROJECT_ID: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project같은 영숫자 문자열입니다.DELEGATES: 위임된 요청 흐름을 사용 중인 경우 이 페이지의 위임 체인 지정을 참조하세요. 위임 없이 직접 요청 흐름을 사용할 경우 요청 본문에서delegates필드를 생략합니다.BLOB_PAYLOAD: 바이트 단위의 base64 인코딩 문자열입니다. 예를 들면VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cu입니다.
HTTP 메서드 및 URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:signBlob
JSON 요청 본문:
{
"delegates": [
DELEGATES
],
"payload": "BLOB_PAYLOAD"
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
signBlob 요청이 성공하면 다음과 같이 응답 본문에 서명된 blob과 blob에 서명할 때 사용된 서명 키 ID가 포함됩니다. signedBlob 값을 Bearer 토큰으로 사용하여 서비스 계정 대신 요청을 직접 인증할 수 있습니다. 토큰은 서비스 계정의 시스템 관리 비공개 키가 만료될 때까지 유효합니다. 이 키의 ID는 응답의 keyId 필드 값입니다.
{
"keyId": "42ba1e...fc0a",
"signedBlob": "eyJ0eXAi...NiJ9"
}
위임 체인 지정
위임 요청 흐름을 사용해 임시 서비스 계정 사용자 인증 정보를 만들 때는 각 API 요청 본문에서 서비스 계정 위임 체인을 정확한 순서와 다음과 같은 형식으로 지정해야 합니다.
projects/-/serviceAccounts/SA_ID
SA_ID를 서비스 계정의 고유 숫자 ID 또는 서비스 계정의 이메일 주소로 바꿉니다.
예를 들어 위임 체인이 SA_1(호출자)부터 SA_2(위임)와 SA_3(위임)를 거쳐 SA_4까지 흐른다고 가정하면 delegates[] 필드에는 SA_2와 SA_3이 다음 순서로 포함됩니다.
{ "delegates": [ "projects/-/serviceAccounts/SA_2@PROJECT_ID.iam.gserviceaccount.com", "projects/-/serviceAccounts/SA_3@PROJECT_ID.iam.gserviceaccount.com" ] }
호출자와 사용자 인증 정보가 생성되는 서비스 계정은 위임 체인에 포함되지 않습니다.