IAM

• Give the service account the role of compute.instanceAdmin:

  • gcloud projects add-iam-policy-binding $PROJECTID2 --member serviceAccount:$SA --role=roles/compute.instanceAdmin

  Create an instance with the devops service account attached. You also have to specify an access scope that defines the API calls that the instance can make.

  • gcloud compute instances create lab-3 --machine-type=e2-standard-2 --service-account $SA --scopes "https://www.googleapis.com/auth/compute"
• Access scopes are the legacy method of specifying permissions for your instance. Access scopes are not a security mechanism. Instead, they define the default OAuth scopes used in requests from the gcloud tool or the client libraries. They have no effect when making requests not authenticated through OAuth, such as gRPC or the SignBlob APIs.

  • You must set up access scopes when you configure an instance to run as a service account.
• Access Scopes:

  • A best practice is to set the full cloud-platform access scope on the instance, then securely limit the service account's API access with IAM roles.
  • Access scopes apply on a per-instance basis. You set access scopes when creating an instance and the access scopes persist only for the life of the instance.
• • Access scopes have no effect if you have not enabled the related API on the project that the service account belongs to. For example, granting an access scope for Cloud Storage on a virtual machine instance allows the instance to call the Cloud Storage API only if you have enabled the Cloud Storage API on the project.
• Connect to the newly created instance using gcloud compute ssh:

  • gcloud compute ssh lab-3
• There are four roles:

  • Browser
  • Editor
  • Owner
  • Viewer

  These are primitive roles in Google Cloud. Primitive roles set project-level permissions and unless otherwise specified, they control access and management to all Google Cloud services.
• roles/viewer

  • Permissions for read-only actions that do not affect state, such as viewing (but not modifying) existing resources or data.

  roles/editor

  • All viewer permissions, plus permissions for actions that modify state, such as changing existing resources.
• roles/owner:

  All editor permissions and permissions for the following actions:

  • Manage roles and permissions for a project and all resources within the project.
  • Set up billing for a project.

  roles/browser

  • Read access to browse the hierarchy for a project, including the folder, organization, and Cloud IAM policy. This role doesn't include permission to view resources in the project.
• Username 2 has the "Viewer" role prescribed which allows them read-only actions that do not affect state. This example illustrates this feature—they can view Cloud Storage buckets and files that are hosted in the Google Cloud project that they've been granted access to.
• Removing Users Access

  
• Now if you give a user for eg. Storage Object Viewer role, they cannot get to the bucket objects through the console, however they can still use the Cloud Shell!
• Predefined roles are created and maintained by Google. Their permissions are automatically updated as necessary, such as when new features or services are added to Google Cloud.
• Custom roles are user-defined, and allow you to bundle one or more supported permissions to meet your specific needs. Custom roles are not maintained by Google; when new permissions, features, or services are added to Google Cloud, your custom roles will not be updated automatically.You create a custom role by combining one or more of the available Cloud IAM permissions. Permissions allow users to perform specific actions on Google Cloud resources.
• Custom IAM Roles:

  • Key Point: Custom roles enable you to enforce the principle of least privilege, ensuring that the user and service accounts in your organization have only the permissions essential to performing their intended functions.
  • Note: You can create a custom role at the organization level and at the project level. However, you cannot create custom roles at the folder level.
• IAM:

  • In the Cloud IAM world, permissions are represented in the form: <service>.<resource>.<verb>
  • For example, the compute.instances.list permission allows a user to list the Compute Engine instances they own, while compute.instances.stop allows a user to stop a VM.
• IAM Roles:

  • Custom roles can only be used to grant permissions in policies for the same project or organization that owns the roles or resources under them. You cannot grant custom roles from one project or organization on a resource owned by a different project or organization.
• Required permissions and roles

  • To create a custom role, a caller must have the iam.roles.create permission.
  • Users who are not owners, including organization administrators, must be assigned either the Organization Role Administrator role (roles/iam.organizationRoleAdmin) or the IAM Role Administrator role (roles/iam.roleAdmin). The IAM Security Reviewer role (roles/iam.securityReviewer) enables the ability to view custom roles but not administer them.
• Custom Roles:

  • It is only available to users who have permissions to create or manage custom roles. By default, only project owners can create new roles. Project owners can control access to this feature by granting IAM Role Administrator role to others on the same project; for organizations, only Organization Administrators can grant the Organization Role, Administrator role.
• • Run the following to get the list of permissions available for your project.:
  • gcloud iam list-testable-permissions //cloudresourcemanager.googleapis.com/proje
• • To view the role metadata, use command below, replacing [ROLE_NAME] with the role. For example: roles/viewer or roles/editor:
  • gcloud iam roles describe [ROLE_NAME]
• Use the gcloud iam list-grantable-roles command to return a list of all roles that can be applied to a given resource.

  • Execute the following gcloud command to list grantable roles from your project:
  • gcloud iam list-grantable-roles //cloudresourcemanager.googleapis.com/projects/$DEVSHELL_PROJECT_ID
