서비스 계정

이 페이지에서는 서비스 계정, 서비스 계정 유형, 서비스 계정에서 사용할 수 있는 IAM 역할을 설명합니다.

시작하기 전에

  • IAM의 기본 개념 이해

서비스 계정이란 무엇인가요?

서비스 계정은 사용자가 아닌 애플리케이션 또는 가상 머신(VM) 인스턴스에서 사용하는 특별한 유형의 계정입니다. 애플리케이션은 서비스 계정 자체 또는 Google Workspace로 승인되거나, 도메인 전체 위임을 통해 Cloud ID 사용자로 승인된 승인된 API 호출을 수행하기 위해 서비스 계정을 사용합니다.

예를 들어 Compute Engine VM을 서비스 계정으로 실행할 수 있으며 해당 계정에 필요한 리소스에 대한 액세스 권한을 부여할 수 있습니다. 이렇게 하면 서비스 계정은 서비스의 ID가 되며 서비스 계정의 권한은 서비스가 액세스할 수 있는 리소스를 제어합니다.

서비스 계정은 계정 고유의 이메일 주소로 식별됩니다.

서비스 계정과 사용자 계정의 차이점

서비스 계정은 사용자 계정과 다음과 같은 몇 가지 주요 차이점이 있습니다.

  • 서비스 계정에는 비밀번호가 없으며 브라우저나 쿠키를 통해 로그인할 수 없습니다.
  • 서비스 계정은 Google을 인증하는 데 사용되는 비공개/공개 RSA 키-쌍과 연결되어 있습니다.
  • 다른 사용자나 서비스 계정이 서비스 계정을 가장하도록 할 수 있습니다.
  • 서비스 계정은 사용자 계정과 달리 Google Workspace 도메인의 구성원이 아닙니다. 문서 또는 이벤트와 같은 Google Workspace 애셋을 Google Workspace 도메인의 모든 구성원과 공유하면 서비스 계정과 공유되지 않습니다. 마찬가지로 서비스 계정으로 만든 Google Workspace 애셋은 Google Workspace 도메인에서 생성되지 않습니다. 따라서 Google Workspace 및 Cloud ID 관리자는 이러한 애셋을 소유하거나 관리할 수 없습니다.

서비스 계정 생성 방지

조직, 프로젝트 또는 폴더에서 constraints/iam.disableServiceAccountCreation 조직 정책 제약조건을 적용하여 서비스 계정 생성을 방지할 수 있습니다.

이 제약조건을 적용하기 전에 다음 제한사항을 고려하세요.

  • 프로젝트 또는 조직 내의 모든 프로젝트에 이 제약조건을 적용하면 일부 Google Cloud 서비스는 기본 서비스 계정을 만들 수 없습니다. 따라서 프로젝트가 서비스 계정을 가장해야 하는 워크로드를 실행하면 프로젝트에는 워크로드가 사용할 수 있는 서비스 계정이 포함되지 않을 수 있습니다.

    이 문제를 해결하려면 프로젝트 간 서비스 계정 명의 도용을 사용 설정하면 됩니다. 이 기능을 사용 설정하면 중앙 집중식 프로젝트에서 서비스 계정을 만든 다음 다른 프로젝트의 리소스에 서비스 계정을 연결할 수 있습니다.

  • 워크로드 아이덴티티 제휴와 같은 일부 기능을 사용하려면 서비스 계정을 만들어야 합니다.

    워크로드 아이덴티티 제휴를 사용하지 않는 경우 조직 정책 제약조건을 사용하여 모든 ID 공급업체의 제휴를 차단하는 것이 좋습니다.

서비스 계정 키

각 서비스 계정은 Google을 인증하는 데 사용되는 두 가지 공개/비공개 RSA 키 쌍 조합인 Google 관리 키 및 사용자 관리 키와 연결되어 있습니다.

Google 관리 키

Google 관리 키 쌍은 Google에서 키의 공개 부분과 비공개 부분을 모두 저장하고 정기적으로 순환시키며(최대 2주까지 각 키를 사용하여 서명할 수 있음) 비공개 키가 항상 에스크로에 보관되며 직접 액세스할 수 없다는 것을 의미합니다. IAM은 이 키를 사용하여 서비스 계정 대신 서명하기 위한 API를 제공합니다. 자세한 내용은 단기 서비스 계정 사용자 인증 정보 만들기를 참조하세요.

