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

1. Step 01 – Organizing Google Cloud Resources – Projects, Folders and Organization

Back until now, all the resources that we have created are created under projects. However, there is a lot more that you need to understand about how you organize your GCP resources. Let’s discuss that in this specific section. Let’s start with understanding the resource hierarchy in GCP. In GCP, there is a well defined hierarchy, organization, folder, project and resources. All the resources we have created until now are created in different projects. Each resource is associated with a specific project, and projects help you to group different resources. A folder can contain multiple projects and an organization can contain multiple folders. So an organization can contain multiple folders.

Each folder can contain multiple projects, and projects are where your resources are defined. Now, how do you decide how to create folders and projects? Let’s look at a few recommendations. Create separate projects for different environments. This would ensure that there is complete isolation between test and production environments. Create separate folders for each department. If you have multiple departments, create separate folders for each of them. This would help you to isolate production applications of one department from another department. If you have any Shade resources, you can create a Shade folder and put all the Shade resources in the Shade folder.

A good recommendation to follow is one project per application per environment. If you have two applications, a one and a two, and let’s say you need two environments each for each of these apps, dev and Prod. Let’s consider two apps a one and a two. And let’s say for each of these apps you need two environments dev and Prod. In the ideal world, you need to actually create four projects. This would ensure that the environments are isolated from each other. You can be confident that any changes that you make in dev environment will not break changes in product environment. This would also allow you to give complete access to your developers for the dev projects.

They can create delete, deploy, so you can give complete permissions to the A one Dev and the AOD projects to your developers. And you can provide production access only to your operations teams only. In the step we looked at the resource hierarchy. In Google Cloud you have an organization at the top. Under organization you can have several folders. Under folders you can have several projects. Under projects is where you have the resources. Now, in your Google Cloud console, you can go to my first project, and over here, if you go to all, you can see the hierarchy. You can see that there is no organization under which we have the projects. What we are making use of in here is a free trial account, and in the free trial account, we don’t have organizations and folders, we directly create projects.

However, if you create an enterprise account, for example a G suite account or a Cloud identity account, in those kind of scenarios, you can have organizations under which you can create folders under which you can create projects. So in enterprise projects, you can have organization, under which you will have folders under which you have projects, and under which your resources are present. However, for the free tire accounts that we are making use of, we can create multiple projects. But organization folder levels are not really visible in this step. We talked about resource hierarchy. I’ll see you in the next step.

2. Step 02 – Exploring Billing Accounts

Let’s talk about billing accounts. Whenever you want to create any resources in a project, billing account is mandatory. You need to pay for them. So you need a billing account. Billing account contains the payment details. Every project with active resources should be associated with a billing account. Every project has one billing account, but a billing account can be associated with one or more projects. You can have multiple billing accounts in a single single organization. You can go into billing accounts and that’s where you’d be able to see your billing account details. So you can see the billing account in here you can see the current month details, you can see the cost trend and all the details. And you can also see the payment overview. You can see, you can see your balance and you can see how you pay.

And you can see if there are any transactions that we performed earlier. You can also create a new billing account. You can go to manage billing accounts and over here you can create new billing accounts and you can associate them with your projects. The recommendation is to create billing accounts representing your organization structure. A startup might just have one billing account. However, a large enterprise may have separate billing accounts for each department. There are two types of billing accounts self serve and Invoiced. What we are making use of in here is self serve. Over here you can see that we are making automatic payments, that is self serve. So you are billed directly to your credit card or bank account. The other option is used by large enterprises which is Invoiced.

Invoice is generated by Google cloud and it is sent and then the enterprise needs to process the invoice, typically for individual accounts. The option which will make use of a self serve. If you have a large enterprise, then you can go for Invoice. Now that we looked at billing account, let’s look at managing billing for your Google Cloud platform account. Let’s look at budget alerts and exports. One of the most important recommendations is to set up a cloud billing budget to avoid surprises. Along with the budget, you can configure alerts. The default alert thresholds are set at 50%, 90% and 100%. You can optionally send alerts to pub, sub billing admins and the billing account users are alerted by email at all these thresholds. Over here, you can go in and configure budgets and alerts. So you can go to budgets and alerts.

You can create a budget, you can give it a name and you can select all the projects that you’d want to look at inside that I’ll call this my first budget. You can configure the projects, you can configure all the services that you want under this specific budget. And you can say next. You can also configure a specific amount, let’s say Rs1000 or whatever. And you can say actions. You can set your alert thresholds, email alert, notifications are sent out to the admins when these alert thresholds are met. So over here, the defaults are 50 91 hundred right below. You can also manage notifications. You can send email alerts to billing admins and users. You can also connect a Pub sub topic to this budget. So the best practice is to create a budget and configure alerts. You can also export billing data.

