Certificate Authority Service in GCP - Mini Project: Build & Apply

Certificate Authority Service

📖 Scenario: You work for a company that needs to securely manage digital certificates for its internal applications. You will set up a Certificate Authority (CA) service on Google Cloud Platform (GCP) to issue and manage certificates.

🎯 Goal: Create a basic Certificate Authority Service setup on GCP using Terraform. You will define the CA pool, create a CA, and configure a certificate template.

📋 What You'll Learn

Create a Certificate Authority Pool named my-ca-pool in the us-central1 region.

Create a Certificate Authority named my-ca inside the my-ca-pool.

Configure the CA with the SUBORDINATE type and ACTIVE state.

Create a certificate template named my-cert-template with server_tls usage.

Use Terraform resource blocks with exact resource names and attributes.

💡 Why This Matters

🌍 Real World

Companies use Certificate Authority Services to securely issue and manage digital certificates for encryption and authentication in their networks and applications.

💼 Career

Understanding how to configure and manage Certificate Authority Services on cloud platforms like GCP is essential for cloud security engineers and infrastructure architects.

1

Create the Certificate Authority Pool

Create a Terraform resource block named google_privateca_ca_pool with the resource name my_ca_pool. Set the name to my-ca-pool and the location to us-central1. Use the tier attribute with value BASIC.

GCP

# Your code here to create the CA pool

Hint

Use the google_privateca_ca_pool resource with the exact name my_ca_pool. Set the name, location, and tier attributes as specified.

2

Create the Certificate Authority

Add a Terraform resource block named google_privateca_certificate_authority with the resource name my_ca. Set the name to my-ca, location to us-central1, and ca_pool to reference the my_ca_pool resource. Set the type attribute to SUBORDINATE and the state attribute to ACTIVE.

GCP

resource "google_privateca_ca_pool" "my_ca_pool" {
  name     = "my-ca-pool"
  location = "us-central1"
  tier     = "BASIC"
}

# Your code here to create the Certificate Authority

Hint

Reference the CA pool resource using google_privateca_ca_pool.my_ca_pool.name for the ca_pool attribute.

3

Create the Certificate Template

Add a Terraform resource block named google_privateca_certificate_template with the resource name my_cert_template. Set the name to my-cert-template and location to us-central1. Under the predefined_values block, set key_usage with base_key_usage having digital_signature and key_encipherment set to true. Also, set extended_key_usage with server_auth set to true.

GCP

resource "google_privateca_ca_pool" "my_ca_pool" {
  name     = "my-ca-pool"
  location = "us-central1"
  tier     = "BASIC"
}

resource "google_privateca_certificate_authority" "my_ca" {
  name     = "my-ca"
  location = "us-central1"
  ca_pool  = google_privateca_ca_pool.my_ca_pool.name
  type     = "SUBORDINATE"
  state    = "ACTIVE"
}

# Your code here to create the Certificate Template

Hint

Use the predefined_values block to set key usage and extended key usage for the certificate template.

4

Link the Certificate Template to the CA Pool

Update the google_privateca_ca_pool resource named my_ca_pool to include the certificate_authority_config block. Inside it, add the certificate_authority block with the certificate_authority attribute referencing the my_ca resource. Also, add the certificate_templates attribute as a list containing the full resource name of the my_cert_template resource.

GCP

resource "google_privateca_ca_pool" "my_ca_pool" {
  name     = "my-ca-pool"
  location = "us-central1"
  tier     = "BASIC"

  # Your code here to link the CA and certificate template
}

resource "google_privateca_certificate_authority" "my_ca" {
  name     = "my-ca"
  location = "us-central1"
  ca_pool  = google_privateca_ca_pool.my_ca_pool.name
  type     = "SUBORDINATE"
  state    = "ACTIVE"
}

resource "google_privateca_certificate_template" "my_cert_template" {
  name     = "my-cert-template"
  location = "us-central1"

  predefined_values {
    key_usage {
      base_key_usage {
        digital_signature = true
        key_encipherment  = true
      }
    }
    extended_key_usage {
      server_auth = true
    }
  }
}

Hint

Use the certificate_authority_config block inside the CA pool to link the CA and certificate template by referencing their resource names.

Practice

1. What is the main purpose of the Certificate Authority Service in Google Cloud?

easy

A. To store large amounts of data securely

B. To create and manage digital certificates for secure communication

C. To monitor network traffic in real-time

D. To provide virtual machines for computing tasks

Solution

1. Step 1: Understand the role of Certificate Authority Service

   This service is designed to create and manage digital certificates that prove identity and secure communication.

2. Step 2: Compare with other options

   Options A, C, and D describe other cloud services unrelated to certificate management.

3. Final Answer:

   To create and manage digital certificates for secure communication -> Option B

4. Quick Check:

   Certificate Authority Service = Manage digital certificates [OK]

Hint: Remember: Certificate Authority = issues certificates [OK]

