Security

• In Cloud IAM, you grant access to principals. Principals can be of the following types:

  • Google Account
  • Service account
  • Google group
  • Google Workspace account
  • Cloud Identity domain
  • All authenticated users
  • All users
• Roles

  • A role is a collection of permissions. You cannot assign a permission to the user directly; instead you grant them a role. When you grant a role to a user, you grant them all the permissions that the role contains.
• In the SSH session, set the region and zone:

  • gcloud config set compute/region us-east4
  • gcloud config set compute/zone us-east4-c
• Create a VM:

  • gcloud compute instances create lab-1 --zone us-east4-c --machine-type=e2-standard-2

  
• Check your current gcloud configuration. Inside the SSH session run:

  • gcloud config list

  List all the zones available to use by running the following inside the SSH session run:

  • gcloud compute zones list

  The default configuration is stored in ~/.config/gcloud/configurations/config_default.
• If you want to use a zone other than the default zone when creating an instance, you can use --zone switch. For example, gcloud compute instances create lab-1 --zone us-central1-f
• Verify the zone was written to the configuration file. Inside the SSH session run:

  • cat ~/.config/gcloud/configurations/config_default
• Start a new gcloud configuration for the second user account. Inside the SSH session run:

  • gcloud init --no-launch-browser
• * Run `gcloud topic --help` to learn about advanced features of the SDK like arg files and output formatting

  * Run `gcloud cheat-sheet` to see a roster of go-to `gcloud` commands.
• list gce instances:

  • gcloud compute instances list

  Change back to your first user's configuration (default). Inside the SSH session run:

  • gcloud config configurations activate default
• To view all the roles, run the following inside the SSH session run:

  • gcloud iam roles list | grep "name:"

  Inspect one of these roles to see the permissions assigned to the role. To view the permissions use gcloud iam roles describe. Try looking at the simple role roles/compute.instanceAdmin.

  • gcloud iam roles describe roles/compute.instanceAdmin
• Set PROJECTID2 to the second project. Inside the SSH session, run the following:

  • echo "export PROJECTID2=qwiklabs-gcp-04-66723f010294" >> ~/.bashrc
  • . ~/.bashrcgcloud config set project $PROJECTID2
• Install jq:

  • sudo yum -y install epel-release
  • sudo yum -y install jq
• Next, set the value of USERID2 to the second user name and bind the role of viewer to the second user onto the second project:

  • echo "export USERID2=[e-mail]" >> ~/.bashrc
  • . ~/.bashrc
  • gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=roles/viewer
• Create a custom role called devops that has the permissions to create an instance. Inside the SSH session run:

  • 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"
• Bind the role of iam.serviceAccountUser to the second user onto the second project. Inside the SSH session run:

  • gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=roles/iam.serviceAccountUser
• Bind the custom role devops to the second user onto the second project. You can find the second user account on the left of this page. Make sure you set USERID to the second user account.

  • gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=projects/$PROJECTID2/roles/devops
• What are two of the three items you need to provide when binding an IAM role to a project?

  1. account
  2. project id
• • 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. Inside the SSH session run:

  • gcloud iam service-accounts create devops --display-name devops

  Get the service account email address.

  • gcloud iam service-accounts list --filter "displayName=devops"

  Put the email address into a local variable called SA:

  • SA=$(gcloud iam service-accounts list --format="value(email)" --filter "displayName=devops")
• Give the service account the role of iam.serviceAccountUser:

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

  This role allows the service account to assign a service account to a compute instance.
• Cloud KMS 

  • Cloud KMS is a cryptographic key management service on Google Cloud. Before using KMS you need to enable it in your project.
  • enable Cloud KMS API:
  • gcloud services enable cloudkms.googleapis.com
• Cloud KMS:

  Create a Keyring and Cryptokey:

  • In order to encrypt the data, you need to create a KeyRing and a CryptoKey. KeyRings are useful for grouping keys. Keys can be grouped by environment (like test, staging, and prod) or by some other conceptual grouping. For this lab, your KeyRing will be called test and your CryptoKey will be called qwiklab.
• Cloud KMS: Create a Keyring and Cryptokey:

  Run the following command in Cloud Shell to set environment variables:

  • KEYRING_NAME=test CRYPTOKEY_NAME=qwiklab

  Execute the gcloud command to create the KeyRing. For this lab you will be using a global location, but it could also be set to a specific region:

  • gcloud kms keyrings create $KEYRING_NAME --location global

  Next, using the new KeyRing, create a CryptoKey named qwiklab:

  • gcloud kms keys create $CRYPTOKEY_NAME --location global \
  • --keyring $KEYRING_NAME \
  • --purpose encryption
• Cloud KMS: Create a Keyring and Cryptokey:

  • Note: CryptoKeys and KeyRings cannot be deleted in Cloud KMS!

  
• Cloud KMS: Encrypt Your Data:

  Take the contents of the email you looked at earlier and base64 encode it by running the following:

  • PLAINTEXT=$(cat 1. | base64 -w0) Note: Base64 encoding allows binary data to be sent to the API as plaintext. This command works for images, videos, or any other kind of binary data.
  • Using the encrypt endpoint, you can send the base64-encoded text you want to encrypt to the specified key.

  