사용자 관리 키

사용자 관리 키 쌍은 키 쌍의 공개 부분과 비공개 부분을 모두 소유한다는 것을 의미합니다. Google Cloud 외부에서 사용할 수 있는 하나 이상의 사용자 관리 키 쌍('외부' 키라고도 함)을 만들 수 있습니다. Google에서는 사용자 관리 키의 공개 부분만 저장합니다.

공개 키를 적절한 형식으로 만들고 Google에 업로드할 수도 있으며, 이 경우 지정된 서비스 계정에 영구적으로 연결됩니다. 서비스 계정 키를 만들 때처럼 서비스 계정 대신 서명 작업을 수행해야 하는 경우 업로드된 공개 키가 사용됩니다.

사용자 관리 키 쌍의 비공개 부분은 애플리케이션 기본 사용자 인증 정보에서 가장 일반적으로 사용됩니다. 그런 다음 비공개 키를 사용하여 서버 간 애플리케이션을 인증합니다.

사용자 관리 키에서 비공개 키의 보안 및 키 순환과 같은 다른 관리 작업의 책임은 사용자에게 있습니다. 사용자 관리 키는 IAM API, gcloud 명령줄 도구, Google Cloud Console의 서비스 계정 페이지에서 관리될 수 있습니다. 원활한 키 순환을 위해 서비스 계정당 최대 10개의 서비스 계정 키를 만들 수 있습니다.

Secret Manager를 사용해 키를 안전하게 관리하는 것이 좋습니다.

사용자 관리 키 생성 방지

사용자 관리 키는 매우 강력한 사용자 인증 정보이며 제대로 관리하지 않을 경우 보안상 위험할 수 있습니다.

사용자 관리 키 사용을 제한하려면 다음 조직 정책 제약조건을 조직, 프로젝트, 폴더에 적용하면 됩니다.

  • constraints/iam.disableServiceAccountKeyCreation: 구성원이 사용자 관리 서비스 계정 키를 만들지 못하게 합니다.
  • constraints/iam.disableServiceAccountKeyUpload: 구성원이 서비스 계정의 공개 키를 업로드하지 못하게 합니다.

워크로드 아이덴티티 제휴를 사용하고 있기 때문에 이러한 제약조건을 적용하는 경우 워크로드 아이덴티티 제휴를 위한 조직 정책 제약조건을 사용하여 허용할 ID 공급업체를 지정하는 것이 좋습니다.

서비스 계정 유형

사용자 관리 서비스 계정

IAM API, Cloud Console, gcloud 명령줄 도구를 사용하여 프로젝트에 사용자 관리 서비스 계정을 만들 수 있습니다. 이러한 계정을 관리하고 보호해야 합니다.

기본적으로 프로젝트에서 최대 100개의 사용자 관리 서비스 계정을 만들 수 있습니다. 이 할당량이 요구사항을 충족하지 않으면 Cloud Console을 사용하여 할당량 증가를 요청할 수 있습니다. 이 페이지에 설명된 기본 서비스 계정은 이 할당량에 포함되지 않습니다.

프로젝트에서 사용자 관리 서비스 계정을 만들 때 서비스 계정의 이름을 선택합니다. 이 이름은 서비스 계정을 식별하는 이메일 주소에 표시되며 다음 형식을 사용합니다.

service-account-name@project-id.iam.gserviceaccount.com

기본 서비스 계정

일부 Google Cloud 서비스를 사용 설정하거나 사용하는 경우 서비스에서 다른 Google Cloud 리소스에 액세스하는 작업을 배포할 수 있는 사용자 관리 서비스 계정이 생성됩니다. 이러한 계정을 기본 서비스 계정이라고 합니다.

애플리케이션이 기본 서비스 계정이 있는 Google Cloud 환경에서 실행되는 경우 애플리케이션은 기본 서비스 계정의 사용자 인증 정보를 사용하여 Google Cloud API를 호출할 수 있습니다. 또는 자체 사용자 관리 서비스 계정을 만들어 인증에 사용할 수 있습니다. 자세한 내용은 사용자 인증 정보 자동으로 찾기를 참조하세요.