Common Mistakes:

• Confusing certificate management with data storage
• Thinking it monitors network traffic
• Assuming it provides computing resources

2. Which of the following is the correct way to create a self-signed certificate authority using gcloud CLI?

easy

A. gcloud privateca certificates create my-cert --issuer=my-root --location=us-central1

B. gcloud privateca subordinate create my-sub --subject="CN=My Sub CA" --location=us-central1

C. gcloud privateca roots create my-root --subject="CN=My Root CA" --pool=my-pool --location=us-central1

D. gcloud privateca revoke my-cert --location=us-central1

Solution

1. Step 1: Identify command for self-signed root CA creation

   The command gcloud privateca roots create is used to create a self-signed root certificate authority.

2. Step 2: Verify other options

   gcloud privateca subordinate create my-sub --subject="CN=My Sub CA" --location=us-central1 creates a subordinate CA, C creates a certificate, and D revokes a certificate, so they are incorrect for creating a self-signed CA.

3. Final Answer:

   gcloud privateca roots create my-root --subject="CN=My Root CA" --pool=my-pool --location=us-central1 -> Option C

4. Quick Check:

   Self-signed CA uses 'roots create' command [OK]

Hint: Self-signed CA uses 'roots create' command in gcloud [OK]

Common Mistakes:

• Using subordinate create command for root CA
• Confusing certificate creation with CA creation
• Trying to revoke instead of create

3. Given the following code snippet, what will be the output of the command?

gcloud privateca certificates list --location=us-central1 --ca-pool=my-pool

medium

A. Lists all certificates issued by the CA pool named 'my-pool' in us-central1

B. Deletes all certificates in the CA pool 'my-pool'

C. Creates a new certificate in the CA pool 'my-pool'

D. Shows the details of the CA pool 'my-pool' without certificates

Solution

1. Step 1: Understand the command purpose

   The command gcloud privateca certificates list lists certificates issued by a specified CA pool.

2. Step 2: Analyze parameters

   The parameters specify the location and the CA pool name, so the output will be the list of certificates issued by that pool in that location.

3. Final Answer:

   Lists all certificates issued by the CA pool named 'my-pool' in us-central1 -> Option A

4. Quick Check:

   Certificates list command outputs issued certificates [OK]

Hint: List command shows issued certificates, not create or delete [OK]

Common Mistakes:

• Thinking list deletes or creates certificates
• Confusing CA pool details with certificate list
• Ignoring the location parameter

4. You tried to create a subordinate CA with the command:

gcloud privateca subordinate create my-sub --pool=my-pool --issuer=my-root --location=us-central1

But got an error about missing permissions. What is the most likely cause?

medium

A. You do not have the required IAM role to create subordinate CAs

B. The command syntax is incorrect; 'subordinate create' is invalid

C. The location 'us-central1' does not support subordinate CAs

D. The issuer 'my-root' does not exist in the project

Solution

1. Step 1: Understand permission errors

   Permission errors usually mean the user lacks the required IAM role or permission to perform the action.

2. Step 2: Check command validity and other options

   The command syntax is valid, 'us-central1' supports subordinate CAs, and issuer existence errors usually mention not found, not permissions.

3. Final Answer:

   You do not have the required IAM role to create subordinate CAs -> Option A

4. Quick Check:

   Permission error = missing IAM role [OK]

Hint: Permission errors usually mean missing IAM role [OK]

Common Mistakes:

• Assuming syntax error causes permission issues
• Ignoring IAM roles and permissions
• Confusing location support with permission problems

5. You want to set up a secure internal network where your services trust certificates issued by your own CA. Which steps should you follow using Certificate Authority Service to achieve this?

hard

A. Create multiple root CAs and assign each service a different root CA

B. Create only a self-signed root CA and issue certificates directly from it to services

C. Use Google-managed CA and import your certificates manually to services

D. Create a root CA, create a subordinate CA signed by the root, then issue certificates from the subordinate CA to services

Solution

1. Step 1: Understand best practice for internal CA hierarchy

   Best practice is to create a root CA and then a subordinate CA signed by the root to issue certificates, improving security and manageability.

2. Step 2: Evaluate options

   Create only a self-signed root CA and issue certificates directly from it to services is less secure because issuing directly from root CA is discouraged. Use Google-managed CA and import your certificates manually to services uses Google-managed CA, not your own. Create multiple root CAs and assign each service a different root CA creates unnecessary complexity.

3. Final Answer:

   Create a root CA, create a subordinate CA signed by the root, then issue certificates from the subordinate CA to services -> Option D

4. Quick Check:

   Root CA + subordinate CA hierarchy = secure internal trust [OK]

Hint: Use root CA + subordinate CA for secure internal certificates [OK]

Common Mistakes:

• Issuing certificates directly from root CA
• Using Google-managed CA instead of own CA
• Creating multiple root CAs unnecessarily