Security and Access management
In this we will learn and understand about IAM Security and access management.
However, with IAM, you manage access control by defining who (identity) has what access (role) for which resource. For example, Compute Engine virtual machine instances, Google Kubernetes Engine (GKE) clusters, and Cloud Storage buckets are all Google Cloud resources. Further, in IAM, permission to access a resource isn’t granted directly to the end user. Instead, permissions are grouped into roles, and roles are granted to authenticated members. An IAM policy defines and enforces what roles are granted to which members. However, this policy is attached to a resource. When an authenticated member attempts to access a resource, IAM checks the resource’s policy to determine whether the action is permitted.
Concepts related to identity
In IAM, you grant access to members. Members can be of the following types:
Google Account
A Google Account represents a developer, an administrator, or any other person who interacts with Google Cloud. Any email address that’s associated with a Google Account can be an identity, including gmail.com or other domains. Further, new users can sign up for a Google Account by going to the Google Account signup page.
Service account
A service account is an account for an application instead of an individual end user. When you run code that’s hosted on Google Cloud, the code runs as the account you specify. However, you can create as many service accounts as needed to represent the different logical components of your application.
Google group
A Google group is a named collection of Google Accounts and service accounts. Every Google group has a unique email address that’s associated with the group. However, you can find the email address that’s associated with a Google group by clicking About on the homepage of any Google group. Further, Google Groups are a convenient way to apply an access policy to a collection of users. You can grant and change access controls for a whole group at once instead of granting or changing access controls one at a time for individual users or service accounts.
Google Workspace domain
A Google Workspace domain represents a virtual group of all the Google Accounts that have been created in an organization’s Google Workspace account. However, Google Workspace domains represent your organization’s internet domain name (such as example.com). Further, when you add a user to your Google Workspace domain, a new Google Account is created for the user inside this virtual group.
All authenticated users
The value allAuthenticatedUsers is a special identifier that represents all service accounts and all users on the internet who have authenticated with a Google Account. This identifier includes accounts that aren’t connected to a Google Workspace or Cloud Identity domain, such as personal Gmail accounts. Users who aren’t authenticated, such as anonymous visitors, aren’t included.
Concepts related to access management
When an authenticated member attempts to access a resource, IAM checks the resource’s IAM policy to determine whether the action is allowed.
Resource
If a user needs access to a specific Google Cloud resource, you can grant the user a role for that resource. Some examples of resources are projects, Compute Engine instances, and Cloud Storage buckets. However, some services support granting IAM permissions at a granularity finer than the project level. For example, you can grant the Storage Admin role (roles/storage.admin) to a user for a particular Cloud Storage bucket, or you can grant the Compute Instance Admin role (roles/compute.instanceAdmin) to a user for a specific Compute Engine instance.
Permissions
Permissions determine what operations are allowed on a resource. In the IAM world, permissions are represented in the form of service.resource.verb, for example, pubsub.subscriptions.consume. Further, permissions often correspond one-to-one with REST API methods. That is, each Google Cloud service has an associated set of permissions for each REST API method that it exposes. The caller of that method needs those permissions to call that method. For example, if you use Pub/Sub, and you need to call the topics.publish() method, you must have the pubsub.topics.publish permission for that topic.
Roles
A role is a collection of permissions. You cannot grant a permission to the user directly. Instead, you grant them a role. When you grant a role to a user, you grant them all the permissions that the role contains. However, there are several kinds of roles in IAM:
- Firstly, Basic roles. Roles historically available in the Google Cloud Console. These roles are Owner, Editor, and Viewer.
- Secondly, Predefined roles. Roles that give finer-grained access control than the basic roles. For example, the predefined role Pub/Sub Publisher (roles/pubsub.publisher) provides access to only publish messages to a Pub/Sub topic.
- Lastly, Custom roles. Roles that you create to tailor permissions to the needs of your organization when predefined roles don’t meet your needs.
Reference: Google Documentation