다음 표에는 기본 서비스 계정을 만드는 서비스가 나와 있습니다.

서비스 서비스 계정 이름 이메일 주소
App Engine 및 App Engine을 사용하는 모든 Google Cloud 서비스 App Engine 기본 서비스 계정 project-id@appspot.gserviceaccount.com
Compute Engine 및 Compute Engine을 사용하는 모든 Google Cloud 서비스 Compute Engine 기본 서비스 계정 project-number-compute@developer.gserviceaccount.com

Google 관리 서비스 계정

일부 Google Cloud 서비스는 사용자를 대신하여 작업을 실행할 수 있도록 리소스에 대한 액세스 권한이 필요합니다. 예를 들어 Cloud Run을 사용하여 컨테이너를 실행할 때 서비스는 컨테이너를 트리거할 수 있는 모든 Pub/Sub 주제에 액세스할 수 있어야 합니다.

이러한 요구사항을 충족하기 위해 Google은 많은 Google Cloud 서비스의 서비스 계정을 만들고 관리합니다. 이러한 서비스 계정을 Google 관리 서비스 계정이라고 합니다. 프로젝트의 IAM 정책, 감사 로그, Cloud Console의 IAM 페이지에서 Google 관리 서비스 계정이 표시될 수 있습니다.

Google 관리 서비스 계정은 Cloud Console의 서비스 계정 페이지에 나열되지 않습니다.

예를 들면 다음과 같습니다.

  • Google API 서비스 에이전트. 프로젝트에는 project-number@cloudservices.gserviceaccount.com 형식을 사용하는 이메일 주소가 포함된 Google API 서비스 에이전트라는 서비스 계정이 포함될 수 있습니다.

    이 서비스 계정은 사용자 대신 내부 Google 프로세스를 실행합니다. 여기에는 프로젝트에 대한 편집자 역할(roles/editor)이 자동으로 부여됩니다.

  • Google 관리 서비스 계정의 역할 관리자. IAM의 감사 로그는 서비스 계정 service-agent-manager@system.gserviceaccount.com을 참조할 수 있습니다.

    이 서비스 계정은 다른 Google 관리 서비스 계정에 부여된 역할을 관리합니다. 감사 로그에서만 볼 수 있습니다.

    예를 들어 새로운 API를 사용하는 경우 Google은 자동으로 새 Google 관리 서비스 계정을 만들고 프로젝트의 서비스 계정에 역할을 부여할 수 있습니다. 이러한 역할을 부여하면 service-agent-manager@system.gserviceaccount.com이 프로젝트의 IAM 정책을 설정했음을 나타내는 감사 로그 항목이 생성됩니다.

  • 다른 Google 관리 서비스 계정. 프로젝트에는 개별 서비스를 대신하는 다른 Google 관리 서비스 계정이 포함될 수 있습니다. 이러한 서비스 계정을 서비스 에이전트라고도 합니다. 이러한 서비스 에이전트에는 역할이 자동으로 부여될 수 있습니다. 이러한 역할의 이름은 일반적으로 serviceAgent로 끝납니다.

    서비스 에이전트와 각 에이전트에 자동으로 부여되는 역할의 전체 목록은 서비스 에이전트를 참조하세요.

서비스 계정 위치

각 서비스 계정은 프로젝트에 위치합니다. 서비스 계정을 만든 후에는 다른 프로젝트로 이동할 수 없습니다.

