이 페이지에서는 서비스 계정이 자신의 ID를 가장할 수 있도록 단기 사용자 인증 정보를 만드는 방법을 설명합니다.
서비스 계정은 단기 사용자 인증 정보를 사용하여 Google Cloud API 및 기타 Google 이외의 API에 대한 호출을 인증할 수 있습니다. 단기 사용자 인증 정보는 존속 기간이 몇 시간 이하로 제한되어 있습니다. 단기 서비스 계정 사용자 인증 정보는 신뢰할 수 있는 서비스 계정에 리소스에 대한 제한적 액세스 권한을 부여해야 하는 경우에 유용합니다. 또한 서비스 계정 키와 같은 장기 사용자 인증 정보보다 위험성이 적습니다.
지원되는 사용자 인증 정보 유형으로는 OAuth 2.0 액세스 토큰, OpenID Connect ID 토큰, 자체 서명 JSON 웹 토큰(JWT), 자체 서명 바이너리 객체(blob) 등이 있습니다. 가장 일반적으로 사용되는 사용자 인증 정보 유형은 OAuth 2.0 액세스 토큰과 OpenID Connect(OIDC) ID 토큰입니다. 일부 시나리오 예시는 다음과 같습니다.
OAuth 2.0 액세스 토큰: OAuth 2.0 액세스 토큰은 Google Cloud APIs에 대한 서비스 계정의 액세스를 인증하는 데 유용합니다. 참고할 수 있는 사용 사례 예시를 들자면 서비스 관리자는 프로젝트에서 상승된 권한을 얻기 위해 서비스 계정에 속하는 OAuth 2.0 액세스 토큰을 작성하는 방법으로 서비스 계정을 가장하여 Google Cloud APIs를 호출할 수 있습니다. 상승된 권한을 임시로 사용하도록 하기 위해 토큰의 수명은 짧습니다. 단기 토큰을 사용하면 ID와 리소스에 최소 권한의 원칙을 구현할 수 있습니다. 또한 프로덕션 환경에서 응급 상황이 발생하고 서비스 관리자가 디버깅을 위해 임시로 상승된 권한을 승인받아야 할 때에도 유용합니다.
OIDC ID 토큰: OIDC ID 토큰은 OpenID Connect를 허용하는 서비스에 대해 서비스 계정의 ID를 인증하는 데 유용합니다. 참고할 수 있는 사용 사례 예시를 들자면 Google Cloud에서 실행 중인 서비스는 서비스 계정에 속한 OIDC ID 토큰을 생성하여 데이터 파이프라인 작업 등 타사 클라우드 제공업체에 배포된 다른 서비스에 자신을 인증할 수 있습니다. 대상 서비스가 OIDC로 구성되었다면 인증이 성공적으로 이루어집니다.
시작하기 전에
Enable the IAM and Service Account Credentials APIs.
IAM 서비스 계정 이해
아직 이해가 부족하면 빠른 시작의 다음 단계를 수행하여 결제와 IAM API를 사용 설정합니다.
서비스 계정 만들기
시작하려면 새로운 서비스 계정을 만드세요.
필요한 권한 제공
호출자가 서비스 계정에 사용할 임시 사용자 인증 정보를 만들 수 있는 흐름은 아래 두 가지입니다. 각 흐름마다 해당하는 권한이 필요합니다.
- 직접 요청: 호출자가 Google 계정 또는 서비스 계정으로 인증을 받은 다음 임시 사용자 인증 정보를 만들어 달라고 직접 요청합니다. 이 흐름에서는 2개의 ID, 즉 호출자와 사용자 인증 정보를 생성할 서비스 계정이 필요합니다.
위임 요청: 직접 요청 흐름과 마찬가지로 호출자가 Google 계정 또는 서비스 계정으로 인증을 받지만 요청은 위임 체인에 속한 1개 이상의 서비스 계정으로 위임됩니다. 이 흐름에서는 여러 개의 서비스 계정이 최초 호출자와 사용자 인증 정보가 생성될 서비스 계정 사이에서 중개자 역할을 합니다. 위임 체인에 속하는 각 서비스 계정은 요청을 전달하는 데 필요한 권한이 있어야 합니다.
위임 요청 흐름은 권한이 제한적인 서비스 계정 계층이 프로젝트에 다수 포함되어 있으며, 각 계층은 일부 리소스에 대해 특정적이거나 제한적인 함수를 실행하도록 구성되어 있는 시나리오에서 유용합니다. 예를 들어 한 서비스 계정에는 Cloud Storage 리소스에 대한 권한만 있고 다른 서비스 계정에는 Compute Engine 리소스에 대한 권한만 있는 등의 경우를 말합니다. 다수의 서비스 계정에게 요청을 성공적으로 위임하려면 각 계정이 위임 체인에 포함되어야 합니다.
직접 요청 권한
이 페이지의 필요한 권한 부여에 설명된 것처럼 직접 요청에는 호출자와 사용자 인증 정보가 생성되는 서비스 계정 등 ID 두 개만 제공됩니다. 이 흐름에서는 다음 ID를 고려하세요.
- 서비스 계정 1(
SA_1) - 단기 사용자 인증 정보를 요청하는 호출자입니다. - 서비스 계정 2(
SA_2) - 사용자 인증 정보가 생성되는 제한적 권한 계정입니다.
SA_1에 단기 사용자 인증 정보를 만들 수 있는 권한을 부여하려면 SA_2에 대한 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여합니다. 다음은 리소스로 처리되는 SA_2 서비스 계정의 예시입니다. SA_2에 역할을 부여할 때 다른 리소스를 업데이트하는 것과 동일한 방식으로 허용 정책을 업데이트합니다.
다음 단계에서는 REST API를 사용하여 역할을 부여합니다. 하지만 Cloud Console 또는 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:admin@example.com"
]
}
]
}
서비스 계정에 역할을 할당하지 않았으면 응답에 etag 값만 포함됩니다. 다음 단계에서 해당 etag 값을 포함합니다.
다음으로 SA_1에 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여하도록 허용 정책을 수정합니다.
예를 들어 이전 단계의 샘플 응답을 수정하려면 다음을 추가합니다.
{ "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" ] } ] }
마지막으로 업데이트된 허용 정책을 작성합니다.
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
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
응답에는 업데이트된 허용 정책이 포함됩니다.
위임 요청 권한
이 페이지의 필요한 권한 부여에 설명된 것처럼 위임된 요청에는 호출자, 위임 체인에 있는 서비스 계정 하나 이상, 마지막으로 서비스 계정 등 ID가 두 개 넘게 포함됩니다. 이 흐름에서는 다음 ID를 고려하세요.
- 서비스 계정 1(
SA_1) - 단기 사용자 인증 정보를 요청하는 호출자입니다. - 서비스 계정 2(
SA_2) - 최초 요청을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를 사용하여 역할을 부여합니다. 하지만 Cloud Console 또는 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:admin@example.com"
]
}
]
}
서비스 계정에 역할을 부여하지 않은 경우 응답에 etag 값만 포함됩니다. 다음 단계에서 해당 etag 값을 포함합니다.
다음으로 SA_1에 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여하도록 허용 정책을 수정합니다.
예를 들어 이전 단계의 샘플 응답을 수정하려면 다음을 추가합니다.
{ "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" ] } ] }
그런 다음 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:admin@example.com"
]
}
]
}
서비스 계정에 역할을 할당하지 않았으면 응답에 etag 값만 포함됩니다. 다음 단계에서 해당 etag 값을 포함합니다.
다음으로 SA_2에 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여하도록 허용 정책을 수정합니다.
예를 들어 이전 단계의 샘플 응답을 수정하려면 다음을 추가합니다.
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@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:admin@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 메서드는 서비스 계정의 OpenID Connect ID 토큰을 생성합니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
SA_NAME: 토큰을 만들 서비스 계정의 이름입니다.PROJECT_ID: Google Cloud 프로젝트 ID. 프로젝트 ID는my-project같은 영숫자 문자열입니다.-
AUDIENCE_NAME: 토큰의 대상이며, 일반적으로 토큰이 액세스하는 데 사용될 애플리케이션 또는 서비스의 URL입니다.
HTTP 메서드 및 URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com: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" ] }
호출자와 사용자 인증 정보가 생성되는 서비스 계정은 위임 체인에 포함되지 않습니다.