이 페이지에서는 Google Kubernetes Engine의 Identity and Access Management(IAM)와 Kubernetes 역할 기반 액세스 제어(RBAC)의 차이점을 설명하여 프로젝트 내 리소스에 대한 액세스를 관리하는 데 도움을 줍니다.
이 페이지는 권한 액세스를 제어하고 IAM과 RBAC의 차이점과 공통점을 이해하려는 보안 전문가를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.
Google Cloud 프로젝트를 만들면 만든 사람이 프로젝트의 유일한 사용자가 됩니다. 기본적으로 다른 사용자는 Google Kubernetes Engine(GKE) 리소스를 비롯해 프로젝트나 프로젝트 리소스에 액세스할 수 없습니다. GKE는 역할 기반 액세스 제어(RBAC)를 사용하여 프로젝트 및 클러스터 내의 리소스에 대한 액세스를 관리하는 여러 가지 옵션을 지원합니다.
이들 메커니즘의 일부는 기능적으로 중복되지만 서로 다른 유형의 리소스를 대상으로 합니다. 각각 이 페이지의 전용 섹션에서 설명하지만 간단히 살펴보면 다음과 같습니다.
Kubernetes에서 기본 제공되는 Kubernetes RBAC는 Kubernetes 클러스터 내 객체에 세분화된 권한을 부여합니다. 이러한 권한은 클러스터 내 ClusterRole 객체 또는 Role 객체로 존재합니다. RoleBinding 객체는Kubernetes 사용자, Google Cloud 사용자, IAM 서비스 계정 또는 Google 그룹스에 역할을 부여합니다.
주로 GKE를 사용하고 클러스터 내 모든 객체 및 작업에 세분화된 권한이 필요한 경우 Kubernetes RBAC를 사용하는 것이 가장 좋습니다.
IAM은 클러스터 및 클러스터 내 객체 유형을 포함한 Google Cloud 리소스를 관리합니다. 권한은 IAM 주 구성원에게 할당됩니다.
IAM 내의 특정 Kubernetes 객체에 권한을 부여하는 메커니즘은 없습니다. 예를 들어 사용자에게 CRD(CustomResourceDefinition)를 만들 수 있는 권한을 부여할 수 있지만 특정 CustomResourceDefinition 한 개만 만들 수 있는 권한을 부여할 수는 없습니다. 또한 프로젝트의 특정 클러스터 또는 특정 네임스페이스로 생성을 제한할 수도 없습니다.
IAM 역할은 프로젝트의 모든 클러스터 또는 모든 하위 프로젝트의 모든 클러스터(역할이 폴더 수준에서 적용되는 경우)에 권한을 부여합니다.
여러 Google Cloud 구성요소를 사용하면서 세분화된 Kubernetes 관련 권한을 관리할 필요가 없으면 IAM을 사용하는 것이 좋습니다.
Kubernetes RBAC
Kubernetes에는 Kubernetes 클러스터 내에 있는 세분화된 역할을 만들 수 있는 RBAC 지원 기능이 기본 제공됩니다. 역할은 특정 Kubernetes 객체 또는 특정 유형의 Kubernetes 객체를 대상으로 할 수 있으며 지정된 객체와 관련하여 역할에서 부여하는 작업(동사라고 함)을 정의합니다. RoleBinding도 Kubernetes 객체이며 사용자에게 역할을 부여합니다. GKE에서 사용자는 다음 중 하나일 수 있습니다.
GKE는 노드에 연결된 IAM 서비스 계정을 사용하여 로깅 및 모니터링과 같은 시스템 태스크를 실행합니다. 이러한 노드 서비스 계정에는 프로젝트에 대한 Kubernetes Engine 기본 노드 서비스 계정(roles/container.defaultNodeServiceAccount) 역할이 있어야 합니다. 기본적으로 GKE는 프로젝트에 자동으로 생성되는 Compute Engine 기본 서비스 계정을 노드 서비스 계정으로 사용합니다.
Kubernetes RBAC와 IAM 상호작용
IAM과 Kubernetes RBAC는 함께 작동하여 클러스터에 대한 액세스를 관리하는 데 도움이 됩니다. RBAC는 클러스터 및 네임스페이스 수준에서 액세스를 제어하는 반면 IAM은 프로젝트 수준에서 작동합니다. 개체가 클러스터의 리소스를 사용하기 위해서는 어느 수준에서든 충분한 권한을 보유해야 합니다.
[[["이해하기 쉬움","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-06-24(UTC)"],[],[],null,["# Access control\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page explains the differences between Identity and Access Management (IAM) and\nKubernetes role-based access control (RBAC) in Google Kubernetes Engine to help you manage\naccess to resources within your project.\n\nThis page is for\nSecurity specialists who control access to permissions and want to understand\nthe differences and overlap between IAM and RBAC. To learn more about\ncommon roles and example tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nWhen you create a Google Cloud project, you are the only user on the project. By\ndefault, no other users have access to your project or its resources, including\nGoogle Kubernetes Engine (GKE) resources. GKE supports multiple\noptions for managing access to resources within your project and its clusters\nusing role-based access control (RBAC).\n\nBefore reading this page, ensure that you're familiar with the following:\n\n- [General overview of IAM in GKE](/kubernetes-engine/docs/how-to/iam)\n- [General overview of Kubernetes RBAC](/kubernetes-engine/docs/how-to/role-based-access-control)\n\nThese mechanisms have some functional overlap, but are targeted to different\ntypes of resources. Each is explained in a dedicated section on this page, but in brief:\n\n- [Kubernetes RBAC](#rbac) is built into Kubernetes, and grants granular\n permissions to objects within Kubernetes clusters. Permissions exist as\n ClusterRole or Role objects within the cluster. RoleBinding objects grant\n Roles to\n\n Kubernetes users, Google Cloud users, IAM\n service accounts, or\n [Google Groups](/kubernetes-engine/docs/how-to/role-based-access-control#google-groups-for-gke).\n\n If you primarily use GKE, and need fine-grained permissions\n for every object and operation within your cluster, Kubernetes RBAC is the\n best choice.\n- [IAM](#iam) manages Google Cloud resources, including\n clusters, and types of objects within clusters. Permissions are assigned to\n IAM *principals*.\n\n There is no mechanism for granting permissions for specific Kubernetes objects\n within IAM. For instance, you can grant a user permission to\n create CustomResourceDefinitions (CRDs), but you can't grant the user\n permission to create only one specific CustomResourceDefinition, or limit\n creation to a specific Namespace or to a specific cluster in the project.\n An IAM role grants privileges across all clusters in the\n project, or all clusters in all child projects if the role is applied at the\n folder level.\n\n If you use multiple Google Cloud components and you don't need to manage\n granular Kubernetes-specific permissions, IAM is a good choice.\n\nKubernetes RBAC\n---------------\n\nKubernetes has built-in support for RBAC that allows you to create fine-grained\nRoles, which exist within the Kubernetes cluster. A Role can be scoped to a\nspecific Kubernetes object or a type of Kubernetes object, and defines which\nactions (called verbs) the Role grants in relation to that object. A RoleBinding\nis also a Kubernetes object, and grants Roles to users. A\nGKE user can be any of:\n\n- Google Cloud user\n- IAM service account\n- Kubernetes ServiceAccount\n- Google Workspace user\n- Google Workspace Google Group\n- Users authenticated using [X509 client certificates](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs)\n\nTo learn more, refer to\n[Role-Based Access Control](/kubernetes-engine/docs/how-to/role-based-access-control).\n\nIAM\n---\n\nIAM lets you grant *roles* to *principals* . A role is a\ncollection of permissions, and when granted to a principal, allows that\nprincipal to access one or more Google Cloud\n*resources* . For more information about principals, roles, and other\nIAM terminology, see\n[IAM overview](/iam/docs/overview).\n\nIn GKE, a principal can be any of the following:\n\n- User account\n- Service account\n- Google Workspace Google Group\n- Google Workspace domain\n- Cloud Identity domain\n\nFor more information about using IAM to control access in\nGKE, see\n[Create IAM allow policies](/kubernetes-engine/docs/how-to/iam).\n\n### IAM policy types\n\nIAM supports the following policy types:\n\n- **Allow policies** : grant roles to principals. For details, see [Allow policy](/iam/docs/overview#cloud-iam-policy).\n- **Deny policies** : prevent principals from using specific IAM permissions regardless of the roles that those principals are granted. For details, see [Deny policies](/iam/docs/deny-overview).\n\nUse deny policies to restrict specific principals from performing specific\nactions in your project, folder, or organization even if an IAM\nallow policy grants those principals a role that contains the relevant\npermissions.\n\n### IAM recommendations\n\nConsider using the following IAM predefined roles to facilitate\ncommon scenarios:\n\n- [Kubernetes Engine Cluster Viewer](/iam/docs/understanding-roles#container.clusterViewer) (`roles/container.clusterViewer`): DevOps, engineers, and application developers who only need to connect to the cluster.\n- [Kubernetes Engine Cluster Admin](/iam/docs/understanding-roles#container.clusterAdmin) (`roles/container.clusterAdmin`): Platform administrators and cluster operators who need to manage one or more clusters in a Google Cloud project.\n\nFor a list of the available predefined IAM roles, refer\nto [Predefined GKE roles](/kubernetes-engine/docs/how-to/iam#predefined).\n\n\nGKE uses IAM service accounts that are attached to your nodes to\nrun system tasks like logging and monitoring. At a minimum, these *node service accounts*\nmust have the\n[Kubernetes Engine Default Node Service Account](/iam/docs/understanding-roles#container.defaultNodeServiceAccount)\n(`roles/container.defaultNodeServiceAccount`) role on your project. By default,\nGKE uses the\n[Compute Engine default service account](/compute/docs/access/service-accounts#default_service_account),\nwhich is automatically created in your project, as the node service account.\n| **Best practice:** Instead of using the Compute Engine default service account, create a *custom service account* for your nodes to use and give it only the permissions that GKE needs to run system tasks. For more information, see [Use a least\n| privileged service account](/kubernetes-engine/docs/how-to/hardening-your-cluster#use_least_privilege_sa).\n\nIAM interaction with Kubernetes RBAC\n------------------------------------\n\nIAM and Kubernetes RBAC work together to help manage access to\nyour cluster. RBAC controls access on a cluster and namespace level, while\nIAM works on the project level. An entity must have sufficient\npermissions at either level to work with resources in your cluster.\n\nWhat's next\n-----------\n\n- [Read the GKE security overview](/kubernetes-engine/docs/concepts/security-overview).\n- [Learn how to use Kubernetes RBAC](/kubernetes-engine/docs/how-to/role-based-access-control).\n- [Learn how to create IAM policies for GKE](/kubernetes-engine/docs/how-to/iam).\n- [Learn how to use IAM Conditions for load balancers](/load-balancing/docs/access-control/iam-conditions)."]]