서비스 계정을 프로젝트로 구성하는 몇 가지 방법이 있습니다.

  • 같은 프로젝트에 서비스 계정과 리소스를 만듭니다.

    이 방법을 사용하면 서비스 계정을 쉽게 시작할 수 있습니다. 하지만 서비스 계정이 많은 프로젝트에 분산되어 있으면 서비스 계정을 추적하기 어려울 수 있습니다.

  • 서로 다른 프로젝트의 서비스 계정을 중앙화합니다.

    이 방법을 사용하면 조직의 모든 서비스 계정이 소수의 프로젝트로 정리되어 서비스 계정을 보다 쉽게 관리할 수 있습니다. 이 방법을 사용하려면 다른 프로젝트의 리소스에 서비스 계정을 연결하는 경우 추가 설정이 필요합니다. 그러면 해당 리소스가 서비스 계정을 ID로 사용할 수 있습니다.

    서비스 계정이 한 프로젝트에 있고 다른 프로젝트의 리소스에 액세스하는 경우 일반적으로 두 프로젝트에서 해당 리소스에 API를 사용 설정해야 합니다. 예를 들어 my-service-accounts 프로젝트에 서비스 계정이 있고 my-application 프로젝트에 Cloud SQL 인스턴스가 있는 경우 my-service-accountsmy-application 모두에 Cloud SQL API를 사용 설정해야 합니다.

    기본적으로 프로젝트 하나에 서비스 계정을 100개까지 만들 수 있습니다. 추가 서비스 계정을 만들어야 하는 경우 할당량 증가를 요청합니다.

서비스 계정 권한

서비스 계정은 ID리소스입니다.

서비스 계정은 ID이므로 다른 구성원에게 역할을 부여했던 것과 마찬가지로 서비스 계정에 역할을 부여하여 프로젝트의 리소스에 액세스하도록 할 수 있습니다. 예를 들어 애플리케이션의 서비스 계정이 Cloud Storage 버킷의 객체에 액세스하도록 하려면 서비스 계정에 버킷에 대한 스토리지 객체 뷰어 역할(roles/storage.objectViewer)을 부여하면 됩니다.

그러나 서비스 계정은 IAM 정책을 허용하는 리소스이기도 합니다. 따라서 다른 구성원이 서비스 계정 또는 서비스 계정의 상위 리소스 중 하나에 대한 역할을 부여하여 서비스 계정에 액세스하도록 할 수 있습니다. 예를 들어 사용자가 서비스 계정을 가장할 수 있도록 사용자에게 서비스 계정에 대한 서비스 계정 사용자 역할(roles/iam.serviceAccountUser)을 부여할 수 있습니다.

서비스 계정을 포함하여 구성원에게 역할을 부여하는 방법에 대한 자세한 내용은 액세스 권한 부여, 변경, 취소를 참조하세요.

서비스 계정에 역할을 부여하는 방법에 대한 자세한 내용은 서비스 계정 명의 도용 관리를 참조하세요.

서비스 계정 사용자 역할

프로젝트 수준 또는 서비스 계정 수준에서 프로젝트의 모든 서비스 계정에 대해 서비스 계정 사용자 역할(roles/iam.serviceAccountUser)을 부여할 수 있습니다.

  • 프로젝트에서 서비스 계정 사용자 역할이 부여된 사용자는 향후 생성될 수 있는 서비스 계정을 비롯한 프로젝트의 모든 서비스 계정에 액세스할 수 있습니다.

  • 특정 서비스 계정에서 서비스 계정 사용자 역할이 부여된 사용자는 이 서비스 계정에만 액세스할 수 있습니다.

서비스 계정에 대해 서비스 계정 사용자 역할이 부여된 사용자는 서비스 계정에서 액세스한 모든 리소스에 간접적으로 액세스할 수 있습니다. 예를 들어 서비스 계정에 Compute 관리자 역할(roles/compute.admin)이 부여된 경우, 해당 서비스 계정에 대해 서비스 계정 역할(roles/iam.serviceAccountUser)이 부여된 사용자는 서비스 계정의 역할을 수행하여 Compute Engine 인스턴스를 시작할 수 있습니다. 이 흐름에서 사용자는 부여된 역할과 권한을 사용하여 작업을 수행하기 위해 서비스 계정을 가장합니다.

서비스 계정에 사용자 역할을 부여하는 방법에 대한 자세한 내용은 서비스 계정 가장 관리를 참조하세요.

