Google Cloud Private CA and VPC Service Controls



















Certificate Authority Service and VPC Service Controls in Google Cloud

Overview

Google Cloud Certificate Authority Service provides a managed private certificate authority for issuing, managing, and revoking digital certificates.

The service is commonly called Certificate Authority Service, CAS, or Private CA. It allows an organization to operate a private Public Key Infrastructure without deploying and maintaining its own certificate-authority servers.

Certificate Authority Service can be used to issue certificates for:

  • Internal applications
  • Servers and virtual machines
  • Users and devices
  • Kubernetes workloads
  • Service-to-service authentication
  • Mutual TLS
  • API clients
  • Network appliances
  • Internet of Things devices
  • Hybrid and multicloud workloads

Because a private certificate authority is one of the most sensitive components in an enterprise security architecture, access to the CA should be protected by multiple independent controls.

Google Cloud provides two important layers:

  1. IAM, which determines who can administer the CA or request certificates.
  2. VPC Service Controls, which establishes an additional perimeter around the Certificate Authority Service API and related Google Cloud services.

Together, these controls can reduce the risk of unauthorized certificate issuance, misuse of compromised credentials, and access to sensitive CA-management operations from untrusted environments.

What Is a Private Certificate Authority?

A certificate authority is a trusted entity that signs and issues digital certificates.

A digital certificate connects an identity—such as a server, user, application, or device—to a public key. The certificate can then be used to establish trust between systems.

For example, an internal API might present a certificate containing:

api.internal.example.com

A client that trusts the issuing CA can validate that:

  • The certificate was issued by a trusted authority.
  • The certificate has not expired.
  • The certificate has not been revoked.
  • The certificate is being presented by an entity possessing the corresponding private key.
  • The certificate is valid for the requested identity or hostname.

Certificate-based trust is widely used for TLS, mutual TLS, device authentication, workload identity, code signing, and other cryptographic applications.

Why Use a Managed CA Service?

Operating a private PKI traditionally requires organizations to deploy and maintain:

  • Root CA servers
  • Subordinate CA servers
  • Hardware Security Modules
  • Certificate-enrollment services
  • Certificate Revocation Lists
  • Online Certificate Status Protocol responders
  • Backup and recovery procedures
  • Key-rotation processes
  • Audit and compliance systems
  • High-availability infrastructure

These systems are security-sensitive and operationally complex.

Certificate Authority Service reduces this burden by providing a managed control plane for:

  • Creating root and subordinate CAs
  • Organizing CAs into CA pools
  • Issuing certificates
  • Revoking certificates
  • Publishing Certificate Revocation Lists
  • Applying certificate-issuance policies
  • Creating certificate templates
  • Rotating certificate authorities
  • Controlling access through IAM
  • Recording administrative activity in audit logs
  • Protecting CA signing keys through Cloud KMS-backed key protection

The organization still owns the PKI architecture and policy decisions, but Google manages much of the underlying infrastructure.

Certificate Authority Service Resource Structure

Certificate Authority Service resources are organized approximately as follows:

Google Cloud project
└── Region
    └── CA pool
        ├── Certificate authority
        ├── Certificate authority
        └── Issued certificates

A CA pool is a collection of certificate authorities that share common:

  • IAM policies
  • Certificate-issuance policies
  • Location
  • Operational tier
  • Certificate-publication settings

A pool can contain multiple enabled CAs. This supports CA rotation, increased issuance capacity, and trust-chain transitions without requiring applications to directly select a specific CA for every certificate request.

Is Certificate Authority Service Tied to a VPC?

Not in the same way as a Compute Engine instance or an internal load balancer.

Certificate Authority Service is a regional, project-scoped managed API service. A CA pool is created in a Google Cloud project and region, but it is not placed inside a customer subnet and does not receive an IP address from that VPC.

This distinction is important.

The correct model is:

Project
├── VPC networks and subnets
└── Certificate Authority Service resources

Both resources can exist in the same project, but the CA is accessed through the Certificate Authority Service API:

