Google Associate Cloud Engineer – Organizations and IAM – Organizing Google Cloud Resources Part 3

14. Step 12 – Exploring IAM Predefined Roles – Google Cloud BigQuery

Come back in this step, let’s look at the different roles related to BigQuery. Whenever we talk about BigQuery, when we talk about BigQuery, there are two kinds of operations. One is to play with the data. The other ones are related to executing queries. And you would see a wide variety of roles offering a clear distinction between these two operations. Let’s look at the roles right now. BigQuery admin can do everything on BigQuery. BigQuery data Owner he has access to data sets, models, routines and tables. However, he does not have access to jobs. Jobs are where you actually run your queries. Data owner has access to data, but not to jobs. Data editor, on the other hand, has access to edit the data so he can perform a number of operations on tables, models, routines and data sets.

Data editor also does not have any access to jobs. Data viewer has view access on the data only. He does not have any access on the jobs. Job user, on the other hand, can create jobs. So a job user can run queries. A BigQuery user has BigQuery Data viewer permissions, that is, to list all the data. And he can also list all the jobs he can and look at all the details and the reservations related to the queries which are running. To see data, you need roles like BigQuery user or BigQuery data viewer. You cannot see the data with BigQuery job user role, BigQuery data owner or Data viewer roles do not have access to jobs. In this step, we looked at some of the important roles related to BigQuery. I’ll see you in the next step.

15. Step 13 – Exploring IAM Predefined Roles – Logging and Service Accounts

Next step, let’s look at some of the important roles related to logging and service account. Logging and Audit logging if you have the logs viewer role, you can read all the logs except access transparency logs and data access audit Logs if you have the Role private logs viewer, you get all the accesses that logs viewer role has. Plus you can also read transparency currency logs and data access audit Logs a logging admin has all permissions related to logging. He can look at all the logs. Now, let’s look at service accounts. A service account admin can create and manage service accounts. A service account user can run operations as a service account, so you can create and manage instances that use a service account.

So if you have this role, you can create and manage instances that use this service account. If you want your admin roles to be able to create instances with that service account, then this permission the Im service account user permission, needs to be added to your admin roles. Earlier, we talked about creating tokens for your service accounts. Creating or Tokens or JWT Tokens and you’d be able to create tokens only if you have the service account token. Creator Role the last one is the creation of the service account keys. You’ll be able to create service account keys only if you have the service account key. Admin Role in this step, we looked at some of the important roles related to logging and service accounts. I’ll see you in the next step.

16. Step 14 – Other Important IAM Roles

Welcome back. In a separate, let’s look at a few other important im roles. If you want to be able to set IAM policy then you need to have Security admin role. If you want to list all the resources and the im policies, you need to have a security reviewer role security reviewer will not be able to change. He’ll only be able to list. If you have an Organization role admin, you’ll able to administer all the custom roles in a specific organization and the projects below it. Earlier we talked about three kinds of roles basic predefined and custom customer roles you create and if you want to be able to administer custom roles, you need to be an Organization Role admin. If you have Organization Role Viewer permissions then you’d be able to read all the custom roles but you will not be able to make changes to it.

If you want to give access to specific custom roles which are present in a project, then you can give them access to Role admin. Role Viewer on the other hand gives you only read access. One important thing to note is the difference organization Role Viewer role Viewer organization Role Admin role Admin organization Role Admin is on the organization Role Admin is on a project. Same is the case with organization Role Viewer. And Role Viewer. Organization role. Viewer is on the organization. An organization might contain n number of projects in those projects. If you want to control access to a specific project, you can use Role Viewer if you want to give him access to every project in an organization view access you can give Organization Role Viewer.

The last one is role slash browser. This provides you with read access to browse the hierarchy for a project. Whenever we talk about a project, the hierarchy is organization folder projects and at all these levels you can configure im policies. A browser has read access to every one of the things that we have talked right now. So you can see what is the organization, what are the folders that are present in there, what are the projects which are present in each of these folders and he can review the policies at each of these levels. However, this will not give you any permissions to view resources in the project. He can only see the policies, the structure, but he will not be able to go and see, let’s say a compute engine or a storage bucket.