• Use the gcloud iam roles create command to create new custom roles in two ways:

  • Provide a YAML file that contains the role definition
  • Specify the role definition using flags
• Creating Custom Roles With YAML FIle:

  • [ROLE_TITLE] is a friendly title for the role, such as Role Viewer.
  • [ROLE_DESCRIPTION] is a short description about the role, such as My custom role description.
  • [LAUNCH_STAGE] indicates the stage of a role in the launch lifecycle, such as ALPHA, BETA, or GA.
  • includedPermissions specifies the list of one or more permissions to include in the custom role, such as iam.roles.get.

  
• Creating Custom Roles with YAML File:

  1. nano role-definition.yaml
  2. Add this custom role definition to the YAML file:
  3. Execute the following gcloud command:
  4. gcloud iam roles create editor --project $DEVSHELL_PROJECT_ID \
  5. --file role-definition.yaml

  
• Creating a Custom Role:

  • If the role was created successfully, the following response is returned:

  
• Create a custom role using flags:

  • Execute the following gcloud command to create a new role using flags:
  • gcloud iam roles create viewer --project $DEVSHELL_PROJECT_ID \--title "Role Viewer" --description "Custom role description." \--permissions compute.instances.get,compute.instances.list --stage ALPHA
• List the custom roles

  • Execute the following gcloud command to list custom roles, specifying either project-level or organization-level custom roles:
  • gcloud iam roles list --project $DEVSHELL_PROJECT_ID

  To list deleted roles, you can also specify the --show-deleted flag.

  • Execute the following gcloud command to list predefined roles: gcloud iam roles list
• Updating metadata:

  A common pattern for updating a resource's metadata, such as a custom role, is to read its current state, update the data locally, and then send the modified data for writing. This pattern could cause a conflict if two or more independent processes attempt the sequence simultaneously.

  • For example, if two owners for a project try to make conflicting changes to a role at the same time, some changes could fail.
• Updating an Existing Roles: Conflicting Changes:

  • Cloud IAM solves this problem using an etag property in custom roles. This property is used to verify if the custom role has changed since the last request. When you make a request to Cloud IAM with an etag value, Cloud IAM compares the etag value in the request with the existing etag value associated with the custom role. It writes the change only if the etag values match.
• Use the "gcloud iam roles update" command to update custom roles in one of two ways:

  • A YAML file that contains the updated role definition
  • Flags that specify the updated role definition
• Updating Custom Roles:

  • When updating a custom role, you must specify whether it applies to the organization level or project level by using the --organization [ORGANIZATION_ID] or --project [PROJECT_ID] flags.
  • The describe command returns the role's definition and includes an etag value that uniquely identifies the current version of the role. The etag value should be provided in the updated role definition to ensure that any concurrent role changes are not overwritten.
• Describing custom roles:

  • gcloud iam roles describe editor --project $DEVSHELL_PROJECT_ID
• Updating a Custom Roles with yaml file:

  • Once updated yaml file, you’ll use the update command to update the role. Execute the following gcloud command, replacing [ROLE_ID] with editor:
  • gcloud iam roles update [ROLE_ID] --project $DEVSHELL_PROJECT_ID \--file new-role-definition.yaml
• Update a custom role using flags

  Use the following flags to add or remove permissions:

  • --add-permissions: Adds one or more comma-separated permissions to the role.
  • --remove-permissions: Removes one or more comma-separated permissions from the role.
  • Alternatively, you can simply specify the new permissions using the --permissions [PERMISSIONS] flag and providing a comma-separated list of permissions to replace the existing permissions list.
• Update a custom role using flags

  • Execute the following gcloud command to add permissions to the viewer role using flags:
  • gcloud iam roles update viewer --project $DEVSHELL_PROJECT_ID \--add-permissions storage.buckets.get,storage.buckets.list
• Disable a custom role

  • When a role is disabled, any policy bindings related to the role are inactivated, meaning that the permissions in the role will not be granted, even if you grant the role to a user.
• Disable a custom role

  The easiest way to disable an existing custom role is to use the --stage flag and set it to DISABLED.

  • Execute the following gcloud command to disable the viewer role:
  • gcloud iam roles update viewer --project $DEVSHELL_PROJECT_ID \--stage DISABLED

  
• Delete a custom role

  • Use the gcloud iam roles delete command to delete a custom role. Once deleted the role is inactive and cannot be used to create new IAM policy bindings:
  • gcloud iam roles delete viewer --project $DEVSHELL_PROJECT_ID
• Deleting a custom role:

  • After the role has been deleted, existing bindings remain, but are inactive. The role can be undeleted within 7 days. After 7 days, the role enters a permanent deletion process that lasts 30 days. After 37 days, the Role ID is available to be used again.
  • Note: If a role is being phased out, change its role.stage property to DEPRECATED, and set the `deprecation_message` to let users know what alternative roles should be used or where to get more information.
• Restore a custom role

  • Within the 7 days window you can restore a role. Deleted roles are in a DISABLED state. To make it available again, update the --stage flag:
  • gcloud iam roles undelete viewer --project $DEVSHELL_PROJECT_ID