Configuring IAM Permissions via gcloud

Identity access management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource.

With Cloud IAM it’s possible to grant granular access to specific GCP Resources and prevent unwanted access to other resources.

Identities

Members can be of the following types

  • Google account
  • Service account
  • Google group
  • G Suite Domain
  • Cloud Identity Domain

more information on this here

Roles

A role is a collection of permissions. You cannot assign a permission to a user directly. It has to be done through a role.

There’re 3 kinds of roles

  • Primitive roles: These are owner, editor and viewer
  • Predefined roles: This are the Cloud IAM roles given for a finer-grained access control than primitives.
  • Custom roles: own defined

more information on this here


Manage Cloud SDK

initialize and manage gcloud

# initialize gcloud after installation  
gcloud init

# examine installed and not installed components
gcloud components list

# install all beta components
gcloud components install beta

# create a compute instance
gcloud compute instances create lab-1

change config

# check config
gcloud config list

# list all zones available
gcloud compute zones list

# change config zone
# all options changed with this command are permanent, as they're saved into your home
gcloud config set compute/zone <your-zone>

Create and switch between multiple IAM configs

It’s possible to have more than one configuration on a machine and change between them.

Create a new (second) configuration

This is, when you already have one set. Just run gcloud init and follow the prompt.

# change to default user
gcloud config configurations activate default

Identify and assign correct IAM permissions

# see all roles' name
gcloud iam roles list | grep "name:"

# examine a single role
gcloud iam roles describe <role-name>

# activate a user
gcloud config configurations activate <user-name>

# sets viewer role for a project to a user
gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=roles/viewer

# create new custom role called devops
gcloud iam roles create devops --project $PROJECTID2 --permissions "compute.instances.create,compute.instances.delete,compute.instances.start,compute.instances.stop,
compute.instances.update,compute.disks.create,compute.subnetworks.use,
compute.subnetworks.useExternalIp,compute.instances.setMetadata,compute.instances.setServiceAccount"

# now the role is created, you need to bind the user and role to the project
gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=projects/$PROJECTID2/roles/devops

Using a service account

A typical approach to using GCP is, when you have an application that will use the GCP APIs, you don’t want to have to authenticate every time you launch a new server, so you use service accounts instead.

A service account is a special Google account that belongs to your application or a virtual machine (VM) instead of to an individual end user. Your application uses the service account to call the Google API of a service so that the users aren’t directly involved.

# create the service account  
gcloud iam service-accounts create devops --display-name devops

# get service account email address  
gcloud iam service-accounts list  --filter "displayName=devops"

# put email address into a var  
SA=$(gcloud iam service-accounts list --format="value(email)" --filter "displayName=devops")