17. Step 15 – SSHing into Linux VMs – 1

Welcome back in this and the next step, let’s dig deeper into SSHing, into Linux VMs. What are the different options? Compute Engine, Linux VMs use key based SSH authentication, private key and public key. Those are the things that are used to enable SSH authentication into your Compute Engine linux virtual machines. Now, whenever we talk about keys, we need to manage the these keys. How do you manage these keys? There are two different options that are provided by Compute Engine. Number one is Metadata Managed where you’d actually manually create and configure individual SSH keys. The other option is OS login where you can actually manage SSH access without managing individual SSH keys.

Now, what is the difference? When we are talking about metadata managed. The place where we would manage the SSH keys is inside Compute Engine Settings metadata. You can go in here and configure SSH keys. You can configure the specific SSH key and the username. If you want, you can add more SSH keys. So this is how you can actually manage this is how you can actually manage access to the virtual machines that are created as part of your Compute Engine over here you are individually managing all the SSH keys in metadata SSH keys and that’s why it’s called Metadata Managed. The other option is OS login. You don’t want to manage individual SSH keys.

Whenever we have a lot of users across different projects making use of thousands of instances, OS login is recommended. What would happen when we are using OS login is your Linux account is automatically linked to your Google identity and therefore you can start using your Google identity to manage your permissions. The way you can enable OS login is by enabling something in metadata. So you need to go to metadata of your project and set enable OS login to True. So you can go to metadata and you can say add metadata and I can say Enable OS login to true and that would enable OS login. And once you enable OS login we will not be using Metadata managed SSH keys, we would be using OS login.

This enabling of OS login can also be done through Gcloud, gcloud Compute Project Info, add metadata and in the metadata we would want to enable OS login to True. Instead of enabling OS login at project level, you can also enable at a specific instance level. So you can go to a specific VM instance and enable OS login for that specific instance. The biggest advantage of going for the OS login approach is you can import your existing Linux accounts from on premises Active Directory and LDAP. So if you have Linux accounts which are present on premises, you can use those and you can give access directly to those users when you’re using OS login, however, very important thing to remember is that these users need to have the right roles on the resources.

If you want a user to be able to log in with normal users then they need to have the Compute OS login role. If you’d want them to be logging in as root then you need to give them Compute OS admin login. Until now we have been talking about Linux machines. These use key based authentication. However, if you create Compute engine virtual machines with Windows as the OS those instances will use password based authentication. You’ll have a username and password. You can manage the password either using Console or by g cloud. For example gcloud compute reset Windows password.

But the important thing to remember is that Linux VMs key based authentication windows password based authentication and when you are using key based authentication for Linux VMs you have two options metadata managed and OS login. If you don’t really want to manage all the individual SSH keys in metadata and use that to provide access you can go for OS login. This is where you are actually linking your Linux user accounts to provide access to virtual machines. Let’s talk a little bit more about this in the next step. I’ll see you in the next step.

18. Step 16 – SSHing into Linux VMs – 2

Back in the step. Let’s dig deeper into SSHing into Linux VMs. Let’s see how you can actually SSH into Linux VMs until now. What is the option that we use to SSH into Linux VMs? All that we did is we went to the VM instance and clicked the SSH button. That’s the option one console SSH button. This can be done whether you are using Metadata based or OS OS login based. All the approaches that we would be talking about right now can be used irrespective of whether you’re using Metadata Managed or you have enabled OS login. If you are using the SSH button in the console in the background, what would happen is a temporary ephemeral SSH key pair is created by Compute engine and that is what is used to login into the SSH button.

You are already authenticated because you are already logged into the Google Cloud platform and then you are clicking SSH button. A temporary SSH keypad is created and that is what is used by Compute Engine to allow you to log in into the virtual machine. The other option you have is also to execute a command. The command is gcloud compute SSH. So you can use Gcloud Compute SSH command to SSH into your Linux VM. And when you do a Gcloud compute SSH, what would happen is a user name and a persistent SSH key pair are created by the Compute engine. And whenever you execute the command again from the same machine again, the same SSH key pair will be reused. So when we are using the SSH button in Console, a temporary SSH key pair is created.

