Skip to main content

GCP Cloud Provider

The GCP (Google Cloud Platform) cloud provider is a production-ready implementation that enables Zenoo Hub to run on Google Cloud infrastructure. It provides seamless integration with core GCP services including Cloud Firestore for storage, Secret Manager for configuration and secrets management, and Cloud Monitoring for metrics publishing. The GCP provider is designed to be highly scalable, secure, and cost-effective, leveraging Google Cloud’s global infrastructure and managed services. It supports Application Default Credentials (ADC) for authentication, making it easy to deploy on GCE, GKE, or Cloud Run without managing service account keys.

Supported GCP Services

Prerequisites

Before using the GCP cloud provider, ensure you have:
  • GCP Project with billing enabled
  • gcloud CLI installed and authenticated (gcloud auth login)
  • Required APIs enabled (see Quick Start below)
  • Service Account with appropriate IAM roles (see IAM Permissions)
  • Spring Boot 3.x application (Hub requires Spring Boot 3.3.11 or later)
  • Java 21 runtime

Quick Start

Get started with the GCP provider in under 10 minutes.

1. Add Dependency

Add the GCP Spring Boot starter to your build.gradle:
Or if using the published artifact:

2. Enable Required APIs

Enable the necessary GCP APIs for your project:

3. Configure Application

Create or update application.yml with minimal GCP configuration:
For local development, authenticate with ADC:

4. Start Application

The Hub will automatically:
  • Connect to Firestore and create necessary collections
  • Initialize Secret Manager for configuration storage
  • Start publishing metrics to Cloud Monitoring

Cloud Firestore Storage

The GCP provider uses Cloud Firestore in Native Mode for storing components, API key mappings, and sharable tokens. Firestore provides real-time synchronization, automatic scaling, and strong consistency guarantees.

Important: Native Mode Required

Critical: The Hub requires Firestore in Native Mode, not Datastore Mode. If you’re creating a new Firestore database, ensure you select Native Mode. The two modes are not compatible and cannot be changed after creation.

Collections Schema

The GCP provider automatically creates and manages three Firestore collections:

Components Collection ({prefix}-components)

Stores component definitions with versioning support. Document ID Pattern: {componentName}_{revision} Fields:
  • componentName (string) - Component identifier
  • revision (number) - Version number (1, 2, 3, …)
  • definition (string) - Component DSL definition (Groovy code)
  • metadata (map) - Component metadata
  • dependencies (array) - List of dependency component names
  • connectors (array) - List of connector names
  • createdAt (timestamp) - Creation timestamp
  • updatedAt (timestamp) - Last update timestamp
LATEST Pointer: The provider maintains a special document {componentName}_LATEST that points to the current active revision. This enables efficient retrieval of the latest version without querying all revisions. Example Documents:

API Keys Collection ({prefix}-api-keys)

Maps component names to their corresponding Secret Manager secret names for API key lookups. Document ID: {componentName} Fields:
  • component (string) - Component name
  • secretName (string) - Secret Manager secret name
  • bidirectional (boolean) - Supports reverse lookup
Purpose: Enables efficient bidirectional mapping between components and API keys stored in Secret Manager. Example Document:

Sharables Collection ({prefix}-sharables)

Stores temporary sharable tokens with automatic TTL-based cleanup. Document ID: {token-uuid} Fields:
  • token (string) - Token identifier
  • payload (string) - Base64-encoded payload
  • expiresAt (timestamp) - Expiration timestamp
  • expired (boolean) - Expiration flag
  • reusable (boolean) - Whether token can be used multiple times
  • ttl (duration) - Time-to-live (triggers automatic deletion)
TTL Feature: Firestore automatically deletes expired documents based on the ttl field, eliminating the need for manual cleanup. Example Document:

Features

  • Atomic LATEST Pointer Updates - Uses Firestore transactions to ensure consistency
  • Component Versioning - Complete revision history for all components
  • Bidirectional API Key Lookup - Fast component-to-secret and secret-to-component mapping
  • Automatic TTL Cleanup - Firestore deletes expired sharables automatically
  • Composite Indexes - Auto-created indexes for efficient queries (if enabled)
  • Strong Consistency - Firestore provides strong consistency for all reads
  • Real-time Updates - Native support for real-time listeners (not used by default)

Configuration

Configure Firestore behavior with these properties:
Notes:
  • prefix - All collection names are prefixed with this value (e.g., zenoo-hub-components)
  • createIndexes - Set to true for automatic composite index creation; set to false for manual management
  • ttlEnabled - Must be true for automatic sharable cleanup
  • retryStrategy - Configures exponential backoff for transient errors

Secret Manager

Google Cloud Secret Manager provides secure, centralized storage for component configuration and API keys. The GCP provider uses Secret Manager for all sensitive data, leveraging automatic encryption at rest and fine-grained IAM access control.