• Cloud KMS: Encrypt Your Data:

  • Note: The encrypt action will return a different result each time even when using the same text and key.
  • Now that your data is encrypted, you can save it to a file and upload it to your Cloud Storage bucket. To grab the encrypted text from the JSON response and save it to a file, use the command-line utility jq. The response from the previous call can be piped into jq, which can parse out the ciphertext property to the file 1.encrypted. Run the following:

  
• • To verify the encrypted data can be decrypted, call the decrypt endpoint to verify the decrypted text matches the original email. The encrypted data has information on which CryptoKey version was used to encrypt it, so the specific version is never supplied to the decrypt endpoint. Run the following:

  Note: Usually decryption is performed at the application layer.

  1. Now that you have verified the text has been encrypted successfully, upload the encrypted file to your Cloud Storage bucket: gsutil cp 1.encrypted gs://${BUCKET_NAME}

  
• Cloud KMS: Configure IAM permissions

  • In KMS, there are two major permissions to focus on. One permissions allows a user or service account to manage KMS resources, the other allows a user or service account to use keys to encrypt and decrypt data.
  • The permission to manage keys is cloudkms.admin, and allows anyone with the permission to create KeyRings and create, modify, disable, and destroy CryptoKeys. The permission to encrypt and decrypt is cloudkms.cryptoKeyEncrypterDecrypter, and is used to call the encrypt and decrypt API endpoints.
• Cloud KMS: Configure IAM Permissions:

  • To get the current authorized user, run the command below:
  • USER_EMAIL=$(gcloud auth list --limit=1 2>/dev/null | grep '@' | awk '{print $2}')

  Next, assign that user the ability to manage KMS resources. Run the following gcloud command to assign the IAM permission to manage the KeyRing you just created:

  • gcloud kms keyrings add-iam-policy-binding $KEYRING_NAME \
  • --location global \
  • --member user:$USER_EMAIL \
  • --role roles/cloudkms.admin
• • Without the cloudkms.cryptoKeyEncrypterDecrypter permission, the authorized user will not be able to use the keys to encrypt or decrypt data.
• Cloud KMS: Configure IAM Permissions:

  • Since CryptoKeys belong to KeyRings, and KeyRings belong to Projects, a user with a specific role or permission at a higher level in that hierarchy inherits the same permissions on the child resources. For example, a user who has the role of Owner on a Project is also an Owner on all the KeyRings and CryptoKeys in that project. Similarly, if a user is granted the cloudkms.admin role on a KeyRing, they have the associated permissions on the CryptoKeys in that KeyRing.
• Run the following gcloud command to assign the IAM permission to encrypt and decrypt data for any CryptoKey under the KeyRing you created:

  • gcloud kms keyrings add-iam-policy-binding $KEYRING_NAME \ --location global \ --member user:$USER_EMAIL \ --role roles/cloudkms.cryptoKeyEncrypterDecrypte
• Cloud KMS: Back up data on the command line

  • Now that you have an understanding of how to encrypt a single file, and have permission to do so, you can run a script to backup all files in a directory. For this example, copy all emails for allen-p, encrypt them, and upload them to a Cloud Storage bucket.

  1. First, copy all emails for allen-p into your current working directory:
  2. gsutil -m cp -r gs://enron_emails/allen-p
• Cloud KMS: Back up data on the command line

  1. Now copy and paste the following into Cloud Shell to back up and encrypt all the files in the allen-p directory to your Cloud Storage bucket:

  This script loops over all the files in a given directory, encrypts them using the KMS API, and uploads them to Cloud Storage.

  
• Cloud KMS:

  View Cloud Audit logs

  Google Cloud Audit Logging consists of two log streams, Admin Activity and Data Access, which are generated by Google Cloud services to help you answer the question "who did what, where, and when?" within your Google Cloud projects.

  • To view the activity for any resource in KMS, go to Navigation menu > Cloud Overview > Activity tab. This will take you to the Cloud Activity UI and then click on View Log Explorer, Select Cloud KMS Key Ring as the Resource Type and you should see the creation and all modifications made to the KeyRing.
• Create Key Ring Audit Log

  
• Private K8s Cluster:

  • In Kubernetes Engine, a private cluster is a cluster that makes your master inaccessible from the public internet. In a private cluster, nodes do not have public IP addresses, only private addresses, so your workloads run in an isolated environment. Nodes and masters communicate with each other using VPC peering.
  • In the Kubernetes Engine API, address ranges are expressed as Classless Inter-Domain Routing (CIDR) blocks.
• Creating a private K8s cluster

  • When you create a private cluster, you must specify a /28 CIDR range for the VMs that run the Kubernetes master components and you need to enable IP aliases.
  • When you enable IP aliases, you let Kubernetes Engine automatically create a subnetwork for you.
  • Run the following to create the cluster:
  • gcloud beta container clusters create private-cluster \ --enable-private-nodes \ --master-ipv4-cidr 172.16.0.16/28 \ --enable-ip-alias \ --create-subnetwork ""
• Private K8s Cluster:

  • gcloud compute networks subnets describe [SUBNET_NAME] --region=$REGION
  • In the output you can see that one secondary range is for pods and the other secondary range is for services.
  • Notice that privateIPGoogleAccess is set to true. This enables your cluster hosts, which have only private IP addresses, to communicate with Google APIs and services.