다양한 사용 사례를 지원하는 사용자 인증 정보 유형
개요
gsutil은 현재 여러 유형의 사용자 인증 정보/인증뿐만 아니라 공개 데이터에 익명으로 액세스하는 기능도 지원합니다. 이러한 각 사용자 인증 정보 유형은 Cloud SDK를 통한 사용자 인증 정보 구성 및 사용에 대한 자세한 내용과 함께 아래에 자세히 설명되어 있습니다.
Gsutil의 Cloud SDK 배포를 통한 사용자 인증 정보 구성/사용
gsutil을 Cloud SDK('gcloud')를 통해 설치/사용하는 경우 사용자 인증 정보는 Cloud SDK의 ~/.config/gcloud 아래에 위치한 사용자가 수정할 수 없는 파일에 저장됩니다. 사용자 인증 정보 작업은 gcloud auth 명령어를 통해서만 가능합니다. 여러 사용자 인증 정보를 설정해야 하는 경우(예: 개별 사용자 계정용 1개와 서비스 계정용 1개) gcloud auth 명령어가 개발자의 사용자 인증 정보를 관리하고 개발자는 gcloud auth 명령어를 사용하여 사용자 인증 정보 간에 전환합니다(자세한 내용은 https://cloud.google.com/sdk/gcloud/reference/auth 참조).
사용자 인증 정보가 gcloud auth를 통해 구성되면 사용자에게 boto 구성 파일(BOTO_CONFIG 환경 변수에 다른 경로가 지정되지 않았으면 ~/.boto에 있음)이 있는지 여부에 관계없이 해당 사용자 인증 정보가 사용됩니다. 하지만 gsutil은 gcloud 사용자 인증 정보 저장소에 저장되지 않은 Cloud Storage가 아닌 사용자 인증 정보 유형(예: S3 계정의 HMAC 사용자 인증 정보)이 필요한 경우에도 boto 구성 파일에서 사용자 인증 정보를 찾습니다.
지원되는 사용자 인증 정보 유형
gsutil은 다양한 유형의 사용자 인증 정보를 지원합니다. 단, 유형 지원 여부는 사용 중인 gsutil 배포에 따라 다릅니다. 위 설명을 참조하세요.
- OAuth2 사용자 계정:
이 사용자 인증 정보 유형은 특정 사용자를 대신하여 요청을 인증하는 데 사용할 수 있습니다(gsutil이 가장 일반적으로 사용).
gcloud init를 실행할 때 생성되는 기본 사용자 인증 정보 유형입니다. 이 사용자 인증 정보 유형은 독립형 gsutil 버전에서 지원되지 않습니다. OAuth2 인증에 대한 자세한 내용은 https://developers.google.com/accounts/docs/OAuth2#scenarios를 참조하세요.- HMAC:
이 사용자 인증 정보 유형은 HMAC 인증을 통해 구현된 프로그램에서 사용할 수 있습니다. HMAC 인증은 다른 특정 클라우드 스토리지 서비스 제공업체에서 지원되는 인증 메커니즘입니다. 이 사용자 인증 정보 유형은 HMAC 사용자 인증 정보를 지원하는 서비스 제공업체와 데이터를 주고받을 때 상호작용에 사용되기도 합니다.
gsutil config -a를 실행할 때 생성되는 사용자 인증 정보 유형입니다.Cloud Storage와 다른 서비스 제공업체 모두에 HMAC 사용자 인증 정보를 설정하거나, Cloud Storage에는 OAuth2 사용자 계정 사용자 인증 정보를 설정하고 다른 서비스 제공업체에는 HMAC 사용자 인증 정보를 설정할 수도 있습니다. 이렇게 하려면
gcloud init명령어를 실행한 후 생성된 ~/.boto 구성 파일을 수정하고 다른 사용자 인증 정보를 추가할 주석을 찾습니다.HMAC 인증에 대한 자세한 내용은 https://developers.google.com/storage/docs/reference/v1/getting-startedv1#keys를 참조하세요.
- OAuth2 서비스 계정:
사용자가 아닌 서비스 또는 애플리케이션을 대신하여 인증할 때 기본적으로 사용되는 사용자 인증 정보 유형입니다. 예를 들어 데이터 업로드/다운로드를 위해 야간 크론 작업에서 gsutil을 실행하려는 경우 서비스 계정을 사용하면 크론 작업이 회사의 개별 직원의 사용자 인증 정보에 의존하지 않습니다.
gcloud auth activate-service-account(또는 gsutil의 독립 실행형 버전을 사용하는 경우gsutil config -e)를 실행할 때 구성된 사용자 인증 정보 유형입니다.서비스 계정은 기본적으로 소유자가 아닌 API 액세스 목적으로 편집자로 간주됩니다. 특히 편집자에게 기본 객체와 버킷 ACL에 대한 소유자 액세스 권한이 있지만 미리 준비된 ACL 옵션이 편집자로부터 소유자 액세스 권한을 삭제하면 예상치 못한 결과가 발생할 수 있습니다. 이 문제를 해결하려면 'gsutil acl set <canned-ACL>' 대신 'gsutil acl ch'를 사용하여 버킷에 대한 권한을 변경합니다.
gcloud auth activate-service-account또는gsutil config -e에 사용할 서비스 계정을 설정하려면 https://cloud.google.com/storage/docs/authentication#generating-a-private-key를 참조하세요.OAuth2 서비스 계정에 대한 자세한 내용은 https://developers.google.com/accounts/docs/OAuth2ServiceAccount를 참조하세요.
계정 역할에 대한 자세한 내용은 https://developers.google.com/console/help/#DifferentRoles를 참조하세요.
- Compute Engine 내부 서비스 계정:
App Engine 또는 Compute Engine에서 호스팅되는 계정에 사용되는 서비스 계정 유형입니다. 이 사용자 인증 정보는 Compute Engine에서
gcloud compute instances create명령어를 실행하면 자동으로 생성되며--scopes플래그로 제어할 수 있습니다.Compute Engine에서 서비스 계정 사용자 인증 정보를 사용하여 워크로드를 인증하는 방법에 대한 자세한 내용은 https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances를 참조하세요.
App Engine 서비스 계정에 대한 자세한 내용은 https://developers.google.com/appengine/docs/python/appidentity/overview를 참조하세요.
- 서비스 계정 가장:
특정 리소스에 대한 단기 액세스 권한을 부여해야 할 때 서비스 계정을 가장하면 유용합니다. 예를 들어 일반적으로 읽기 전용인 민감한 데이터가 포함된 버킷이 있고 신뢰할 수 있는 서비스 계정을 통해 쓰기 액세스 권한을 일시적으로 부여하려는 경우가 해당됩니다.
gsutil -i,gsutil config -e를 실행하고 boto 구성 파일 또는gcloud config set auth/impersonate_service_account [service_account_email_address]를 수정하여 가장에 사용할 서비스 계정을 지정할 수 있습니다.가장하려면 대상 서비스 계정에서 원래 사용자 인증 정보에 roles/iam.serviceAccountTokenCreator를 부여해야 합니다. 자세한 내용은 https://cloud.google.com/iam/docs/creating-short-lived-service-account-credentials를 참조하세요.
- 외부 계정 사용자 인증 정보(워크로드 아이덴티티 제휴):
워크로드 아이덴티티 제휴를 사용하면 Amazon Web Services(AWS), Microsoft Azure나 OpenID Connect(OIDC) 또는 SAML 2.0을 지원하는 ID 공급업체에서 Google Cloud 리소스에 액세스할 수 있습니다.
자세한 내용은 https://cloud.google.com/iam/docs/using-workload-identity-federation을 참조하세요.