Component Configuration Secrets

Component configuration is stored as versioned secrets in Secret Manager. Naming Convention:
Example:
Features:
  • Version-labeled Secrets - Stores semantic version labels (version-1.0.0) on Secret resource
  • Automatic Version Management - New versions created automatically on updates
  • Caching - Caffeine-based cache reduces Secret Manager API calls
  • Batch Operations - Supports bulk secret loading on startup
Version Management: Secret Manager doesn’t natively support semantic versioning labels on secret versions. The GCP provider works around this by:
  1. Storing version labels (version-{semantic}) on the Secret resource metadata
  2. Mapping semantic versions to Secret Manager version numbers
  3. Managing version limits automatically (deletes oldest versions when limit reached)

API Key Secrets

API keys are stored as JSON-encoded secrets. Naming Convention:
Example:
Secret Structure:
Features:
  • Bidirectional lookup via Firestore API Keys collection
  • JSON serialization/deserialization
  • Automatic caching with configurable TTL
  • Permission metadata support

Configuration

Configure Secret Manager behavior:
Notes:
  • cacheSize - Increase for applications with many configuration keys
  • cacheExpiry - Balance between freshness and API costs
  • versionsLimit - Old versions are automatically deleted when limit is reached
  • forceDelete: false - Recommended for production (enables 30-day recovery window)
  • requestTimeout - 2s recommended to handle Secret Manager eventual consistency

Configuration Reference

Complete reference for all GCP provider configuration properties.

Core GCP Configuration

Firestore Configuration

Secret Manager Configuration

Cloud Monitoring Configuration

Complete Configuration Examples

Minimal Development Configuration

Production Configuration

High Performance Configuration

Multi-Environment Configuration

IAM Permissions

The GCP provider requires specific IAM permissions to access Firestore, Secret Manager, and Cloud Monitoring. This section details the minimum required permissions and recommended IAM roles.

Required Permissions

Firestore Access

Secret Manager Access

Cloud Monitoring

Predefined Roles (Minimum Required)

The simplest approach is to use Google’s predefined IAM roles:

Custom Role (Least Privilege Approach)

For production environments, create a custom role with minimal permissions:
Note: If hub.gcp.firestore.createIndexes=true, add datastore.indexes.create permission.

Service Account Setup

Create Service Account

Grant Permissions

Authentication Options

Option 1: Application Default Credentials (Recommended for GCP) When running on GCP infrastructure (GCE, GKE, Cloud Run), attach the service account to the compute resource:
No credentialsLocation configuration needed - ADC automatically detects the attached service account. Option 2: Service Account Key File (For non-GCP deployments)
In application.yml:
Security Warning: Service account keys are long-lived credentials. Prefer ADC (Option 1) or Workload Identity on GKE. If using keys:
  • Store keys securely (e.g., Google Cloud Secret Manager, Kubernetes secrets)
  • Rotate keys regularly (every 90 days recommended)
  • Never commit keys to source control

Authentication Methods

The GCP provider supports three authentication methods, in order of preference: Application Default Credentials (ADC) is Google’s recommended authentication mechanism. It automatically discovers credentials from the environment in this order:
  1. GOOGLE_APPLICATION_CREDENTIALS environment variable (points to key file)
  2. User credentials from gcloud auth application-default login
  3. Service account attached to GCE VM, GKE pod, or Cloud Run instance
  4. Default service account from Compute Engine metadata service
Configuration: None required - just omit hub.gcp.credentialsLocation Local Development:
GCP Deployment:
Advantages:
  • No credential files to manage
  • Automatic credential refresh
  • Follows Google Cloud best practices
  • Works seamlessly on GCP infrastructure

2. Service Account Key File

Explicitly specify a service account key file path. Configuration:
Or via environment variable:
Use Cases:
  • Running Hub outside GCP (on-premises, other clouds)
  • Testing with specific service account
  • Development environments without gcloud CLI
Disadvantages:
  • Manual key management and rotation required
  • Security risk if key is compromised
  • Must securely distribute keys to all instances

3. GCE/GKE Metadata Service (Automatic)

When running on Google Cloud compute resources with an attached service account, ADC automatically uses the metadata service. Configuration: None required Requirements:
  • Service account attached to compute resource
  • Compute resource has cloud-platform scope (or specific scopes)
Verification:
GKE Workload Identity: For GKE, use Workload Identity for enhanced security:

Performance Tuning

Optimize GCP provider performance for your workload.

Firestore Optimization

Batch Operations: The GCP provider uses batch operations for bulk component updates. Firestore supports up to 500 operations per batch. Composite Indexes: Enable automatic index creation for complex queries:
Or create indexes manually via Firebase Console or firestore.indexes.json. Retry Strategy: Tune retry behavior for your latency requirements:
Connection Pooling: Firestore SDK manages connection pooling automatically. No configuration needed.

