Security design principles in GCP - Mini Project: Build & Apply

Implementing Security Design Principles in GCP

📖 Scenario: You are working as a cloud engineer for a small company moving its applications to Google Cloud Platform (GCP). Your task is to set up a simple, secure environment following basic security design principles to protect company data and resources.

🎯 Goal: Build a GCP project configuration that applies key security design principles: least privilege access, network segmentation, and secure storage. You will create a service account with limited permissions, configure a Virtual Private Cloud (VPC) network with subnets, and set up a Cloud Storage bucket with restricted access.

📋 What You'll Learn

Create a service account named app-service-account with the role roles/storage.objectViewer.

Create a VPC network named secure-vpc with two subnets: frontend-subnet and backend-subnet.

Create a Cloud Storage bucket named secure-data-bucket with uniform bucket-level access enabled.

Grant the service account read-only access to the storage bucket.

💡 Why This Matters

🌍 Real World

Companies use these security design principles to protect their cloud resources from unauthorized access and reduce risk.

💼 Career

Cloud engineers and security specialists must implement these principles to build secure cloud environments that comply with best practices and regulations.

1

Create a service account

Create a service account named app-service-account in your GCP project.

GCP

# Create the service account named app-service-account
# Your code here

Hint

Use the gcloud iam service-accounts create command with the exact name app-service-account.

2

Assign storage object viewer role to the service account

Assign the role roles/storage.objectViewer to the service account app-service-account for your project.

GCP

gcloud iam service-accounts create app-service-account --display-name="App Service Account"
# Assign the storage.objectViewer role to app-service-account
# Your code here

Hint

Use gcloud projects add-iam-policy-binding with the service account email and the role roles/storage.objectViewer.

3

Create a VPC network with two subnets

Create a VPC network named secure-vpc with two subnets: frontend-subnet in region us-central1 and backend-subnet in region us-east1.

GCP

gcloud iam service-accounts create app-service-account --display-name="App Service Account"
gcloud projects add-iam-policy-binding $(gcloud config get-value project) --member="serviceAccount:app-service-account@$(gcloud config get-value project).iam.gserviceaccount.com" --role="roles/storage.objectViewer"
# Create the VPC network secure-vpc
# Create frontend-subnet in us-central1
# Create backend-subnet in us-east1
# Your code here

Hint

Use gcloud compute networks create with --subnet-mode=custom and then create two subnets with gcloud compute networks subnets create.

4

Create a secure Cloud Storage bucket and grant access

Create a Cloud Storage bucket named secure-data-bucket with uniform bucket-level access enabled. Then grant the service account app-service-account the role roles/storage.objectViewer on this bucket.

GCP

gcloud iam service-accounts create app-service-account --display-name="App Service Account"
gcloud projects add-iam-policy-binding $(gcloud config get-value project) --member="serviceAccount:app-service-account@$(gcloud config get-value project).iam.gserviceaccount.com" --role="roles/storage.objectViewer"
gcloud compute networks create secure-vpc --subnet-mode=custom
gcloud compute networks subnets create frontend-subnet --network=secure-vpc --region=us-central1 --range=10.0.1.0/24
gcloud compute networks subnets create backend-subnet --network=secure-vpc --region=us-east1 --range=10.0.2.0/24
# Create the Cloud Storage bucket secure-data-bucket with uniform bucket-level access
# Grant app-service-account the storage.objectViewer role on the bucket
# Your code here

Hint

Use gcloud storage buckets create with --uniform-bucket-level-access and then gcloud storage buckets add-iam-policy-binding to grant the service account access.

Practice

1. Which security design principle means giving users only the access they need and nothing more?

easy

A. Secure by default

B. Defense in depth

C. Continuous monitoring

D. Least privilege

Solution

1. Step 1: Understand the principle of least privilege

   Least privilege means users get only the minimum access needed to do their job.

2. Step 2: Compare with other principles

   Defense in depth means multiple layers of security, secure by default means safe settings initially, monitoring means watching for issues.

3. Final Answer:

   Least privilege -> Option D

