Cuando creas un proyecto de Google Cloud, eres el único usuario en el proyecto. De forma predeterminada, ningún otro usuario tiene acceso a tu proyecto ni a sus recursos, incluidos los recursos de Google Kubernetes Engine (GKE). GKE admite varias opciones para administrar el acceso a los recursos de tu proyecto y sus clústeres mediante el control de acceso según el rol (RBAC).
Estos mecanismos se superponen en cuanto a sus funciones en cierto punto, pero están dirigidos a diferentes tipos de recursos. Cada uno se explica de forma breve en una sección que se incluye a continuación:
El RBAC de Kubernetes está incorporado en Kubernetes y otorga permisos detallados a los objetos dentro de los clústeres de Kubernetes. Los permisos existen como objetos Role o ClusterRole dentro del clúster. Los objetos RoleBinding otorgan roles a
usuarios de Kubernetes, usuarios de Google Cloud, cuentas de servicio de IAM o Grupos de Google.
Si usas GKE y necesitas permisos específicos para cada objeto y operación dentro de tu clúster, el RBAC de Kubernetes es la mejor opción.
IAM administra los recursos de Google Cloud, incluidos los clústeres y los tipos de objetos dentro de los clústeres. Los permisos se asignan a las principales de IAM.
No existe un mecanismo con el que se otorguen permisos para objetos de Kubernetes específicos dentro de IAM. Por ejemplo, puedes otorgar a un usuario permiso para crear CustomResourceDefinitions (CRD), pero no puedes otorgarle permiso a fin de crear solo una CustomResourceDefinition específica, ni limitar la creación a un espacio de nombres específico o a un clúster específico en el proyecto.
Una función de IAM otorga privilegios en todos los clústeres del proyecto o en todos los clústeres de todos los proyectos secundarios si la función se aplica a nivel de carpeta.
Si usas varios componentes de Google Cloud y no necesitas administrar permisos específicos detallados de Kubernetes, IAM es una buena opción.
RBAC de Kubernetes
Kubernetes cuenta con compatibilidad integrada para RBAC. Esto te permite crear funciones detalladas, que existen dentro del clúster de Kubernetes. Una función puede aplicarse a un objeto de Kubernetes específico o a un tipo de objeto de Kubernetes, y define qué acciones (llamadas verbos) otorga la función en relación con ese objeto. Un RoleBinding también es un objeto de Kubernetes y otorga funciones a los usuarios. Un usuario de GKE puede ser cualquiera de las siguientes opciones:
IAM te permite otorgar roles a las principales. Una función es una colección de permisos, y cuando se le asigna a una principal, controla el acceso a uno o más recursos de Google Cloud. Puedes usar los siguientes tipos de roles:
Las funciones básicas proporcionan permisos generales limitados a permisos de propietario, de editor y de visualizador.
Una principal puede ser cualquiera de las siguientes opciones:
Cuenta de usuario
Cuenta de servicio
Grupo de Google de Google Workspace
Dominio de Google Workspace
Dominio de Cloud Identity
Tipos de políticas de IAM
IAM admite los siguientes tipos de políticas:
Políticas de permisos: Otorga roles a las principales. Para obtener más información, consulta Política de permisos.
Políticas de denegación: Evita que las principales usen permisos de IAM específicos, sin importar las funciones que se les otorguen. Para obtener más detalles, consulta Políticas de denegación.
Usa políticas de denegación para evitar que principales específicas realicen acciones específicas en tu proyecto, organización o carpeta, incluso si una política de permisos de IAM otorga a esas principales un rol que contenga los permisos relevantes.
Recomendaciones de IAM
Considera usar las siguientes funciones predefinidas de IAM para facilitar situaciones comunes:
Administrador de clústeres de Kubernetes Engine (roles/container.clusterAdmin): Los administradores de plataformas y operadores de clústeres que necesitan administrar uno o más clústeres en un proyecto de Google Cloud.
Para obtener una lista de los roles predefinidos de IAM disponibles, consulta Roles predefinidos de GKE.
Además, considera crear una cuenta de servicio de IAM personalizada
que usen tus nodos en lugar de la cuenta de servicio predeterminada de Compute Engine.
Otorga a la cuenta de servicio personalizada los permisos mínimos necesarios
para que GKE funcione. Para obtener instrucciones, consulta
Usa cuentas de servicio de IAM con privilegios mínimos.
Interacción de IAM con RBAC de Kubernetes
IAM y RBAC de Kubernetes trabajan juntos para ayudar a administrar el acceso a tu clúster. RBAC controla el acceso en el nivel de clúster y espacio de nombres, mientras que IAM funciona en el nivel de proyecto. Una entidad debe tener permisos suficientes en cualquier nivel para trabajar con recursos en tu clúster.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2024-06-25 (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)."]]