Secret Manager Optimization

Cache Configuration: Reduce Secret Manager API calls by tuning the cache:
Cache Hit Rate Monitoring: Monitor cache effectiveness:
Target 95%+ cache hit rate for optimal performance. Batch Secret Loading: Load all secrets at startup to populate cache:
Version Limit: More versions = more storage costs, but enables rollback:

Cloud Monitoring Optimization

Batch Size: Configure batch size based on metric volume:
Selective Metrics: Disable metrics in non-production environments:

Security Best Practices

Secure your GCP provider deployment.

Service Account Security

1. Use Least Privilege IAM Roles Create custom roles with minimum required permissions (see IAM Permissions). 2. Rotate Service Account Keys If using key files, rotate every 90 days:
3. Prefer Workload Identity on GKE Use GKE Workload Identity instead of service account keys for enhanced security and automatic credential rotation. 4. Separate Service Accounts per Environment Use different service accounts for dev, staging, and production:

Secret Management Security

1. Enable 30-Day Recovery for Production
2. Enable Cloud Audit Logs Monitor secret access:
3. Implement Secret Rotation Policies Rotate API keys and sensitive configuration regularly:
  • Database passwords: Every 90 days
  • API keys: Every 180 days
  • Encryption keys: Yearly
4. Use Secret Manager Replication For multi-region deployments:

Network Security

1. VPC Service Controls Restrict Firestore access to specific VPC networks:
2. Private Google Access Enable Private Google Access for GCE instances without external IPs:
3. Cloud NAT for Egress Traffic Use Cloud NAT for controlled egress:

Firestore Security

1. Database-Level IAM Grant permissions at database level, not collection level:
2. Enable Audit Logging Track all Firestore operations:
3. Regular Security Reviews
  • Review service account permissions quarterly
  • Audit Firestore security rules (if using)
  • Check for unused service accounts

Monitoring and Metrics

The GCP provider publishes metrics to Cloud Monitoring for observability.

Cloud Monitoring Integration

The GcpMetricPublisher automatically publishes application metrics to Cloud Monitoring with:
  • Custom dimensions: componentName, operation, status
  • Batch publishing: Up to 200 time series per request
  • Level-based filtering: INFO, ERROR, TRACE
Configuration:

Key Metrics to Monitor

Application Metrics

Published by Hub to Cloud Monitoring:
View in Cloud Console:

GCP Service Metrics

Native GCP service metrics available in Cloud Monitoring: Firestore:
Secret Manager:
Cloud Monitoring:

Setting Up Alerts

Create alert policies for critical metrics:

High Firestore Latency Alert

Low Cache Hit Rate Alert

Secret Manager Error Rate Alert

Dashboards

Create custom dashboards in Cloud Monitoring Console:
  1. Navigate to Monitoring > Dashboards
  2. Click Create Dashboard
  3. Add charts for key metrics:
    • Firestore read/write operations
    • Secret Manager access count
    • Cache hit rate
    • Application latency

Troubleshooting

Common issues and solutions when using the GCP provider.

Authentication Issues

Problem: PermissionDeniedException

Cause: Service account lacks required IAM roles. Solution:

Problem: Application Default Credentials Not Found

Cause: No credentials found in environment. Solution: For local development:
For production, attach service account to compute resource or set:

Firestore Issues

Problem: Cloud Firestore API Not Enabled

Cause: Firestore API not enabled. Solution:

Problem: ComponentNotFoundException

Cause: Firestore collection or document missing, or wrong prefix configuration. Solution:
  1. Check collection prefix matches configuration:
  1. Verify component was stored successfully (check application logs for write errors)
  2. Check Firestore Console for data:
  1. List collections programmatically:

Problem: Firestore in Datastore Mode

Cause: Firestore database is in Datastore Mode, which is incompatible. Solution: Firestore modes cannot be changed after creation. You must:
  1. Create a new GCP project
  2. Enable Firestore in Native Mode
  3. Migrate data from old project (if needed)
Prevention: Always select Native Mode when creating Firestore:

Secret Manager Issues

Problem: Secret Not Found

Cause: Secret doesn’t exist or wrong prefix configuration. Solution:
  1. List existing secrets:
  1. Verify prefix configuration matches Secret Manager naming:
  1. Create missing secret:

Problem: High Cache Miss Rate

Symptoms:
  • High Secret Manager API usage
  • Increased latency
  • hub.cache.miss.rate metric > 20%
Cause: Cache too small or expiry too short for access patterns. Solution: Increase cache size and TTL:
Monitor cache metrics:

Performance Issues

Problem: High Firestore Latency

Symptoms:
  • Slow component loads
  • firestore.googleapis.com/api/request_latencies > 500ms