privateca.googleapis.com

VPC Service Controls protects access to that managed API and its project-scoped resources. It does not protect the CA merely because the CA is “attached” to a VPC.

VPC networks can still be part of the access decision. For example, a service perimeter can permit requests originating from approved VPC networks while rejecting requests made from an untrusted environment.

Why Protect a Private CA?

A private certificate authority is a high-value security resource.

If an unauthorized person can issue a certificate from a trusted CA, that certificate might be used to impersonate:

  • An application server
  • A user
  • A workload
  • A device
  • An internal API
  • A network appliance
  • A privileged administrative service

The attacker would still need the appropriate private key and the target system would need to accept the certificate, but unauthorized certificate issuance can seriously weaken a trust architecture.

High-risk CA operations include:

  • Creating a new CA
  • Enabling or disabling a CA
  • Changing issuance policies
  • Modifying certificate templates
  • Granting certificate-request permissions
  • Issuing certificates
  • Revoking certificates
  • Changing CRL publication settings
  • Deleting a CA
  • Modifying IAM policies

These operations should be protected by IAM, separation of duties, audit logging, and—where appropriate—VPC Service Controls.

The Role of IAM

IAM determines which principals can administer Certificate Authority Service and which principals can request certificates.

A principal might be:

  • A user
  • A group
  • A service account
  • A federated workforce identity
  • A federated workload identity

Google Cloud provides CA-specific roles such as:

  • CA Service Admin — broad administration of Certificate Authority Service
  • CA Service CA Manager — management of CA pools and CAs
  • CA Service Certificate Requester — permission to request certificates
  • CA Service Auditor — read-only access for auditing
  • CA Service Operation Manager — management of long-running CA operations

These roles should be assigned according to job function. Google documents the available roles and permissions in its Certificate Authority Service IAM guidance.

A certificate-requesting workload should not also be able to:

  • Create a root CA
  • Change issuance policy
  • Modify IAM permissions
  • Delete a CA
  • Create unrestricted certificate templates

Similarly, a PKI administrator does not necessarily need permission to use every issued certificate or administer the applications that consume them.

Separation of Duties

A mature PKI design should separate the following responsibilities:

Responsibility Example team
Root CA administration Enterprise security or PKI team
Subordinate CA administration PKI operations
Certificate policy management Security architecture
Certificate requests Approved applications and workloads
IAM administration Identity and access-management team
Perimeter administration Cloud security team
Audit review Risk, compliance, or internal audit
Network configuration Cloud networking team

This reduces the possibility that a single compromised identity can modify policy, issue certificates, and conceal its activity.

Why IAM Alone Might Not Be Sufficient

Suppose an application service account has legitimate permission to request certificates.

If a long-lived key for that service account is accidentally committed to a public repository, an attacker could obtain the credential.

From an IAM perspective:

  • The service account is valid.
  • The credential is valid.
  • The service account has certificate-request permissions.
  • The requested API operation is permitted.

IAM might therefore authorize the request.

VPC Service Controls adds an independent perimeter check. If the request originates outside the approved security context and no ingress rule permits it, the request can be denied even though the credential has valid IAM permissions.

The simplified authorization model becomes:

IAM authorization
        +
VPC Service Controls decision
        =
Certificate Authority Service access

Both layers must allow the request.

How VPC Service Controls Protects Certificate Authority Service

VPC Service Controls allows an organization to define a service perimeter around projects and supported Google Cloud services.

Certificate Authority Service is fully supported by VPC Service Controls. Its service name is:

privateca.googleapis.com

To use Certificate Authority Service in a protected environment, Google currently requires the perimeter to include:

privateca.googleapis.com
cloudkms.googleapis.com
storage.googleapis.com

The Cloud KMS API is required because Certificate Authority Service relies on cryptographic signing keys. Cloud Storage may be used for CA-related publication and storage functions, including CRL and Authority Information Access data.

A simplified perimeter might therefore look like this:

