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

6. Step 04c – Understanding Organization Policy Service

Welcome back in the step. Let’s look at organization, policy, service. Let’s say you want to define centralized constraints on all resources in your organization. What would you do in those situations? You can go for an organization policy. Let’s look at an example. You want to disable creation of service accounts in the entire organization or in a specific project. Or you might want to allow or deny creation of resources in specific regions. You only want to create resources in specific regions. Or you don’t want to allow creation of resources in specific regions. One important thing to remember is we are not talking about IAM in here. We are not talking about a specific user should not be able to do a specific thing. We are talking about nobody in the account should be able to create a resource in a specific region. So these are centralized constraints that we are talking about in here.

And in those kind of situations we would go for an organization policy. If you want to be able to configure an organization policy, you need to have the organization policy administrator role. It’s very important to remember that I am focusing on who I am, focuses on members, people or service accounts or groups and their accesses who can take specific actions on resources. Organization policy focuses on what can be done on specific resources or specific resources should not be allowed to be created in a specific region. That’s the organization policy. Organization policy always overrides whatever is configured in IAM. So if an organization policy prohibits the creation of resources in, let’s say a specific region, even though a user might have that access through Im, he’ll not be able to create the resource in that specific region because I am policy has the highest priority.

Where can you configure organization policy? If you go to Im Admin, you can go to Organization policies. This is where you can actually configure the organization policies. And you can see that there are a number of organization policies which are predefined and already present in here. A good example is enforced uniform bucket level access. What would it do? It would ensure that inside the project you’ll not be able to create any buckets with uniform bucket level access disabled. This is where you can also define a resource location restriction. So constraint slash GCP resource locations. You can say I want to allow creation of resources only in this specific regions, or I can say I don’t want to deny creation of resource in a specific region.

You can also see you can have a restriction on OS login. So is OS login mandatory? If you don’t want to allow public access to cloud SQL instances, you can do that as well. You can enable an organization policy for that. So as you can see in here, there are a wide variety of organization policies which are in here. You don’t really need to remember all these policies. What I would recommend you to do is to just scroll through them once to get a highlevel overview. In this step we talked about organization, Policy Service. It is used to configure organization policies. These are centralized constraints which apply to all resources that you are creating in a specific organization. I’m sure you’re having a wonderful time and I’ll see you in the next step.

7. Step 05 – Exploring IAM Policy at multiple levels – Resourcing Hierarchy

Welcome back. In this step, let’s look at im policy and resource hierarchy. IAM policy can actually be set at any level in the hierarchy. Earlier, we talked about the levels organization, folder, project and resource. IAM policies can be set at resource level, project level, folder level, and organization level as well. Resources inherit the policies of all parents. So if you have a policy configured at project level or folder level or organization level, resources would inherit them. The effective policy for a resource is the union of the policy on that resource and its parents.

So you can set policies at any of these levels and at a specific level. The effective policy is the policy at that level plus the policy at all the above levels. Policy inheritance is transitive. So if you have some policy at organization level, it is definitely applicable at resource level as well. If a permission is provided at organization level, for example, you cannot override that and deny it at a resource level. So you cannot restrict policy at lower level. If permission is given at a higher level. In this step, we talked about the fact that im policies can be assigned at multiple levels alike. You in the next step.

8. Step 06 – Exploring IAM Predefined Roles – Organization, Billing and Project

Back. Starting this step, let’s look at IAM predefined roles in a little bit more depth. We will explore the different services that are provided by GCP and the different predefined roles that are part of these services. Let’s start with organization building and project roles. Organization administrator can define resource hierarchy. He can define the different folders, different projects that are present. He can define the folders and the projects. Organization administrator can also define access management policies. Organization administrator can also manage other users and the roles that are bound to your specific user. The next important role is a billing account creator.

A billing account creator can create billing accounts. Billing account administrator on the other hand can manage billing accounts so he can manage payment instruments, billing, exports, linking and unliking projects and managing the different roles on a billing account. However, a billing account administrator cannot create a billing account. This is another good example of separation of duties principle. You can have somebody to create a billing account and somebody else to manage it. A billing account user is the one who would associate projects with billing accounts. This is typically used in combination with project creator.