서비스 계정은 서비스 수준의 보안을 나타냅니다. 서비스의 보안을 결정하는 요인은 서비스 계정을 관리하고 사용하는 IAM 역할이 부여된 사람과 해당 서비스 계정에 대한 비공개 외부 키를 보유한 사람입니다. 보안을 위한 권장사항은 다음과 같습니다.

  • IAM API를 사용하여 서비스 계정, 키, 해당 서비스 계정의 정책을 감사합니다.
  • 서비스 계정에서 필요로 하지 않는 외부 키는 삭제합니다.
  • 사용자에게 서비스 계정 관리 또는 사용 권한이 필요하지 않으면 해당 IAM 정책에서 삭제합니다.
  • 서비스 계정에 권한이 최소한의 권한만 갖는지 확인합니다. 기본 서비스 계정은 프로젝트에 대한 편집자(roles/editor) 역할이 자동으로 부여되므로 주의해서 사용해야 합니다.

권장사항에 대한 자세한 내용은 서비스 계정 이해를 참조하세요.

서비스 계정 토큰 생성자 역할

이 역할은 서비스 계정 명의로 OAuth2 액세스 토큰, blob 서명, JWT 서명을 만듭니다.

액세스 범위

액세스 범위는 Compute Engine 가상 머신(VM) 인스턴스에 권한을 지정하는 기존의 방법입니다. gcloud 도구 및 클라이언트 라이브러리의 요청에 사용되는 기본 OAuth 범위를 정의합니다.

이제 Google Cloud는 액세스 범위가 아닌 IAM을 사용하여 Compute Engine 인스턴스의 권한을 지정합니다. 하지만 서비스 계정을 가장하도록 인스턴스를 구성할 때는 여전히 액세스 범위를 설정해야 합니다.

자세한 내용은 Compute Engine 문서를 참조하세요.

단기 서비스 계정 사용자 인증 정보

Google Cloud 서비스 계정의 ID를 사용할 수 있는 임시 사용자 인증 정보를 만들 수 있습니다. 이러한 사용자 인증 정보를 사용하여 Google Cloud API 또는 기타 Google 이외의 API에 대한 호출을 인증할 수 있습니다.

이러한 사용자 인증 정보의 가장 일반적인 사용 사례는 다른 프로젝트, 조직, 계정에서 Google Cloud 리소스에 대한 액세스를 일시적으로 위임하는 것입니다. 예를 들어 외부 호출자에게는 대부분 권한이 부여된 서비스 계정의 영구 사용자 인증 정보를 제공하지 않고 긴급할 때 일시적으로 액세스할 수 있는 권한이 부여됩니다. 또한 보다 제한적인 권한으로 위임된 서비스 계정은 외부 호출자가 강력한 권한이 부여된 서비스 계정의 사용자 인증 정보를 요청할 필요 없이 가장하여 사용할 수 있습니다.

자세한 내용은 단기 서비스 계정 사용자 인증 정보 만들기를 참조하세요.

워크로드 아이덴티티 제휴

Amazon Web Services(AWS) 또는 Microsoft Azure와 같이 Google Cloud 외부에서 실행되는 워크로드의 ID 즉, 서비스 계정을 가장할 수 있는 기능을 부여할 수 있습니다. 이렇게 하면 서비스 계정 키를 사용하는 대신 단기 사용자 인증 정보를 사용하여 리소스에 직접 액세스할 수 있습니다.

자세한 내용은 워크로드 아이덴티티 제휴를 참조하세요.

애플리케이션 기본 사용자 인증 정보

애플리케이션 기본 사용자 인증 정보는 Google Cloud 클라이언트 라이브러리에서 서비스 계정 사용자 인증 정보를 자동으로 검색하는 데 사용하는 도구입니다. 환경 변수에 서비스 계정 키를 지정할 수 있으며 애플리케이션 기본 사용자 인증 정보는 자동으로 서비스 계정 키를 사용합니다. 키를 지정하지 않으면 애플리케이션 기본 사용자 인증 정보는 코드를 실행 중인 리소스에 연결된 서비스 계정 또는 코드를 실행하는 서비스의 기본 서비스 계정을 사용합니다.

자세한 내용은 자동으로 사용자 인증 정보 찾기를 참조하세요.

다음 단계

서비스 계정 사용에 관한 권장사항은 서비스 계정 이해를 참조하세요.

다음 방법을 알아보려면 해당 가이드를 참조하세요.

직접 사용해 보기

Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

무료로 시작하기