Cause: Missing composite indexes for queries. Solution:
  1. Check index status:
  1. Enable automatic index creation:
  1. Or create indexes manually via Firebase Console or firestore.indexes.json

Problem: Secret Manager Rate Limiting

Symptoms:
Cause: Too many Secret Manager API calls. Solution:
  1. Increase cache TTL to reduce API calls:
  1. Preload secrets at startup:
  1. Request quota increase (if legitimately needed):

Network Issues

Problem: Connection Timeouts to GCP APIs

Symptoms:
Cause: Network configuration, firewall rules, or regional outage. Solution:
  1. Test connectivity:
  1. Check VPC firewall rules:
  1. Verify Private Google Access (if using private IPs):
  1. Check GCP Status Dashboard:
  1. Increase request timeouts (temporary workaround):

Testing

Test your GCP provider integration locally and in CI/CD.

Local Testing with Firestore Emulator

Use the Firestore emulator for local development and testing without incurring costs or needing network access. 1. Start Firestore Emulator:
2. Configure Application: Set the emulator environment variable before starting your application:
Or in application-test.yml:
3. Run Tests:
Benefits:
  • No GCP credentials needed
  • Fast local testing
  • No costs
  • Isolated test environment
Limitations:
  • Emulator doesn’t support all Firestore features (e.g., TTL)
  • No Secret Manager or Cloud Monitoring emulators

Integration Testing with Real GCP

For comprehensive integration testing, use a dedicated test GCP project. 1. Create Test Project:
2. Test Service Account: Create a service account with limited permissions for testing:
3. Test Configuration:
4. Test Cleanup: Always clean up test resources after tests:
Or use Firestore emulator for unit tests and real GCP only for end-to-end tests.

CI/CD Integration

GitHub Actions Example:

Cost Optimization

Optimize GCP costs for your Hub deployment.

Firestore Costs

Firestore charges for:
  • Document reads - $0.06 per 100,000 documents
  • Document writes - $0.18 per 100,000 documents
  • Document deletes - $0.02 per 100,000 documents
  • Storage - $0.18 per GB/month
  • Network egress - Varies by region
Optimization Strategies:
  1. Enable TTL for Sharables:
Firestore automatically deletes expired documents, saving delete operation costs:
  1. Use LATEST Pointers:
Retrieve latest component version without querying all revisions (saves read operations).
  1. Minimize Write Operations:
  • Only update components when actually changed
  • Batch multiple updates together
  1. Storage Cleanup:
Delete old component revisions:
  1. Regional Selection:
Choose regions with lower costs (e.g., us-central1 vs asia-northeast1).

Secret Manager Costs

Secret Manager charges for:
  • Active secret versions - $0.06 per secret version per month
  • Access operations - $0.03 per 10,000 access operations
Optimization Strategies:
  1. Version Limits:
Limit number of versions to reduce storage costs:
  1. Cache Aggressively:
Reduce access operation costs with longer cache TTL:
  1. Force Delete in Development:
Immediate deletion avoids 30-day retention costs:
  1. Preload at Startup:
Single bulk load is cheaper than many individual accesses:

Cloud Monitoring Costs

Cloud Monitoring charges for:
  • Ingestion - $0.2580 per MB for custom metrics (first 150 MB/month free)
  • API calls - First 1 million free, then $0.01 per 1,000 calls
Optimization Strategies:
  1. Disable in Non-Production:
  1. Batch Metrics:
Maximize batch size to reduce API calls:
  1. Selective Metrics:
Only publish critical metrics (custom implementation).

Multi-Region Considerations

Cost vs Availability Tradeoff:
  • Single Region: Lowest cost, sufficient for most use cases
  • Multi-Region (Automatic): Higher cost, better availability and latency
Recommendation: Start with single region, move to multi-region only if needed for SLA requirements.

Migration

Migrate to GCP provider from other storage backends.

From AWS to GCP

Strategy: Dual-write pattern for zero-downtime migration. Phase 1: Dual Write
  1. Enable both AWS and GCP providers simultaneously
  2. Write to both backends
  3. Read from AWS (existing)
Phase 2: Verification
  1. Verify data consistency between AWS and GCP
  2. Run parallel production traffic (10% to GCP)
  3. Monitor for errors
Phase 3: Cutover
  1. Switch reads to GCP
  2. Continue dual writes for rollback capability
  3. Monitor for 24-48 hours
Phase 4: Cleanup
  1. Disable AWS writes
  2. Remove AWS provider dependency
  3. Archive AWS data

From Local Provider to GCP

Strategy: Export and import data. 1. Export from Local Provider:
2. Update Configuration:
3. Restart Application 4. Verify Data: Check Firestore Console for migrated data. Considerations:
  • Local provider has no persistence - export during runtime
  • Sharable tokens are temporary - may not need migration
  • Test import in dev environment first

See Also