VPC Service Controls perimeter
├── PKI project
├── Approved workload project
├── Certificate Authority Service API
├── Cloud KMS API
└── Cloud Storage API

The perimeter can restrict access from unauthorized projects, networks, identities, and external request contexts.

What the Service Perimeter Actually Protects

VPC Service Controls can help protect operations performed through the Certificate Authority Service API, including access to CA resources within protected projects.

It can reduce the risk of:

  • Calling the CA API with stolen credentials from an unauthorized environment
  • Accessing protected CA resources from an unauthorized project
  • Moving protected service data across the perimeter
  • Using an unapproved external workflow to administer the CA
  • Allowing an unintended cloud environment to request certificates

However, VPC Service Controls does not replace PKI policy.

It does not decide:

  • Which certificate subject names are acceptable
  • Which key algorithms must be used
  • How long certificates should remain valid
  • Which certificate extensions are allowed
  • Whether a certificate requester is entitled to a specific identity
  • Whether an application trusts the correct CA chain

Those controls must be implemented through certificate templates, issuance policies, IAM, application trust configuration, and PKI governance.

VPC Service Controls Access Mechanisms

The original VPC Service Controls model is sometimes described as having four access types:

  1. Perimeter bridges
  2. External ingress access
  3. Egress to external targets
  4. Access levels

That description is useful as an introduction, but the modern design is better understood through the following components.

Ingress Rules

Ingress rules allow approved clients outside a perimeter to access protected resources inside it.

An ingress rule can evaluate:

  • Source identity
  • Source project
  • Source VPC network
  • Access level
  • Target project
  • Target service
  • Permitted API operations

For example, an ingress rule could allow one CI/CD service account to request certificates from a protected CA pool.

A narrow rule might conceptually state:

Allow:
    Approved certificate-requester service account

From:
    Approved build project

To:
    PKI project

For:
    Certificate issuance operations only

The rule should not grant broad access to every identity or every API operation.

Egress Rules

Egress rules allow resources or identities inside a perimeter to access approved resources outside it.

For a PKI implementation, egress might be required when:

  • A protected workflow writes approved output to another project.
  • A certificate-management system calls another Google Cloud service.
  • CRL or certificate-publication workflows use resources outside the perimeter.
  • A centralized automation project interacts with multiple security boundaries.

Egress should be permitted only when required and restricted by identity, destination, service, and operation.

Access Levels

Access Context Manager access levels classify requests according to security context.

An access level can consider attributes such as:

  • Source IP address
  • User or service-account identity
  • Device status
  • Operating system
  • Geographic location
  • VPC network origin
  • Google Cloud project origin

For example:

HIGH-TRUST-ADMIN
=
Approved PKI administrator
AND
Managed corporate device
AND
Approved corporate network

That access level can then be referenced by an ingress rule or service perimeter.

An important clarification is that an access level is not directly attached to a data-classification label on a bucket, disk, or certificate.

The access level classifies the request context. The perimeter, ingress rules, IAM policies, and resource configuration determine which protected resources the request can reach.

Perimeter Bridges

A perimeter bridge allows projects in separate service perimeters to communicate.

However, a bridge is broad and bidirectional. Google generally recommends using ingress and egress rules for new designs because they provide more granular control over:

  • Identities
  • Resources
  • Services
  • API operations
  • Direction of access

A bridge should not be the default solution merely because two protected environments need limited communication.

Example: Blocking Stolen CA Credentials

Consider a service account authorized to request workload certificates.

Authorized request

Approved workload
        |
        | Approved service account
        | Approved project and network context
        v
IAM check: Allow
        |
VPC Service Controls check: Allow
        |
Issuance policy check: Allow
        |
        v
Certificate issued

Request using stolen credentials

Attacker environment
        |
        | Stolen service-account credential
        | Unapproved source context
        v
IAM check: Allow
        |
VPC Service Controls check: Deny
        |
        v
Certificate request blocked