You can schedule the export of billing data to BigQuery. If you want to look at the billing data in depth, you want to use queries to analyze that, you can send it to BigQuery. If you want to archive your billing data for history, you can use cloud storage. You can go to billing export, and you can configure either a BigQuery export or a file export. You would see that file export is replicated right now, but there are frequent questions in the exam regarding that. So as far as the exam is concerned, remember that there are two kinds of exports BigQuery export and file export to cloud storage. Instead, we talked about some of the important information that you would need to know about billing accounts, about setting a budget, and alerts about exports of your billing data. I’m sure you’re having an interesting time, and I’ll see you on the next step.

3. Step 03 – Understanding IAM Best Practices

Welcome back. In an earlier section, we started our discussion on IAM. We’ll discuss a lot more about IAM in this specific section. Let’s get started with IAM best practices. One of the recommendations for IAM is principle of least privilege. Give least possible privilege needed for a specific role. So if you have a developer, provide him with least possible access that is needed to be able to do all actions that are needed by his role. And because of this, basic roles are not really recommended. Viewer, Editor owner roles give you a wide variety of permissions, and that’s why basic roles are not recommended. Wherever possible, use predefined roles. And whenever you create service accounts, make sure that you create service accounts with the minimum amount of privileges.

If a VM needs to be able to talk to cloud storage only, give it permissions. Don’t give it very generic permissions. And another best practice is to use different service accounts for different apps and different purposes. I see a lot of apps, typically in Google Cloud, use a common service account and the common service account has all the accesses that are needed by all the apps. That’s not really good. You need to customize your service account for the needs of a specific app, and you need to attach that service account with that specific app. The next best practice is separation of duties. Whenever you have sensitive task that needs to be performed, involve at least two people. Don’t let one person have all access to perform a sensitive task.

A good example is having separate deployer and traffic migrator roles in App Engine. App engine has app engine deployer and app engine service admin roles. An App Engine deployer can deploy a new version, but he cannot shift traffic to the new version. An App Engine Service Admin can shift traffic to the new version, but he cannot deploy a new version. So whenever you want to deploy a new version and shift traffic to it, you’d need two people. Whenever you want to perform sensitive operations, sensitive tasks involve at least two people. That’s what is separation of duties. The next important thing is constant monitoring. Make sure that you keep reviewing the cloud audit logs to audit the changes to IAM policies and also to check who is accessing your service account keys.

In addition, you can also ensure that the cloud audit logs are archived in Cloud storage buckets for long term retention. The next important best practice is to use groups whenever possible. Whenever using IAMs, always create groups. So if you have a set of developers, create a group for them and bind the roles to the group. This would ensure that your management of users becomes easy. Whenever a new developer comes in, all that you need to do is to add him to the group. Whenever a developer leaves, all you need to do is to remove that specific developer from the group. So whenever possible, use groups. Using Groups makes it easy to manage your users and permissions. In this step, we looked at IAM best practices. I’ll see you in the next step.

4. Step 04a – Understanding User Identity Management in GCP

Welcome back. Instead, let’s talk about user identity management in Google Cloud. What do I mean by that? Earlier we used a specific email account to create our free trial account. And this user has owner role. And this guy is called the Super Admin of your Google Cloud account. As we discussed, Super Admin can do anything. He has access to everything in your GCP organization folders and projects. In addition to the Super Admin account, you can add other users. We can add other users by adding roles to that specific user on the specific project. Earlier we talked about Im policy. I Am policy is nothing but the list of bindings which are attached to a project. A binding is nothing but a mapping between a user and a role.

So if you add a binding for a specific user to a specific role in a specific project, he’ll be able to access that specific resource in a project. So, if you take the Gmail account of a user and add an Im policy binding so earlier we executed the command add Im policy binding to this member to this role. This is how we can actually add in access to other users. However, remember that this is not recommended for enterprises. You don’t want to use individual Gmail accounts when it comes to enterprises. So whenever we talk about enterprises, they have their own custom authentications. For example, if your enterprise is already using Google Workspace, what is Google Workspace? Google Workspace was earlier called G Suite, and even before that it was called Gcloud Apps for your domain.

So if you are an enterprise, and you want to provide a custom email, and you want to provide collaboration tools like Gmail, Calendar, Drive, Doc Sheets, if you want to provide any of these services to your employees, you can register for a Google Workspace account, and you can use Google Workspace to manage your users and their access to different tools. So if you are already making use of Google Workspace, then you can continue using Google Workspace to manage your users. All that you need to do is to link your Google Cloud organization with Google Workspace. The other option could be that your enterprise is not making use of Google Workspace at all and your enterprise uses an active directory or an identity provider of its own.

In those kind of situations, you can actually federate Google Cloud with your identity provider, you can link Google Cloud with your identity provider and you can give permissions to your enterprise users to use the Google Cloud platform. So if you are using Google Workspace already, you can link Google Workspace with the organization of your Google Cloud account, or if your enterprise has an identity provider of its own, you can also federate Google Cloud with your identity provider. Let’s quickly look at what corporate directory federation is. You want to federate Cloud Identity or Google workspace with your external identity provider such as Active Directory or Azure. Active Directory.

