워크로드 아이덴티티 제휴 및 GKE용 워크로드 아이덴티티 제휴를 사용하면 워크로드가 외부 ID 제공업체(IdP)를 통해 인증되는 제휴 ID를 사용하여 대부분의 Google Cloud 서비스에 액세스할 수 있습니다.Google Cloud 에서 ID를 주 구성원으로 인증하면 주 구성원은 개발자가 부여한 IAM 역할을 사용하여 리소스에 액세스할 수 있습니다.
Google Cloud 의 워크로드 또는 AWS, Azure, GitHub, GitLab과 같은 플랫폼에서 실행되는 외부 워크로드에서 워크로드 아이덴티티 제휴를 사용할 수 있습니다.
GKE 클러스터에서 실행되는 워크로드에서 GKE용 워크로드 아이덴티티 제휴를 사용하여 Google Cloud리소스에 대한 액세스 권한을 부여할 수 있습니다.
Google Cloud 서비스 계정은 프로덕션 환경에서 워크로드 ID 역할을 할 수 있습니다. 개발자는 워크로드에 직접 액세스 권한을 부여하는 대신 서비스 계정에 대한 액세스 권한을 부여한 후 워크로드에서 서비스 계정을 ID로 사용하게 합니다.
관리형 워크로드 아이덴티티(미리보기)를 사용하면 강력하게 증명된 ID를 Compute Engine 워크로드에 바인딩할 수 있습니다. 관리형 워크로드 아이덴티티를 사용하면 상호 TLS(mTLS)를 사용하여 워크로드를 다른 워크로드에 인증할 수 있지만 Google Cloud API에 인증하는 데는 사용할 수 없습니다.
워크로드에 사용할 수 있는 ID 유형과 구성 방법은 워크로드가 실행되는 위치에 따라 달라집니다.
Google Cloud의 워크로드:
Google Cloud에서 워크로드를 실행하는 경우 다음 방법을 사용하여 워크로드의 ID를 구성할 수 있습니다.
일부 Google Cloud 리소스의 경우 리소스에서 기본 ID로 사용하는 사용자 관리 서비스 계정을 지정할 수 있습니다. 이 프로세스는 서비스 계정을 리소스에 연결하거나 서비스 계정과 리소스를 연결한다고 알려져 있습니다.
리소스에서 실행되는 코드는 Google Cloud 서비스와 리소스에 액세스할 때 리소스에 연결된 서비스 계정을 ID로 사용합니다. 예를 들어 서비스 계정을 Compute Engine 인스턴스에 연결하고 인스턴스의 애플리케이션에서 클라이언트 라이브러리를 사용하여 Google Cloud API를 호출하는 경우 애플리케이션은 인증과 승인에 연결된 서비스 계정을 자동으로 사용합니다.
대부분의 경우 리소스를 만들 때 서비스 계정을 리소스에 연결해야 합니다. 리소스를 만든 후에는 리소스에 연결된 서비스 계정을 변경할 수 없습니다. Compute Engine 인스턴스에는 이 규칙이 적용되지 않습니다. 필요에 따라 인스턴스에 연결된 서비스 계정을 변경할 수 있습니다.
GKE에서 실행되는 워크로드의 경우 GKE용 워크로드 아이덴티티 제휴를 사용하면 클러스터의 각 애플리케이션에서 미세 조정된 고유한 주 구성원 집합에 IAM 역할을 부여할 수 있습니다. GKE용 워크로드 아이덴티티 제휴를 사용하면 GKE 클러스터의 Kubernetes 서비스 계정에서 직원 ID 제휴를 사용하거나 간접적으로 IAM 서비스 계정 가장을 사용하여 Google Cloud리소스에 직접 액세스할 수 있습니다.
직접 리소스 액세스를 사용하면 Google Cloud 서비스 리소스에서 직접 Kubernetes 서비스 계정 ID에 IAM 역할을 부여할 수 있습니다. 대부분의 Google Cloud API는 직접 리소스 액세스를 지원합니다. 하지만 ID 제휴를 사용할 때는 특정 API 메서드에 제한사항이 적용될 수 있습니다. 이러한 제한사항 목록은 지원되는 제품 및 제한사항을 참조하세요.
또는 워크로드에서 서비스 계정 가장을 사용할 수 있습니다. 여기서 구성된 Kubernetes ServiceAccount는 Google CloudAPI에 액세스할 때 ID로 사용되는 IAM 서비스 계정에 바인딩됩니다.
관리형 워크로드 아이덴티티를 사용하면 강력하게 증명된 ID를 Compute Engine 워크로드에 결합할 수 있습니다. 관리형 워크로드 아이덴티티를 사용하면 mTLS를 사용하여 워크로드를 다른 워크로드에 인증할 수 있지만 Google Cloud API에 인증하는 데는 사용할 수 없습니다.
Google Cloud외부에서 워크로드를 실행하는 경우 다음 방법을 사용하여 워크로드의 ID를 구성할 수 있습니다.
워크로드 아이덴티티 제휴
서비스 계정 키
워크로드 아이덴티티 제휴
워크로드 아이덴티티 제휴를 사용하면 AWS 및 Azure Active Directory와 같은 외부 ID 공급업체의 사용자 인증 정보를 사용하여 워크로드가 서비스 계정을 일시적으로 가장하는 데 사용할 수 있는 단기 사용자 인증 정보를 생성할 수 있습니다. 그러면 워크로드에서 서비스 계정을 ID로 사용하여 Google Cloud 리소스에 액세스할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Identities for workloads\n\nThis page describes the identity types that you can use to configure\nyour workloads' access to Google Cloud resources.\n\nGoogle Cloud provides the following types of identities for workloads:\n\n- [**Workload Identity Federation**](/iam/docs/workload-identity-federation) and\n [**Workload Identity Federation for GKE**](/kubernetes-engine/docs/concepts/workload-identity) let your workloads access\n most Google Cloud services by using federated identities that are\n authenticated through an external identity provider (IdP). After\n Google Cloud authenticates the identity as a principal, the principal\n can access resources by using IAM roles that you grant.\n\n- [**Google Cloud service accounts**](/iam/docs/service-account-overview) can act as\n identities for workloads in production environments. Instead of granting access\n to a workload directly, you grant access to a service account, then have the\n workload use the service account as its identity.\n\n- [**Managed workload identities**](/iam/docs/managed-workload-identity) [(Preview)](/products#product-launch-stages)\n let you bind strongly attested identities to your Compute Engine and\n GKE workloads.\n\nThe types of identities that you can use for workloads and the way that you\nconfigure them depends on where your workloads are running.\n\nConfigure workloads on Google Cloud\n-----------------------------------\n\nIf you're running workloads on Google Cloud, you can use the following\nmethods to configure identities for your workloads:\n\n- Attached service accounts\n- Workload Identity Federation for GKE (for workloads running on Google Kubernetes Engine only)\n- Managed workload identities (for workloads that run on Compute Engine and GKE only)\n- Service account keys\n\n### Attached service accounts\n\n\nFor some Google Cloud resources, you can specify a user-managed service account that the\nresource uses as its default identity. This process is known as *attaching* the service\naccount to the resource, or *associating* the service account with the resource.\n\n\nWhen code running on the resource accesses Google Cloud services and resources, it uses the\nservice account attached to the resource as its identity. For example, if you [attach a\nservice account to a Compute Engine instance](/compute/docs/access/service-accounts#associating_a_service_account_to_an_instance), and the applications on the instance use a [client library](/apis/docs/client-libraries-explained) to call Google Cloud APIs,\nthose applications automatically use the attached service account for authentication and\nauthorization.\n\nIn most cases, you must attach a service account to a resource when you create\nthat resource. After the resource is created, you cannot change which service\naccount is attached to the resource. Compute Engine instances are an\nexception to this rule; you can change which service account is attached to an\ninstance as needed.\n\nTo learn more, see [Attach a service account to a resource](/iam/docs/attach-service-accounts).\n\n### Workload Identity Federation for GKE\n\nFor workloads that run on GKE, Workload Identity Federation for GKE lets you\ngrant IAM roles to distinct, fine-grained sets of principals, for\neach application in your cluster. Workload Identity Federation for GKE lets Kubernetes\nservice accounts in your GKE cluster access Google Cloud\nresources directly, by using Workload Identity Federation, or indirectly,\nby using IAM service account impersonation.\n\nBy using direct resource access, you can grant IAM roles to the\nKubernetes service account identity directly on the Google Cloud service's\nresources. Most Google Cloud APIs support direct resource access. However,\nwhen using identity federation, certain API methods might have limitations. For\na list of these limitations, see [Supported products and limitations](/iam/docs/federated-identity-supported-services).\n\nAs an alternative, workloads can also use service account impersonation, where\nthe configured Kubernetes ServiceAccount is bound to an IAM\nservice account, which serves as the identity when accessing Google Cloud\nAPIs.\n\nTo learn more about GKE Workload Identity Federation for GKE, see\n[Workload Identity Federation for GKE](/kubernetes-engine/docs/concepts/workload-identity).\n\n### Managed workload identities\n\n|\n| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the\n| General Service Terms section of the\n| [Service Specific Terms](/terms/service-terms#1).\n| Pre-GA features are available \"as is\" and might have limited support. For more\n| information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nManaged workload identities let you bind strongly attested identities to your\nCompute Engine and GKE workloads. You can use managed\nworkload identities to authenticate your workloads to other workloads using\n[mTLS](https://en.wikipedia.org/wiki/Mutual_authentication).\n\nTo learn more about managed workload identities, and how to configure platforms\nto use them, see [Managed workload identities overview](/iam/docs/managed-workload-identity).\n\nConfigure external workloads\n----------------------------\n\nIf you're running workloads outside of Google Cloud, you can use the\nfollowing methods to configure identities for your workloads:\n\n- Workload Identity Federation\n- Service account keys\n\n### Workload Identity Federation\n\nYou can use Workload Identity Federation with workloads on\nGoogle Cloud or external workloads that run on platforms such as AWS,\nAzure, GitHub, and GitLab.\n\nWorkload Identity Federation lets you use credentials from external identity\nproviders like [AWS, Azure](/iam/docs/workload-identity-federation-with-other-clouds), and [Active Directory](/iam/docs/workload-identity-federation-with-active-directory)\nto generate short-lived credentials, which workloads can use to temporarily\nimpersonate service accounts. Workloads can then access Google Cloud\nresources, using the service account as their identity.\n\nWorkload Identity Federation is the preferred way to configure identities for\nexternal workloads.\n\nTo learn more about Workload Identity Federation, see\n[Workload Identity Federation](/iam/docs/workload-identity-federation).\n\n### Service account keys\n\n\nA service account key lets a workload authenticate as a service account, then\nuse the service account's identity for authorization.\n| **Note:** Service account keys are a security risk if not managed correctly. You should [choose a more secure alternative to service account keys](/docs/authentication#auth-decision-tree) whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by [Best practices for managing service account keys](/iam/docs/best-practices-for-managing-service-account-keys). If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see [Managing secure-by-default organization resources](/resource-manager/docs/secure-by-default-organizations).\n|\n|\n| If you acquired the service account key from an external source, you must validate it before use.\n| For more information, see [Security requirements for externally sourced credentials](/docs/authentication/external/externally-sourced-credentials).\n\n\u003cbr /\u003e\n\nLocal development\n-----------------\n\nIf you're developing in a local environment, you can configure workloads to use\neither your user credentials or a service account for authentication and\nauthorization. For more information, see\n[Local development environment](/docs/authentication/set-up-adc-local-dev-environment) in the authentication documentation.\n\nWhat's next\n-----------\n\n- Learn how to [set up authentication by using service accounts](/docs/authentication#service-accounts).\n- Learn how to [set up authentication for a local development environment](/docs/authentication/set-up-adc-local-dev-environment).\n- Learn how to [grant service accounts access to resources](/iam/docs/granting-changing-revoking-access)."]]