The service-account credential must still be revoked, and the incident must be investigated. The perimeter does not make the stolen credential harmless, but it provides another opportunity to stop its misuse.

Certificate-Issuance Policies

VPC Service Controls protects the boundary around the CA API. Certificate-issuance policies control what the CA is allowed to issue.

A strong issuance policy can restrict:

  • Certificate lifetime
  • Subject fields
  • Subject Alternative Names
  • Key usages
  • Extended key usages
  • Certificate extensions
  • Allowed identity formats
  • Whether callers can specify unrestricted fields

For example, a workload CA might allow certificates only for names under:

*.workloads.internal.example.com

A certificate requester should not be able to request:

admin.internal.example.com

unless the policy explicitly permits it.

Certificate templates can provide reusable, controlled certificate profiles for different workloads.

Examples include:

  • Web-server TLS template
  • Client-authentication template
  • Kubernetes workload template
  • Network-device template
  • Short-lived API certificate template

Root and Subordinate CA Design

A private PKI usually contains at least two levels.

Offline or tightly controlled root CA
└── Issuing subordinate CA
    └── Workload certificates

The root CA establishes the trust anchor. It should be used infrequently and protected more strictly than an issuing CA.

The subordinate CA performs routine certificate issuance.

A larger organization might use several subordinate CAs:

Enterprise root CA
├── Production workload CA
├── Nonproduction workload CA
├── User and device CA
├── Network-device CA
└── Partner-integration CA

This structure limits the consequences of a compromised issuing CA and allows different issuance policies for different certificate types.

CA Pools and Rotation

A CA pool can contain multiple certificate authorities with a common issuance policy and IAM policy.

This allows Google Cloud to distribute certificate requests across enabled CAs and supports controlled CA rotation.

A rotation process can include:

  1. Create a new CA in the existing pool.
  2. Distribute the new trust chain to relying systems.
  3. Enable the new CA.
  4. Allow the old and new CAs to coexist during transition.
  5. Stop issuing from the old CA.
  6. Wait for certificates issued by the old CA to expire or be replaced.
  7. Disable and eventually delete the old CA according to policy.

Applications should trust the appropriate CA chain rather than depending permanently on one individual issuing CA.

Cloud KMS and CA Signing Keys

The security of a CA ultimately depends on its signing key.

Certificate Authority Service uses Cloud KMS-backed keys for CA signing operations. Depending on the security and compliance requirements, organizations can select an appropriate key-protection level, including hardware-backed protection where required.

Key decisions include:

  • Algorithm
  • Key size
  • Protection level
  • Region
  • Rotation design
  • Administrative ownership
  • Destruction policy
  • Separation of CA and key administrators

The CA private signing key should never be made available to ordinary certificate requesters.

Protecting the Certificate Authority Service API without protecting the related Cloud KMS API would leave an incomplete perimeter. This is why the required services and dependent projects must be assessed together.

Private Connectivity

Workloads do not need public IP addresses merely to call Google APIs.

Private Google Access can allow workloads with private IP addresses to access Google APIs and services through Google’s network.

For a tightly controlled environment, the architecture can include:

Private workload
        |
        | Private Google Access
        v
restricted.googleapis.com
        |
        | VPC Service Controls evaluation
        v
Certificate Authority Service API

The restricted Google API endpoint provides access to services supported by VPC Service Controls.

This design can reduce public exposure, but it requires correct:

  • DNS configuration
  • Routing
  • Firewall policies
  • Private Google Access settings
  • Service-perimeter configuration
  • IAM permissions

Private connectivity does not replace authentication or authorization.

Hybrid and On-Premises Certificate Requests

On-premises workloads can also request certificates from Certificate Authority Service.

A typical hybrid path includes:

  1. An on-premises workload
  2. Cloud VPN or Cloud Interconnect
  3. An authorized Google Cloud landing-zone VPC
  4. Private Google Access for on-premises hosts
  5. Private DNS resolution for Google APIs
  6. A VPC Service Controls perimeter
  7. IAM or federated workload credentials
  8. A certificate-issuance policy