4. Quick Check:

   Minimum access = Least privilege [OK]

Hint: Minimum access means least privilege [OK]

Common Mistakes:

• Confusing defense in depth with least privilege
• Thinking secure by default means limited access
• Mixing monitoring with access control

2. Which of the following is the correct way to assign a role to a user in GCP IAM using the gcloud CLI?

easy

A. gcloud iam roles assign [e-mail] roles/viewer

B. gcloud iam add-role [e-mail] viewer

C. gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer

D. gcloud iam set-role [e-mail] roles/viewer

Solution

1. Step 1: Recall correct gcloud command syntax for IAM role assignment

   The correct command uses 'projects add-iam-policy-binding' with --member and --role flags.

2. Step 2: Check each option

   gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer matches the correct syntax; others use invalid commands or flags.

3. Final Answer:

   gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer -> Option C

4. Quick Check:

   IAM role assignment uses add-iam-policy-binding [OK]

Hint: Use add-iam-policy-binding with --member and --role [OK]

Common Mistakes:

• Using incorrect gcloud commands like 'iam roles assign'
• Omitting --member or --role flags
• Confusing roles with users in command syntax

3. Consider this GCP IAM policy snippet:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user:[e-mail]"]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": ["user:[e-mail]"]
    }
  ]
}

What access does Alice have on the storage bucket?

medium

A. Full control including deleting objects

B. Read-only access to objects

C. No access at all

D. Can create and delete buckets

Solution

1. Step 1: Identify Alice's assigned role

   Alice has the role 'roles/storage.objectViewer' which grants read-only access to objects.

2. Step 2: Understand role permissions

   ObjectViewer allows viewing objects but not modifying or deleting them.

3. Final Answer:

   Read-only access to objects -> Option B

4. Quick Check:

   ObjectViewer = read-only access [OK]

Hint: Viewer roles mean read-only access [OK]

Common Mistakes:

• Confusing objectAdmin with objectViewer
• Assuming viewer can delete objects
• Mixing bucket-level and object-level permissions

4. You wrote this IAM policy JSON but get an error when applying it:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user:[e-mail]"]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": ["[e-mail]"]
    }
  ]
}

What is the error and how to fix it?

medium

A. Missing 'user:' prefix before bob's email in members; add 'user:'

B. Role 'roles/storage.objectAdmin' does not exist; use 'roles/storage.admin'

C. JSON syntax error; remove trailing commas

D. Members list must be empty for objectAdmin role

Solution

1. Step 1: Check members format in IAM policy

   Each member must have a prefix like 'user:', 'serviceAccount:', etc.

2. Step 2: Identify the missing prefix for [e-mail]

   Bob's member entry lacks 'user:' prefix, causing the error.

3. Final Answer:

   Missing 'user:' prefix before bob's email in members; add 'user:' -> Option A

4. Quick Check:

   Member identifiers need prefixes like 'user:' [OK]

Hint: Always prefix members with user: or serviceAccount: [OK]

Common Mistakes:

• Omitting user: prefix in members list
• Assuming roles names are incorrect without checking
• Misreading JSON syntax errors

5. You want to design a GCP project with strong security. Which combination of principles and practices best protects your resources?

hard

A. Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing

B. Use secure by default settings only, no need for monitoring or role restrictions

C. Grant all users owner role for flexibility, disable monitoring to reduce noise, and use default network settings

D. Assign broad roles to users, enable audit logging, and rely on firewall rules only

Solution

1. Step 1: Identify key security principles for GCP

   Least privilege limits access, defense in depth adds multiple security layers, and continuous auditing monitors activity.

2. Step 2: Evaluate options for best security practice

   Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing combines these principles correctly; others either grant excessive access or skip monitoring.

3. Final Answer:

   Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing -> Option A

4. Quick Check:

   Least privilege + defense in depth + monitoring = strong security [OK]

Hint: Combine least privilege, defense in depth, and monitoring [OK]

Common Mistakes:

• Granting overly broad roles
• Ignoring monitoring and auditing
• Relying only on default settings