If somebody has the billing account user and the project creator roles, then he can create the project and assign the project to a billing account. These two roles allow user to create new project and link it with a billing account. Billing account viewer on the other hand can see all the details of the billing account. He’ll not be able to make any modifications. As you can see, there are a wide variety of roles which are related to organization, billing and project. Let’s do a quick review of the billing roles. Billing account creator permissions to create new billing accounts use cases. Let’s say somebody from finance team billing account administrator manages the billing account but they cannot create them.

Typically, these guys are also part of the finance team. A billing account user can map a project to a specific billing account. Typically, a project owner, somebody who creates the project would want to actually map the project to a billing account and they would be having the role of billing account user. Billing account viewer has access only to view the billing account. Good use case is auditor. Somebody wants to look at all the information related to a billing account, they can be assigned a role of billing account viewer. Let’s look at a couple of scenarios.

Scenario one, I am creating a project and I would want to associate an existing billing account with the project. What roles do you need? You need project creator role to create the project and you need billing account user role so that you can link the project to the billing account. Scenario two, you are a billing auditor, you don’t want to look at all the details. The role that is needed is billing account viewer role. In the step we looked at organization billing and project roles in subsequent steps. Let’s look at roles related to other services as.

9. Step 07 – Exploring IAM Predefined Roles – Google Compute Engine

Come back. In this step, let’s look at few roles related to Compute Engine compute Engine admin he has complete control over Compute. Earlier, when we talked about Compute, we talked about instances, images we talked about network firewalls, load balances and a wide variety of resources that are part of Compute. A Compute Engine admin has complete control over everything that is part of Compute Instance images, et cetera. Compute Instance admin can only create, modify and delete virtual machine instances and disks. The important difference in here is Compute Engine Admin compute Instance admin instance admins can play with instances and disks that’s all.

Compute Engine admin can play with everything in Compute. Compute Engine network admin network admin can only play with networking resources, routes, networks, health checks, VPNs gateways, et cetera. And the network admin also has read only access to Firewalls and SSL certificates to the security related things. A network admin has read only access who has write access to the security related things compute Engine security admin he has complete access to Firewall rules and SSL certificates. Compute Storage admin has access to disks, images and snapshots.

Compute Engine Viewer has read only access to everything in Compute. Compute OS admin login if you have this role, you can log into a Compute Engine instance as an administrator user. Compute OS login you can log in to Compute Engine instance as a standard user. So if you want to be able to log in as an administrator user, you need to have admin login role. If you just have login, then you cannot log in as an admin user. You can log in as a standard user. In this quick step, we looked at some of the important roles related to Compute Engine. I’ll see you in the next.

10. Step 08 – Exploring IAM Predefined Roles – Google App Engine

Back in this step, let’s look at some of the important roles related to App Engine. There are a variety of roles that are present in App Engine and what we’ll do is we’ll use an abbreviation. So let’s say Crud stands for create, Read, Update and Delete. So you can create a resource, you can read, basically you can list the resources and also you can get the details of a specific resource. You can also do an update and delete. Let’s start with App Engine Creator. An app engine creator can create and delete applications. That’s all. He’s responsible for creating an application. So whenever you want to start creating an App Engine app in a specific project, you need to have the App Engine Creator role. App Engine Admin has read and update access on applications.

However, he has complete access on everything else services, instances, versions he has Cred access and he can perform all operations. Whenever we talk about App Engine, we have an application at the top and underneath the application you can have multiple services. For each of these services you can have multiple versions and under each version you can have multiple instances which are serving a specific version. So an App Engine admin can read and update application and can do all the operations on services, instances and versions. An app engine viewer. It’s easy. He can read everything and he can also perform operations. App engine code viewer is a unique role. This is the only role that can view code. Security is very very important when it comes to your code.

You don’t want everybody to be able to read the code which is deployed to App Engine. App Engine Deployer is somebody who can create, read and delete versions so he can create a new version. So if a new version of application needs to be deployed, app Engine Deployer can do that for you. He can also read the application, services and versions information. So an App Engine deployer can deploy a new version of App if you also grant him the service account user role. The next role is App Engine Service Admin. An app engine service admin cannot create a version. He can read, update and delete a version, but he cannot create a version. He can read the application details and he can perform all operations on services and instances. He is also allowed to do several operations, split or migrate traffic, start and stop a version.