The connection path might look like this:

On-premises workload
        |
        | Cloud VPN or Cloud Interconnect
        v
Authorized landing-zone VPC
        |
        | Private Google Access
        v
Certificate Authority Service

The VPN or Interconnect provides connectivity. It does not grant permission to request certificates.

The workload must still satisfy:

  • Authentication
  • IAM authorization
  • Perimeter policy
  • Ingress policy
  • Certificate-issuance policy

Recommended Implementation Process

Step 1: Design the PKI Hierarchy

Determine:

  • Which root and subordinate CAs are required
  • Which environments require separate trust domains
  • Which workloads can share an issuing CA
  • Which certificate types will be supported
  • Required certificate lifetimes
  • Required revocation model
  • Compliance requirements

Step 2: Select the Project and Region

Place the CA resources in a dedicated security or PKI project when possible.

The project should not also host unrelated development workloads.

Consider:

  • Regional availability
  • Data residency
  • Workload locations
  • Disaster-recovery requirements
  • Administrative ownership

Step 3: Create CA Pools and CAs

Create CA pools based on trust and policy boundaries.

Avoid placing every certificate use case into one universal CA pool.

Separate, for example:

  • Production from nonproduction
  • User certificates from workload certificates
  • Internal TLS from device authentication
  • High-assurance certificates from routine certificates

Step 4: Configure IAM

Grant only the required CA-specific roles.

Use:

  • Groups for human administrators
  • Dedicated service accounts for automation
  • Workload Identity Federation where appropriate
  • Short-lived credentials
  • Conditional IAM when useful

Avoid long-lived service-account keys.

Step 5: Define Issuance Policies and Templates

Restrict:

  • Allowed subjects
  • SAN formats
  • Certificate lifetimes
  • Key usages
  • Extended key usages
  • Extensions
  • Certificate profiles

Do not depend on the requesting application to submit safe certificate parameters.

Step 6: Create the Service Perimeter

Add the relevant PKI project and required resources to a VPC Service Controls perimeter.

Restrict at least:

privateca.googleapis.com
cloudkms.googleapis.com
storage.googleapis.com

Review the current Google documentation before deployment because supported services and dependencies can change.

Step 7: Add Narrow Ingress and Egress Rules

Allow only the identities and operations required for:

  • Certificate requests
  • PKI administration
  • CRL publication
  • Monitoring
  • Automation
  • Hybrid access
  • Cross-project integrations

Avoid broad rules such as allowing every identity from an entire organization when only one service account requires access.

Step 8: Configure Private API Access

Where appropriate:

  • Remove public IP addresses from workloads.
  • Enable Private Google Access.
  • Configure DNS for Google API endpoints.
  • Use restricted.googleapis.com.
  • Validate routes and firewall policies.

Step 9: Test in Dry-Run Mode

Before enforcing the perimeter, use VPC Service Controls dry-run mode to identify requests that would be denied.

Test:

  • Certificate issuance
  • Certificate revocation
  • CA administration
  • CRL publication
  • Cloud KMS access
  • Storage dependencies
  • CI/CD automation
  • Hybrid requests
  • Emergency administrative access
  • Monitoring and audit workflows

Step 10: Enable Logging and Alerting

Monitor for:

  • CA creation
  • CA enablement or disablement
  • CA deletion
  • IAM-policy changes
  • Certificate-template changes
  • Unusual issuance volume
  • Unexpected certificate subjects
  • Failed certificate requests
  • Perimeter violations
  • Requests from unusual identities or locations
  • Changes to KMS keys
  • CRL publication failures

Audit logs should be exported to a centralized security project or SIEM where appropriate.

Common Design Mistakes

Treating the CA as a VPC Resource

Certificate Authority Service is not deployed into a subnet. It is a project-scoped managed API service.

A VPC can supply trusted request context and private connectivity, but the CA itself is not assigned a VPC IP address.

Using VPC Service Controls Without IAM

