1. Overview
    1. When a project is created, by default, no other users have access to a project or its resources, including Google Kubernetes Engine resources
    2. Google Kubernetes Engine supports Cloud Identity and Access Management (Cloud IAM) and Kubernetes role-based access control (RBAC) for managing access to resources within project and its clusters using role-based access control (RBAC)
    3. Cloud IAM and RBAC mechanisms have some functional overlap, but are targeted to different types of resources
  2. Cloud IAM
    1. Cloud IAM manages Google Cloud resources, including clusters, and types of objects within clusters
    2. Cloud IAM allows users to define roles and assign them to members
    3. A Role is a collection of permissions, and when assigned to a member, controls access to one or more Google Cloud resources.
    4. Permissions are assigned to Cloud IAM members, which exist within Google Cloud, G Suite, or Cloud Identity
    5. Primitive roles provide coarse permissions limited to Owner, Editor, and Viewer
    6. Pre-defined roles, such as the pre-defined roles for GKE, provide finer-grained access than primitive roles and address many common use cases
    7. Custom roles allow users to create unique combinations of permissions
    8. Cloud IAM can be used to create and configure service accounts
    9. Service accounts are assigned roles and permissions in the same way as human users
    10. There is no mechanism for granting permissions for specific Kubernetes objects within Cloud IAM
    11. A Cloud IAM role grants privileges across all clusters in the project, or all clusters in all child projects if the role is applied at the folder level
    12. Where multiple Google Cloud components are used and users don't need to manage granular Kubernetes-specific permissions, Cloud IAM is a good choice
  3. RBAC
    1. Kubernetes has built-in support for RBAC that allows users to create fine-grained Roles within Kubernetes clusters
    2. A Role can be scoped to a specific Kubernetes object or a type of Kubernetes object
    3. A Role defines which actions (called verbs) the Role grants in relation to that object
    4. Permissions exist as ClusterRole or Role objects within the cluster
    5. RoleBinding objects grant Roles to Kubernetes users
    6. GKE user can be any of Google Cloud user, Google Cloud service account, Kubernetes service account, G Suite user or G Suite Google Group
    7. Where GKE is primarily used, and there is a need for fine-grained permissions for every object and operation within a cluster, Kubernetes RBAC is the best choice