With GCP, you must ensure that resources are properly secured. To do this, you will leverage Identity and Access Management, or IAM.
IAM is used to provide an authentication and authorization model for GCP. It is used to secure the cloud platform, not operating systems or applications.
IAM provides a easy to use, unified model to:
- Identify users
- Secure resources
- Authorize API requests
Users, or members, are not created in GCP. You will use some other system to provide user identity. Members can be added to projects or resources.
Members can be people identified by a login.
Members can also be service accounts. Service accounts are used by GCP to provide privileges to products and services. For example, a service account can give privileges to an instance. Service accounts are the only identities provided by GCP.
A best practice is to apply permissions to a group rather than an individual.
What would you rather do? Manage the permissions of 5 groups or 500 users?
GCP uses roles as a method to distribute permissions. Members are assigned one or more roles. The roles a member is assigned will determine the permissions of a member. A role is a list of permissions organized by a service. This list of permissions correlate with GCP API calls and are aligned based on job functions.
The examples shown are roles for Compute Engine, Google Cloud Storage, App Engine, and Kubernetes Engine.
The example shows the content of a few Google Cloud Storage Roles. Roles are a list of API functions the member will be able to invoke. If the API function is not listed in the role, then the member will not have permissions to run the function.
There are three types of roles available for GCP:
Primitive roles apply to the projects only. All permissions applied at the project level will be inherited to child objects in the project, and can’t be limited.
There are three primitive roles.
Project Viewer provides read-only access to all services and resources in a project. Project viewer roles are good for security auditors who need to see everything but build nothing.
Project Editor has all the permissions of the project viewer role, as well as read/write access to all services and resources in a project. Project editors are usually members who will be leveraging resources to build solutions.
Project Owner has all the permissions of a project editor, but can also control the project. For example, a project owner can add and remove users, as well as delete the project.
Google provides roles for each service. There are hundreds of predefined roles in GCP. Predefined roles are based on different job roles when working with different services. And are maintained by Google.
A Google best practice is to avoid using primitive roles. Primitive roles may not be specific enough.
Always follow the principle of least privilege.
Custom roles are an option when there is not a predefined role available that provides the permissions you would like to group. You create custom roles. Custom roles give you fine-grained control over permissions by allowing you to add any permission you like to a role you create.
You can create custom roles by copying and modifying a predefined role. Custom roles add operational overhead. You are responsible for maintaining the permissions of a custom role.
Service accounts are accounts that are built within GCP, which provide a method to distribute service to service permissions.
Service accounts are used to identify machines or applications. You can create a service account and give the account a name. Then add one or more roles to the service account, much in the same way you would apply roles to a user or group.
Service accounts can be assigned to virtual machines as a way of giving the applications within them permissions.
You can also download a key that can be used to identify a service account. Then the key can be used to identify code to give permissions, or authenticate the Cloud SDK.
Here is an example of creating a service account.
First, give your service account a name. A best practice is to give the account a name that can be used to easily determine the purpose of the service account.
Next, you add one or more roles to associate with the service account. The roles will determine the permissions associated with the account.
If required, you can also create a JSON or P12 key to apply to applications and services.
Service accounts can be used to control the level of access a virtual machine can have to other GCP services.
The default service account for a virtual machine gives it project editor privileges. However, the default service account can be overridden by using scopes to set the permissions per service.
An alternative would be to create a new service account and select it when creating a virtual machine.
Here is an example of a service account key configuration. The configuration can be used for gcloud or your application code.
The top example shows how to configure gcloud to use a service account by linking gcloud to a key that was created.
The bottom example shows how to use your keys via code. In this example, Python. The SDK will automatically look for the environment variable.
IAM uses an inherited model for distributing privileges. All privileges applied to a parent object will be inherited to the child objects. Permissions can be granted at any level of the hierarchy
However, an inherited permission on a child object cannot be overridden.
All permissions are allow permissions. There isn’t an explicit deny option for a permission. If a permission is not allowed, it is denied.
The IAM Hierarchy is organized in four distinct levels. The levels are:
Organization, which is a registered domain. Rights granted at the organization level are applied to the entire infrastructure.
Folders are an optional level used to organize projects. Rights can be granted to folders and folders can contain other folders.
Projects are accounts that can be added to an organization or folder. Rights granted at the project level are applied to all resources in a project.
Resources are the products and services used within a project. Rights can also be granted at the resource level.
Here is an example of an organization and folders.
From here, you can see the drehnstrom.com organization. Under that organization, you see multiple folders.
Inside the Google Courses folder, you can see a project named gcp-associate-engineer-demo project.
Some best practices include:
For example, developer project to allow programmers access
Production project to allow operations access
Before moving on, check out the links and exercises provided in this chapter and make sure you take the quiz.
For homework, complete the following exercise. Based on the scenario described in the first paragraph, perform the following:
Create a project for your application.
Add a friend as a programmer. Give your friend roles appropriate for the application.
Add a service account with roles required for the code to run properly.
Figure out how to write a Python Flask web application. Then try to create a home page.