A perimeter does not decide which administrator can create a CA or which workload can request a certificate.

IAM remains mandatory.

Using IAM Without Issuance Policies

A service account with permission to request certificates should not automatically be allowed to request any subject name, certificate lifetime, or key usage.

Issuance policies and templates must constrain the request.

Forgetting Dependent Services

Protecting only:

privateca.googleapis.com

is insufficient for a supported protected deployment.

Cloud KMS and Cloud Storage must also be included in the service perimeter.

Confusing Access Levels with Data Classification

An Access Context Manager access level describes the security context of a request. It is not a label attached directly to “high,” “medium,” or “low” data.

Data classification can influence perimeter design, but it is implemented through project placement, IAM, resource policies, organization policies, and service-perimeter architecture.

Creating Overly Broad Ingress Rules

An ingress rule that permits every user or service account can undermine the value of the perimeter.

Rules should specify:

  • Approved identities
  • Approved sources
  • Approved target resources
  • Approved services
  • Approved operations

Skipping Dry-Run Testing

A CA may depend on KMS, Storage, automation projects, hybrid networks, and external certificate-management systems.

Enforcing a perimeter without testing can interrupt production certificate issuance or revocation.

What VPC Service Controls Does Not Protect

VPC Service Controls provides an additional API security boundary, but it does not replace:

  • IAM
  • Certificate issuance policies
  • Certificate templates
  • Cloud KMS controls
  • VPC firewall rules
  • Private Google Access
  • Organization Policy
  • Audit logging
  • Revocation monitoring
  • Application trust-store management
  • Key protection on certificate-consuming systems
  • Certificate renewal automation

It also does not control what happens to a certificate after it has been legitimately issued.

A certificate is generally public information. Its security depends on the associated private key and how relying systems validate the certificate.

Protecting the CA therefore requires controlling:

  1. Who can administer the CA
  2. Who can request certificates
  3. What kinds of certificates can be issued
  4. From where CA operations can be performed
  5. How CA signing keys are protected
  6. How issued certificate private keys are protected
  7. How revocation and expiration are managed
  8. How applications establish trust

Recommended Defense-in-Depth Model

A mature implementation can combine:

Dedicated PKI project
        +
Root and subordinate CA hierarchy
        +
CA pools
        +
Cloud KMS-backed signing keys
        +
Least-privilege IAM
        +
Certificate templates
        +
Issuance policies
        +
VPC Service Controls
        +
Private Google Access
        +
Restricted Google API endpoint
        +
Centralized audit logging

Each control solves a different security problem.

Security control Primary purpose
IAM Determines who can administer the CA or request certificates
CA hierarchy Separates the trust anchor from routine issuance
CA pools Supports policy consistency, capacity, and rotation
Cloud KMS Protects CA signing keys
Issuance policies Restrict the certificates that may be issued
Certificate templates Standardize certificate profiles
VPC Service Controls Adds a perimeter around protected CA API access
Access Context Manager Evaluates network, identity, device, and request context
Private Google Access Provides private connectivity to Google APIs
Audit logs Records CA administration and certificate activity

Summary

Google Cloud Certificate Authority Service provides a managed private PKI platform for issuing and managing certificates.

The service is created within a project and region, but it is not directly attached to a VPC subnet. It is accessed through the managed Certificate Authority Service API:

privateca.googleapis.com

VPC Service Controls can place an additional security perimeter around this API and the projects containing the CA resources.

For a protected Certificate Authority Service implementation, include:

privateca.googleapis.com
cloudkms.googleapis.com
storage.googleapis.com

IAM determines who can manage the CA or request certificates. Certificate templates and issuance policies determine what certificates may be created. VPC Service Controls determines whether the API request is allowed to cross the security perimeter.

The strongest model is therefore:

IAM + issuance policy + protected signing keys + VPC Service Controls

This layered approach can help prevent a compromised credential, unauthorized workload, or misconfigured project from becoming an easy path to unauthorized certificate issuance.