If you are deploying a new version, the App Engine deployer can deploy a new version and App Engine Service Admin can configure the traffic to go to the new version. Important thing to remember about App Engine roles is they do not allow you to view and download application logs. If you want to be able to access application logs, you need to have permissions on cloud logging. They don’t allow you to view monitoring charts in the cloud console. If you want to be able to do that, you need to have access to cloud monitoring. They don’t allow you to enable and disable building. They don’t allow you to access configuration or data which is stored in other services. You need additional rules to be able to do that. In this step, we looked at App engine roles.

11. Step 09 – Exploring IAM Predefined Roles – Scenarios

Welcome back. In this step, let’s look at a few scenarios related to Compute Engine and App Engine roles. What is the difference between Compute engine admin and Compute instance admin? Compute Instance Admin can do everything with instances and disks only. Compute Engine Admin is admin for everything in Compute instances disks, images, network firewalls, etc. What is a secure way of setting up application deployment? We already talked about that. Application deployer. You can provide him roles.

App Engine Deployer Plus Service account User this would allow him to deploy new versions and delete old versions that are not serving traffic. However, he’ll not be able to configure traffic. You can have an additional operations person. You can assign a role of App Engine Service Admin to him. An App Engine Service Admin cannot deploy a new version of the app. However, he can change traffic between versions. In this quick step, we looked at a couple of scenarios related to Compute Engine and App Engine roles. I’ll see you in the next step.

12. Step 10 – Exploring IAM Predefined Roles – Google Kubernetes Engine

Come back in the step. Let’s look at Google Kubernetes engine. I am Roles. Whenever we talk about Google Kubernetes engine, there are two different things clusters and your applications, which are deployed to the clusters. There might be different people who are managing the cluster, and there might be different people who might be deploying the applications to the cluster. And that’s why you would see that the GKE roles bring in a clear distinction between these two good things. Kubernetes Engine Admin kubernetes Engine admin can do everything with Kubernetes, so they have complete access to clusters and Kubernetes API objects.

Kubernetes API objects are nothing but deployment services, pods and things like that. So the Kubernetes engine admin has complete access to everything kubernetes kubernetes Engine cluster admin, on the other hand, has complete access to management of clusters.However, they cannot access Kubernetes API objects. They cannot access deployments pods and things like that. Kubernetes Engine Developer they have access to Kubernetes API objects, and they can read the cluster information.

Kubernetes Engine Viewer they can do a get or list on the cluster. They can read cluster information, and they can also read Kubernetes API objects. Two important roles to remember in here are admin and cluster admin. Admin has complete access. Cluster admin has access to the cluster, but they cannot access Kubernetes API objects. A Kubernetes Engine developer, on the other hand, can manage Kubernetes API objects, but they cannot make any changes on the cluster. They can read cluster information, but they cannot edit the cluster information.

13. Step 11 – Exploring IAM Predefined Roles – Google Cloud Storage

Welcome back. Next step, let’s look at cloud storage roles. Let’s start with storage. Admin Storage admin has complete access to buckets and objects. He can create new budgets and he can create new objects in buckets. And you can do he can do all operations with buckets and objects. A storage object admin can only play with objects. He does not have access to play with buckets. Storage Object creator can create objects. Storage Object Viewer can get and list objects. One important thing that you need to remember is that the Container Registry stores container images in cloud storage buckets. Earlier, when we were talking about containers, we talked about the fact that we create container images and we upload them to Container Registry.

And the Container Registry stores them in cloud storage buckets. If you want to access the container images in the cloud storage buckets, then you would need to have the appropriate permissions so you can control access to images in the Container Registry using the cloud storage permissions. The other important thing to remember is the difference between storage admin and Storage Object admin. Storage admin can create buckets and play with objects. Storage object admin cannot create buckets but can play with objects. Objects in a bucket. In this episode, we talked about the different roles associated with cloud storage. I’ll see you in the next step.

• Category: Uncategorized