However, when we are using gcloud compute. SSH, then a persistent SSH key pair is created and that is what is reused for further interactions from the same machine. So these are the two easiest options. Either go to Console, click the SSH button or execute Gcloud compute SSH. The other option is also to customize your own SSH keys and use the key to login. So you can go to metadata managed. If you’re using Metadata Managed keys, then you can go in here, configure your SSH key in here and then you can use that SSH key to log in. Or if you’re using OS login, you can upload your public SSH key to your OS login profile. How can you do that? The first option of how you can do that is by using Gcloud.

So you can say gcloud compute OS login SSH keys add, so you are associating your login with an SSH key. The other option is to use OS login API. So there is an API which you can use to add a SSH key. So this option three is where you are uploading your own SSH key and you are using that to SSH into a virtual machine. Typically the mostly used options are option One and option two. The key difference between OS login and Metadata Managed when it comes to option three is the fact that with metadata managed, all the public keys are uploaded to a centralized place which is in metadata SSH keys. However, when it comes to OS login, each user can individually maintain his OS login profile.

So this is centralized, whereas this is individualized. Each individual can maintain his own SSH keys. And that’s the reason why OS login is typically considered to be easier to implement when you have thousands of users because they can manage their own keys in the step. Until now we talked about the different options that you can use to SSH into Linux VMs. You can either use the console g cloud or you can customize your SSH keys, configure them, and you can use an SSH client with the key to login into a virtual machine. We talked about the fact that metadata based that’s basically configuring the SSH keys over here is a centralized kind of an approach.

Once you have a key in here and you’re using metabatabased authentication, then you can use this user to log in into any virtual machine that is created in this specific project. However, you can disable project wide SSH keys on specific compute instance. If on a specific compute instance I don’t want to use the keys which are configured in here, you can disable project wide SSH keys as well. The way you can do that is by saying gcloud compute instances, add metadata the specific instance name and you can add metadata saying block project SSH keys is equal to true. In the last few steps we looked at SSHing into Linux VMs. I’m sure you’re having a wonderful time and I’ll see you in the next step.

19. Step 17 – Exploring IAM Scenarios

Welcome back. Let’s look at a few scenarios related to IAM. You want to give permanent access to a subset of objects in a cloud storage bucket to a user. How can you do that? You can use ACLs because there are subset of objects, we cannot use IAM. We have to use ACL. You want to give permanent access to entire bucket in cloud storage bucket, this is where you can go for IAM. You want to provide time limited access to a specific object. In cloud storage object, important thing is time limited access. Once you use ACL or Im, the access is permanent. It is not time limited. If you want time limited access, you’d go for signed URL. You want to give access to a set of resources to your development team.

The best way is to create a group with your development team as the members. And then you can bind you can create a policy binding the right roles to the right group. Let’s look at a few example scenarios related to roles. You need to decide what role you would use when you want to upload objects to cloud storage. One of the most important principles to apply is the minimum privileged principle. If I would want to upload objects to cloud storage, I can give them cloud storage admin, or I can say cloud storage object admin, but those would give them too much permission. If I just want to do upload objects to cloud storage, the best permission to give is storage object created. So they don’t need to be a storage object admin or a storage admin.

If you just give them permission to storage object created, that should be sufficient. Manage kubernetes API objects? Typically, who would manage the kubernetes API objects? API objects are nothing but deployments services. So who would be actually making deployments and the services? Typically somebody in your DevOps team. Right? And that’s the role as well. Kubernetes Engine Developer if you give Kubernetes admin role, they’ll be able to manage everything on Kubernetes. Let’s say you would want to manage the service account. What’s recommended role? Recommended role is service account admin let’s say you want to view data in BigQuery.

The role is BigQuery Data viewer. Now, the important thing is not remember every one of these roles. Remembering each one of these roles is really, really difficult. I know that the important thing you should be able to distinguish between is the different roles which are present for each service. You should be able to look at options where there are multiple BigQuery roles and identify the specific role in the exam. They will not be asking for an answer. They will be asking you to choose between a few roles. So you should be able to look at all the roles, identify the right one for the right purpose. I’m sure you’re having a wonderful time, and I’ll see you in the next step.

• Category: Uncategorized