All your enterprise users are either in Active Directory or Azure Active Directory. For example, these are called identity providers. And because these are external to Google Cloud, these are called external Identity Providers. And if we would want to use external identity providers to authenticate our users who are using the resources in the Google Cloud, we call it Federation. What we can do is we can federate Cloud Identity with this. Now, what is Cloud identity? Cloud Identity is a unified identity access, app and endpoint management platform. In simple words, cloud identity manages identities? So I’ll click Identity Platform in here and you can go to the console of the Identity Platform.

Let’s go ahead and enable Identity Platform for this account. Once you go into the Identity Platform, you can configure different identity providers. Who is the guy who can authenticate a user for us? You can also configure multifactor authentication. Just using user ID and password is not sufficient. I would want another way of authenticating a user, maybe a SMS. What you can do in the Identity Providers is add a connection to an external provider. So over here you can say I would want to connect to an Open ID Connect or a SAML based. Typically, whenever we talk about enterprises, we are talking about things which are making use of Active Directory. In those kind of situations, we would typically go for SAML.

So you can say SAML and you can configure the details of your enterprise external identity provider. So Federation is all about linking Google Cloud platform with an external identity provider such as Active Directory or Azure. Active Directory? And when we are doing this and to be able to do that, we can make use of Cloud Identity. When you’re using Federation, you can also enable single sign on. You log into your enterprise directory and automatically this would also log in you into the Google Cloud Platform. So users are redirected to an external IDP or Identity provider to authenticate. And when users are authenticated the SAML assertion, a SAML assertion is sent over to Google sign in.

And this is what is used to enable users to log in into their Google Cloud Platform account. Let’s look at a couple of examples of corporate directory federation federating Active Directory with Cloud Identity by using Google Cloud Directory sync and Active Directory federation Services federating Azure Active Directory azure Active Directory is a service which is provided by Azure. You can also federate Azure active directory with cloud identity. There are a lot of things that we discussed as part of this step. The important takeaways are if you’re using Google Workspace for custom emails and also providing collaboration services for your enterprise for your employees, then that’s awesome.

You can link your Google Workspace account with the Google Cloud platform and use that to authenticate your users. The other option is you might be using any external identity provider for example, you have your own custom from Active Directory setup or you have Azure Active Directory. In those type of situations, you can set up federation between your identity provider and Google Cloud that will help you to enable single sign on for your users where they’ll be using their corporate identities to log in and get access to the resources which are present in the Google Cloud platform. I’m sure you’re having a wonderful time and I’ll see you in the next step.

5. Step 04b – Exploring IAM Members and Identities

Back in this up, let’s look at different types of IAM members or identities. The first type is a Google account. It represents a person email address. We used a Google account to create a free tab account. So that’s one type. The other members we have already talked about are service accounts. These are not people, these are applications. These are resources. This represents an application account. A Google group is nothing but a collection. So a group of users or a group of service accounts. These are called groups. In Google cloud platform. Even when you create a group, it is assigned a unique email address.

Using Groups is recommended because you can manage permissions at one place. The other option is what we looked at earlier. Google workspace domain. Google Workspace provides collaboration services for your enterprises. So tools like Gmail, Calendar, Meet, Chat, Drive, Docs are included as part of Google Workspace. And if your enterprise is using Google Workspace, you can manage permissions using your Google Workspace domain. If you have your own enterprise user directory, then you can use federation. You can use Cloud Identity to set up federation between your external identity provider and Google Cloud platform, and you can use the users who are already present in your enterprise directory.

Once you have the federation established, you can use IAM and map the right roles to the Cloud Identity accounts. Let’s look at a few use cases. All members in your team have G Suite accounts. You are creating a new production project and you want to provide access to your operations team. What would you do? You can create a group with your operations team, and then you can create a policy binding the group to the right accesses. All members in your team have G Suite accounts. You are setting up a new project. You want to provide a one time quick access to a team member. What you can do is to assign the role directly to the G Suite email address of your team member.

So you would have a policy binding your team member directly to the role. Typically this is not recommended, but because this is a onetime access, it might be simple to directly assign the role. Rather than create a group and then assign the role to a group and assign the user to the group. You want to provide an external auditor access to view resources in your project, but he should not be able to make changes. What would you give? You’d give them role slash viewer role. This is a basic role, also called a primitive role. Typically these are not recommended, but if you want somebody to be able to see everything in a project, I think giving them the role slash viewer role makes sense.

Your application is deployed in Project A in a virtual machine there, and it needs to access a cloud storage bucket from a different project. For example, project B. How can you provide access important thing to remember is where is the resource? The resource is in project b. So the cloud storage bucket is in project b. So what you’d do is you’d go to project b, and you would assign the role with the right access. So over here, we would want to access the cloud storage bucket. Whichever role has that access, you’d assign that role to the user who is already created in the project a. You would assign that role to the service account of the VM. I’m sure you’re having a wonderful time, and I’ll see you in the next step.

• Category: Uncategorized