Ao criar um projeto do Google Cloud, você é o único usuário no projeto. Por
padrão, nenhum outro usuário tem acesso ao seu projeto ou recursos dele, incluindo
os recursos do Google Kubernetes Engine (GKE). O GKE é compatível com várias
opções para gerenciar o acesso a recursos no projeto e nos clusters dele
usando o controle de acesso baseado em papéis (RBAC, na sigla em inglês).
Esses mecanismos têm algumas funções semelhantes, mas são direcionados para diferentes tipos de recursos. Cada um é explicado em uma das seções abaixo. No entanto, estas são algumas características:
O RBAC do Kubernetes é incorporado ao Kubernetes e concede permissões granulares a objetos nos clusters do Kubernetes. As permissões existem como objetos ClusterRole ou Role no cluster. Os objetos RoleBinding concedem papéis a usuários do Kubernetes, usuários do Google Cloud, contas de serviço do IAM ou Grupos do Google.
Se você usa principalmente o GKE e precisa de permissões refinadas para cada objeto e operação no cluster, o RBAC do Kubernetes é a melhor escolha.
O IAM gerencia recursos do Google Cloud, incluindo
clusters e tipos de objetos dentro deles. As permissões são atribuídas aos
participantes do IAM.
Não há mecanismo para conceder permissões a objetos específicos do Kubernetes
no IAM. Por exemplo, é possível conceder permissão a um usuário para criar CustomResourceDefinitions (CRDs). No entanto,
isso não é possível para criar somente uma CustomResourceDefinition em particular ou limitar
a produção a um namespace individual ou a um cluster especial no projeto.
Se aplicado no nível da pasta, um papel do IAM concede privilégios a todos os clusters no
projeto ou em todos
os projetos filho.
Se você usa vários componentes do Google Cloud e não precisa gerenciar
permissões granulares específicas do Kubernetes, o IAM é recomendável.
Kubernetes RBAC
O Kubernetes conta com suporte integrado para RBAC, o que permite criar papéis específicos que existem no cluster do Kubernetes. É possível definir o escopo de um papel para um objeto específico do Kubernetes ou um tipo de objeto do Kubernetes. Também é possível definir quais ações (chamadas de verbos) o papel concede em relação a esse objeto. Um RoleBinding também é um objeto do Kubernetes que concede papéis aos usuários. Em um usuário do GKE, pode ser qualquer um dos seguintes:
O IAM permite conceder papéis aos
principais. Um papel é
um conjunto de permissões e, quando atribuído a um principal, controla o acesso a
um ou mais recursos do Google Cloud. Você
pode usar os seguintes tipos de papéis:
Papéis básicos fornecem permissões gerais
limitadas a Proprietário, Editor e Leitor.
Papéis predefinidos, como
os
do GKE,
fornecem acesso mais restrito do que papéis básicos e abordam muitos casos de
uso comuns.
Permitir políticas: atribua papéis aos principais. Para detalhes, consulte a
Política de permissão.
Políticas de negação: impedem que os principais usem permissões
específicas do IAM, independentemente dos papéis atribuídos a eles. Para
mais detalhes, consulte as Políticas de negação.
Use as políticas de negação para impedir que principais específicos executem ações
específicas no projeto, pasta ou organização, mesmo que uma política de permissão do IAM
conceda a esses principais um papel que contenha as permissões
relevantes.
Recomendações de IAM
Use os seguintes papéis predefinidos do IAM para facilitar
cenários comuns:
Leitor de cluster do Kubernetes Engine (roles/container.clusterViewer): DevOps,
engenheiros e desenvolvedores de aplicativos que só precisam se conectar ao
cluster.
Administrador de cluster do Kubernetes Engine (roles/container.clusterAdmin): administradores
de plataforma e operadores de cluster que precisam gerenciar um ou mais clusters
em um projeto do Google Cloud.
Além disso, considere criar uma conta de serviço do IAM personalizada para
seus nós usarem em vez da conta de serviço padrão do Compute Engine.
Conceda à conta de serviço personalizada as permissões mínimas necessárias para o funcionamento do GKE. Para mais instruções, consulte Usar contas de serviço IAM de privilégio mínimo.
Interação do IAM com o Kubernetes RBAC
O IAM e o RBAC do Kubernetes trabalham juntos para ajudar a gerenciar o
acesso ao cluster. O RBAC controla o acesso no nível do cluster e do namespace, enquanto o
IAM funciona no nível do projeto. Uma entidade precisa ter permissões suficientes em qualquer nível para trabalhar com recursos no cluster.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-11-26 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)."]]
