Google Cloud - Tensor9

Google Cloud is a fully supported deployment platform for Tensor9 BYOC appliances. Deploying to Google Cloud customer environments provides access to Google’s global infrastructure, its security and scaling controls, and integration with customers’ existing Google Cloud resources.

Overview

When you deploy an application to Google Cloud customer environments using Tensor9 BYOC:

Customer appliances run entirely within the customer’s Google Cloud project
Your control plane orchestrates deployments from your dedicated Tensor9 BYOC AWS account
Service account impersonation enables your control plane to manage customer appliances with customer-approved permissions
Service equivalents compile your origin stack into Google Cloud-native resources

Google Cloud appliances use Google Cloud services for compute, storage, networking, and observability, so they fit into the Google Cloud environments your customers already run.

Prerequisites

Before deploying appliances to Google Cloud customer environments, ensure:

Your control plane

Dedicated AWS account for your Tensor9 BYOC control plane
Control plane installed - See Installing Tensor9 BYOC
Origin stack published - Your application infrastructure defined and uploaded

Customer Google Cloud project

Your customers must provide:

Google Cloud project where the appliance will be deployed
Service accounts configured for the four-phase permissions model (Install, Steady-state, Deploy, Operate)
VPC and networking configured according to their requirements
Sufficient API quotas for your application’s resource needs
Google Cloud region where they want the appliance deployed

Your development environment

gcloud CLI installed and configured
Terraform or OpenTofu (if using Terraform origin stacks)
Docker (if deploying container-based applications)

How Google Cloud appliances work

Google Cloud appliances are deployed using Google Cloud-native services orchestrated by your Tensor9 BYOC control plane.

Customer provisions service accounts

Your customer creates four service accounts in their Google Cloud project, each corresponding to a permission phase: Install, Steady-state, Deploy, and Operate. These service accounts define what your control plane can do within their environment.The customer configures IAM policies that allow your control plane’s service account to impersonate these service accounts with appropriate conditions (time windows, approval labels, etc.).

You create a release for the customer appliance

You create a release targeting the customer’s appliance:

tensor9 stack release create \
  -appName my-app \
  -customerName acme-corp \
  -vendorVersion "1.0.0" \
  -description "Initial production deployment"

Your control plane compiles your origin stack into a deployment stack tailored for Google Cloud, compiling any non-Google Cloud resources to their Google Cloud service equivalents. The deployment stack downloads to your local environment.

Customer grants deploy access

The customer approves the deployment by granting temporary deploy access. This can be manual (updating IAM policy conditions) or automated (scheduled maintenance windows).Once approved, the Tensor9 BYOC controller in the appliance can impersonate the Deploy service account in the customer’s project.

You deploy the release

You run the deployment locally against the downloaded deployment stack:

cd acme-corp-production
tofu init
tofu apply

The deployment stack is configured to route resource creation through the Tensor9 BYOC controller inside the customer’s appliance. The controller impersonates the Deploy service account and creates all infrastructure resources in the customer’s Google Cloud project:

VPCs, subnets, firewall rules
Compute Engine instances, GKE clusters, Cloud Functions
Cloud SQL databases, Cloud Storage buckets, Memorystore clusters
Cloud Logging log sinks, service accounts, Cloud DNS records
Any other Google Cloud resources defined in your origin stack

Steady-state observability begins

After deployment, your control plane uses the Steady-state service account to continuously collect observability data (logs, metrics, traces) from the customer’s appliance without requiring additional approvals.This data flows to your observability sink, giving you visibility into appliance health and performance.

Service adapters

When you deploy an origin stack to Google Cloud customer environments, Tensor9 BYOC automatically compiles resources from other cloud providers to their Google Cloud equivalents. This allows you to maintain a single origin stack and deploy it across different customer environments.

How service equivalents work

When compiling a deployment stack for Google Cloud:

AWS resources are compiled - AWS resources are converted to their Google Cloud equivalents
Generic resources are adapted - Cloud-agnostic resources (like Kubernetes manifests) are adapted for Google Cloud
Configuration is adjusted - Resource configurations are modified to match Google Cloud conventions and best practices

Common service equivalents

Which AWS services reach Google Cloud, what each becomes, and the tier it lands at are maintained in one place rather than repeated per form factor: see service adapters and the generated Service Catalog.

EC2, DynamoDB, and EFS are all offered. Some services are not adapted yet, including Step Functions, API Gateway, Cognito, AppSync, and Redshift. See Service Catalog.

Example: Compiling an AWS origin stack

If your origin stack defines a Lambda function:

# Origin stack (AWS)
resource "aws_lambda_function" "api" {
  function_name = "${var.namespace}myapp-api"
  handler       = "index.handler"
  runtime       = "nodejs18.x"
  role          = aws_iam_role.api_role.arn

  environment {
    variables = {
      NAMESPACE = var.namespace
    }
  }
}

Tensor9 BYOC compiles it to a Cloud Function for Google Cloud:

# Deployment stack (Google Cloud)
resource "google_cloudfunctions2_function" "api" {
  name     = "${var.namespace}myapp-api"
  location = var.region
  project  = var.project_id

  build_config {
    runtime     = "nodejs18"
    entry_point = "handler"
  }

  service_config {
    environment_variables = {
      NAMESPACE = var.namespace
    }

    service_account_email = google_service_account.api.email
  }
}

Permissions model

Google Cloud appliances use a four-phase service account permissions model that balances operational capability with customer control.

The four permission phases

Phase	Service Account	Purpose	Access Pattern
Install	`[email protected]`	Initial setup, major infrastructure changes	Customer-approved, rare
Steady-state	`[email protected]`	Continuous observability collection (read-only)	Active by default
Deploy	`[email protected]`	Deployments, updates, configuration changes	Customer-approved, time-bounded
Operate	`[email protected]`	Remote operations, troubleshooting, debugging	Customer-approved, time-bounded

Service account structure

Each service account is created in the customer’s Google Cloud project with IAM policies that allow your control plane to impersonate it. Example: Deploy service account with conditional access

# Deploy service account
resource "google_service_account" "deploy" {
  account_id   = "tensor9-deploy-000000007e"
  display_name = "Tensor9 Deploy Service Account"
  project      = var.customer_project_id
}

# IAM binding allowing vendor control plane to impersonate
resource "google_service_account_iam_binding" "deploy_impersonation" {
  service_account_id = google_service_account.deploy.name
  role               = "roles/iam.serviceAccountTokenCreator"

  members = [
    "serviceAccount:[email protected]"
  ]

  condition {
    title       = "Deploy access time window"
    description = "Allow impersonation during approved time window"
    expression  = <<-EOT
      request.time >= timestamp("2024-01-01T00:00:00Z") &&
      request.time <= timestamp("2024-12-31T23:59:59Z") &&
      resource.labels.deploy_access == "enabled"
    EOT
  }
}

# Grant Deploy service account permissions in customer project
resource "google_project_iam_member" "deploy_compute" {
  project = var.customer_project_id
  role    = "roles/compute.instanceAdmin.v1"
  member  = "serviceAccount:${google_service_account.deploy.email}"
}

resource "google_project_iam_member" "deploy_storage" {
  project = var.customer_project_id
  role    = "roles/storage.admin"
  member  = "serviceAccount:${google_service_account.deploy.email}"
}

Your control plane can only impersonate the Deploy service account when:

The deploy_access label is set to “enabled”
The current time is within the allowed window

Customers control when and how long deploy access is granted. Example: Steady-state service account (read-only observability)

# Steady-state service account
resource "google_service_account" "steadystate" {
  account_id   = "tensor9-steadystate-000000007e"
  display_name = "Tensor9 Steady-State Service Account"
  project      = var.customer_project_id
}

# Allow vendor control plane to impersonate (no time restriction)
resource "google_service_account_iam_binding" "steadystate_impersonation" {
  service_account_id = google_service_account.steadystate.name
  role               = "roles/iam.serviceAccountTokenCreator"

  members = [
    "serviceAccount:[email protected]"
  ]
}

# Grant read-only permissions, scoped to the appliance's own project
resource "google_project_iam_member" "steadystate_logging_viewer" {
  project = var.customer_project_id
  role    = "roles/logging.viewer"
  member  = "serviceAccount:${google_service_account.steadystate.email}"
}

resource "google_project_iam_member" "steadystate_monitoring_viewer" {
  project = var.customer_project_id
  role    = "roles/monitoring.viewer"
  member  = "serviceAccount:${google_service_account.steadystate.email}"
}

The Steady-state service account:

Can read observability data from the appliance’s project, which holds only that appliance’s resources
Cannot modify, delete, or terminate any resources
Cannot change IAM policies

Deployment workflow with service accounts

Customer grants deploy access

Customer approves a deployment by setting the deploy_access label to “enabled” and defining a time window. This can be done manually or through automated approval workflows.

You execute deployment locally

You run the deployment locally against the downloaded deployment stack:

cd acme-corp-production
tofu init
tofu apply

The deployment stack is configured to route resource creation through the Tensor9 BYOC controller in the appliance.

Controller impersonates Deploy service account and creates resources

For each resource Terraform attempts to create, the Tensor9 BYOC controller inside the appliance impersonates the Deploy service account and creates the resource in the customer’s project.All infrastructure changes occur within the customer’s project using their Deploy service account permissions.

Deploy access expires

After the time window expires, the Deploy service account can no longer be impersonated. Your control plane automatically reverts to using only the Steady-state service account for observability.

See Permissions Model for detailed information on all four phases.

Networking

Google Cloud appliances use an isolated networking architecture with a Tensor9 BYOC controller that manages communication with your control plane.

Tensor9 BYOC controller VPC

When an appliance is deployed, Tensor9 BYOC creates an isolated VPC containing the Tensor9 BYOC controller. This VPC is configured with:

Cloud NAT: Provides outbound internet connectivity
Route to control plane: Establishes a secure channel to your Tensor9 BYOC control plane
No ingress firewall rules: The controller VPC does not accept inbound connections - all communication is outbound-only

The Tensor9 BYOC controller uses this secure channel to:

Receive deployments: Deployment stacks are pushed from your control plane to the appliance
Configure observability pipeline: Set up log, metric, and trace forwarding to your observability sink
Receive operational commands: Execute remote operations initiated from your control plane

Outbound-only security model

The Tensor9 BYOC controller in your customer’s appliance is designed to only make outbound connections and not require ingress ports to be opened in your customer’s network perimeter:

# Example: Controller VPC configuration (managed by Tensor9)
resource "google_compute_network" "tensor9_controller" {
  name                    = "tensor9-controller-000000007e"
  auto_create_subnetworks = false
  project                 = var.customer_project_id
}

resource "google_compute_subnetwork" "controller" {
  name          = "tensor9-controller-subnet-000000007e"
  ip_cidr_range = "10.0.0.0/24"
  region        = var.region
  network       = google_compute_network.tensor9_controller.id
  project       = var.customer_project_id
}

# Cloud Router for NAT
resource "google_compute_router" "controller" {
  name    = "tensor9-controller-router-000000007e"
  region  = var.region
  network = google_compute_network.tensor9_controller.id
  project = var.customer_project_id
}

# Cloud NAT for outbound connectivity
resource "google_compute_router_nat" "controller" {
  name                               = "tensor9-controller-nat-000000007e"
  router                             = google_compute_router.controller.name
  region                             = var.region
  nat_ip_allocate_option             = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
  project                            = var.customer_project_id
}

# Firewall: egress only, no ingress
resource "google_compute_firewall" "controller_egress" {
  name    = "tensor9-controller-egress-000000007e"
  network = google_compute_network.tensor9_controller.name
  project = var.customer_project_id

  allow {
    protocol = "tcp"
    ports    = ["443"]
  }

  direction          = "EGRESS"
  destination_ranges = ["0.0.0.0/0"]
}

# No ingress firewall rules - controller never accepts inbound connections

This architecture ensures that the customer’s appliance cannot be compromised via inbound network attacks on the controller.

Application VPC topology

Your application resources run in their own VPC(s), completely separate from the Tensor9 BYOC controller VPC. The application VPC topology is defined entirely by your origin stack - whatever VPC resources you define in your origin stack will be deployed into the appliance. Example: Application VPC with internet-facing load balancer If your origin stack defines an AWS VPC with public subnets and a load balancer, that topology will compile to Google Cloud VPC resources in the customer’s appliance:

# AWS origin stack - Application VPC
resource "aws_vpc" "application" {
  cidr_block           = "10.1.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "${var.namespace}myapp-vpc"
  }
}

# Public subnet for load balancer
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.application.id
  cidr_block              = "10.1.0.0/24"
  availability_zone       = data.aws_availability_zones.available.names[0]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.namespace}myapp-public"
  }
}

# Private subnet for application servers
resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.application.id
  cidr_block        = "10.1.1.0/24"
  availability_zone = data.aws_availability_zones.available.names[0]

  tags = {
    Name = "${var.namespace}myapp-private"
  }
}

# NAT Gateway for private subnet outbound access
resource "aws_eip" "nat" {
  domain = "vpc"

  tags = {
    Name = "${var.namespace}myapp-nat"
  }
}

resource "aws_nat_gateway" "application" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.id

  tags = {
    Name = "${var.namespace}myapp-nat"
  }
}

# Application Load Balancer
resource "aws_lb" "application" {
  name               = "${var.namespace}myapp-lb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.lb.id]
  subnets            = [aws_subnet.public.id]
}

This application VPC topology is deployed alongside the Tensor9 BYOC controller VPC, but they remain completely separate. The controller VPC manages the control plane connection, while the application VPC handles your application’s traffic and resources.

Resource naming and labeling

All Google Cloud resources should incorporate the @namespace annotated variable to ensure uniqueness across multiple customer appliances.

Parameterization pattern

This page uses max_size=16 because service account IDs cap at 30 characters, which a longer namespace would exhaust.

#@namespace(max_size=16, delimiter='-')
variable "namespace" {
  type        = string
  description = "Prefix that keeps globally-unique resource names distinct per install"
  default     = ""
}

# Cloud Storage buckets
resource "google_storage_bucket" "data" {
  name     = "${var.namespace}myapp-data"
  location = var.region
  project  = var.project_id
}

# Cloud SQL databases
resource "google_sql_database_instance" "postgres" {
  name             = "${var.namespace}myapp-db"
  database_version = "POSTGRES_15"
  region           = var.region
  project          = var.project_id

  settings {
    tier = "db-f1-micro"
  }
}

# Cloud Functions
resource "google_cloudfunctions2_function" "api" {
  name     = "${var.namespace}myapp-api"
  location = var.region
  project  = var.project_id

  build_config {
    runtime     = "nodejs20"
    entry_point = "handleRequest"
  }
}

# Service accounts
resource "google_service_account" "app" {
  account_id   = "${var.namespace}myapp"
  display_name = "Application Service Account"
  project      = var.project_id
}

Labeling resources

Label resources with whatever your own tooling needs. Tensor9 BYOC does not require any particular label: each appliance gets its own Google Cloud project, so telemetry and permissions are already scoped to it.

resource "google_storage_bucket" "data" {
  name     = "${var.namespace}myapp-data"
  location = var.region
  project  = var.project_id

  labels = {
    application = "my-app"
    managed-by  = "tensor9"
  }
}

resource "google_compute_instance" "app" {
  name         = "${var.namespace}myapp-instance"
  machine_type = "e2-medium"
  zone         = "${var.region}-a"
  project      = var.project_id

  labels = {
    application = "my-app"
    managed-by  = "tensor9"
  }
}

The appliance’s own project:

Scopes IAM role bindings to a single appliance
Isolates Cloud Logging and Cloud Monitoring telemetry by appliance
Helps customers track costs per appliance
Lets Tensor9 BYOC controllers discover the appliance’s resources

Observability

Google Cloud appliances provide observability through Cloud Logging, Cloud Monitoring, and Cloud Trace.

Cloud Logging

Application and infrastructure logs flow to Cloud Logging:

# Log sink for application logs
resource "google_logging_project_sink" "app_logs" {
  name        = "${var.namespace}myapp-logs"
  destination = "storage.googleapis.com/${google_storage_bucket.logs.name}"
  project     = var.project_id

  unique_writer_identity = true
}

# Grant sink service account permissions
resource "google_storage_bucket_iam_member" "logs_writer" {
  bucket = google_storage_bucket.logs.name
  role   = "roles/storage.objectCreator"
  member = google_logging_project_sink.app_logs.writer_identity
}

Your control plane uses the Steady-state service account to continuously fetch logs:

gcloud logging read \
  --limit 100 \
  --format json \
  --project customer-project-id \
  --impersonate-service-account [email protected]

Logs are forwarded to your observability sink for centralized monitoring.

Cloud Monitoring

Infrastructure metrics are automatically collected:

Compute Engine: CPU utilization, network I/O, disk I/O
Cloud SQL: Database connections, query latency, storage usage
Cloud Functions: Invocations, execution time, errors
GKE: Node CPU/memory, pod counts, API server metrics
Cloud Load Balancing: Request counts, latency, HTTP status codes

Cloud Trace

Enable distributed tracing for Cloud Functions and containerized applications:

resource "google_cloudfunctions2_function" "api" {
  name     = "${var.namespace}myapp-api"
  location = var.region
  project  = var.project_id

  build_config {
    runtime     = "nodejs20"
    entry_point = "handleRequest"
  }

  service_config {
    environment_variables = {
      NAMESPACE                      = var.namespace
      GOOGLE_CLOUD_TRACE_ENABLED     = "true"
      GOOGLE_CLOUD_TRACE_NEW_CONTEXT = "true"
    }
  }
}

Cloud Trace data is accessible through the Steady-state service account and forwarded to your observability sink.

Cloud Audit Logs

All API calls within the customer’s Google Cloud project are logged to Cloud Audit Logs, providing a complete audit trail of what your control plane does:

Service account impersonations
Resource creation, modification, deletion
Permission denials
Configuration changes

Customers have full visibility into your control plane’s actions through their Cloud Audit Logs.

Artifacts

Google Cloud appliances automatically provision private artifact repositories to store container images and application files deployed by your deployment stacks.

Container images (Artifact Registry)

When you deploy an appliance, Tensor9 BYOC automatically provisions a private Artifact Registry repository in the customer’s Google Cloud project to store your container images. Example: Origin stack with container service Your AWS origin stack references container images from your vendor’s Amazon ECR:

# ECS Fargate service in your origin stack
resource "aws_ecs_task_definition" "api" {
  family                   = "${var.namespace}myapp-api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = "256"
  memory                   = "512"

  container_definitions = jsonencode([
    {
      name  = "api"
      # Reference to your vendor ECR registry
      image = "123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp/api:1.0.0"
      portMappings = [
        {
          containerPort = 8080
          protocol      = "tcp"
        }
      ]
      environment = [
        {
          name  = "NAMESPACE"
          value = var.namespace
        }
      ]
    }
  ])
}

Container copy during deployment When you deploy the deployment stack, Tensor9 BYOC automatically:

Detects the container image reference in your ECS task definition
Provisions a private Artifact Registry repository in the appliance (e.g., us-docker.pkg.dev/customer-project/myapp-000000007e/api)
Copies the container image from your vendor ECR registry to the appliance’s private Artifact Registry
Rewrites the deployment stack to reference the appliance-local registry

The compiled deployment stack will contain a Cloud Run service with the rewritten image reference:

template {
  containers {
    # Rewritten to reference appliance's private Artifact Registry
    image = "us-docker.pkg.dev/customer-project/myapp-000000007e/api:1.0.0"
    # ... rest of configuration compiled from ECS task definition
  }
}

This ensures the container image is stored locally in the customer’s project and the application doesn’t depend on cross-project access to your vendor registry. Artifact lifecycle Container artifacts are tied to the deployment stack lifecycle:

Deploy (tofu apply): Tensor9 BYOC copies the container image from your vendor registry to the appliance’s private registry
Destroy (tofu destroy): Deleting the deployment stack also deletes the copied container artifact from the appliance’s private registry

This ensures that artifacts are cleaned up when deployments are removed, preventing orphaned resources.

Function source code

For Lambda functions in your AWS origin stack, Tensor9 BYOC automatically handles copying function source code to the customer’s Google Cloud environment:

# Lambda function in your AWS origin stack
resource "aws_lambda_function" "processor" {
  function_name = "${var.namespace}myapp-processor"
  handler       = "processor.process_event"
  runtime       = "python3.11"
  role          = aws_iam_role.processor.arn

  # Reference to function code in your vendor S3 bucket
  s3_bucket = "vendor-lambda-sources"
  s3_key    = "processor-v1.0.0.zip"

  environment {
    variables = {
      NAMESPACE = var.namespace
    }
  }
}

During deployment, Tensor9 BYOC:

Provisions a private Cloud Storage bucket in the appliance for function sources
Copies the Lambda source archive from your vendor S3 bucket to the appliance’s Cloud Storage bucket
Compiles the Lambda function to a Cloud Run service with the appliance-local source reference

Like container images, destroying the deployment stack (tofu destroy) removes the copied function source archives. See Artifacts for documentation on artifact management, including immutability requirements and supported artifact types.

Secrets management

Store secrets in AWS Secrets Manager or AWS Systems Manager Parameter Store in your AWS origin stack, then pass them to your application as environment variables.

Secret naming and injection

Always use parameterized secret names and inject them as environment variables:

# AWS Secrets Manager secret
resource "aws_secretsmanager_secret" "db_password" {
  name = "prod/db/password"
}

resource "aws_secretsmanager_secret_version" "db_password" {
  secret_id     = aws_secretsmanager_secret.db_password.id
  secret_string = var.db_password
}

# ECS Fargate task - inject secret as environment variable
resource "aws_ecs_task_definition" "app" {
  family = "${var.namespace}myapp"

  container_definitions = jsonencode([
    {
      name  = "app"
      image = "myapp:latest"

      # Inject secret as environment variable
      secrets = [
        {
          name      = "DB_PASSWORD"
          valueFrom = aws_secretsmanager_secret.db_password.arn
        }
      ]
    }
  ])
}

Your application reads secrets from environment variables:

import os

# Read secret from environment variable
db_password = os.environ['DB_PASSWORD']

Your application can keep using AWS Secrets Manager SDK calls on Google Cloud through the configured Secrets Manager service adapter. The adapter serves supported requests and maintains secret values and versions. Review the target-specific limits before deployment; environment variables remain an option for values needed at startup.

See Secrets for detailed secret management patterns.

Operations

Perform remote operations on Google Cloud appliances using the Operate service account.

kubectl on GKE

Execute kubectl commands against GKE clusters:

tensor9 ops kubectl \
  -appName my-app \
  -customerName acme-corp \
  -originResourceId "google_container_cluster.main" \
  -command "kubectl get pods -n my-app-namespace"

Output:

NAME                     READY   STATUS    RESTARTS   AGE
api-7d9f8b5c6d-9k2lm    1/1     Running   0          2h
worker-5c8d7b4f3-8h4km  1/1     Running   0          2h

gcloud CLI operations

Execute gcloud commands:

# List Cloud Storage bucket contents
tensor9 ops gcloud \
  -appName my-app \
  -customerName acme-corp \
  -originResourceId "google_storage_bucket.data" \
  -command "gcloud storage ls gs://myapp-data-000000007e/"

# Invoke Cloud Function
tensor9 ops gcloud \
  -appName my-app \
  -customerName acme-corp \
  -originResourceId "google_cloudfunctions2_function.api" \
  -command "gcloud functions call myapp-api-000000007e --data '{\"test\":true}'"

# View Cloud SQL status
tensor9 ops gcloud \
  -appName my-app \
  -customerName acme-corp \
  -originResourceId "google_sql_database_instance.postgres" \
  -command "gcloud sql instances describe myapp-db-000000007e"

Database queries

Execute SQL queries against Cloud SQL databases:

tensor9 ops db \
  -appName my-app \
  -customerName acme-corp \
  -originResourceId "google_sql_database_instance.postgres" \
  -command "SELECT count(*) FROM users WHERE created_at > NOW() - INTERVAL '24 hours'"

Operations endpoints

Create temporary operations endpoints for interactive access:

# Create kubectl endpoint
tensor9 ops endpoint create \
  -appName my-app \
  -customerName acme-corp \
  -originResourceId "google_container_cluster.main" \
  -endpointType kubectl \
  -ttl 3600

# Output:
# Endpoint created: https://ops.tensor9.io/kubectl/abc123
# Expires in: 1 hour
# Use: kubectl --server=https://ops.tensor9.io/kubectl/abc123 get pods

See Operations for the full operations documentation.

Example: Complete Google Cloud appliance

Here’s a complete example of a deployment stack for a Google Cloud appliance, compiled from an AWS origin stack:

main.tf

# VPC
resource "google_compute_network" "main" {
  name                    = "${var.namespace}myapp-vpc"
  auto_create_subnetworks = false
  project                 = var.project_id
}

# Subnets
resource "google_compute_subnetwork" "private" {
  name          = "${var.namespace}myapp-private"
  ip_cidr_range = "10.0.1.0/24"
  region        = var.region
  network       = google_compute_network.main.id
  project       = var.project_id

  secondary_ip_range {
    range_name    = "pods"
    ip_cidr_range = "10.1.0.0/16"
  }

  secondary_ip_range {
    range_name    = "services"
    ip_cidr_range = "10.2.0.0/16"
  }
}

# GKE Cluster
resource "google_container_cluster" "main" {
  name     = "${var.namespace}myapp-cluster"
  location = var.region
  project  = var.project_id

  network    = google_compute_network.main.name
  subnetwork = google_compute_subnetwork.private.name

  ip_allocation_policy {
    cluster_secondary_range_name  = "pods"
    services_secondary_range_name = "services"
  }

  logging_config {
    enable_components = ["SYSTEM_COMPONENTS", "WORKLOADS"]
  }

  monitoring_config {
    enable_components = ["SYSTEM_COMPONENTS"]
    managed_prometheus {
      enabled = true
    }
  }

  resource_labels = {
  }
}

# Cloud SQL PostgreSQL
resource "google_sql_database_instance" "postgres" {
  name             = "${var.namespace}myapp-db"
  database_version = "POSTGRES_15"
  region           = var.region
  project          = var.project_id

  settings {
    tier              = "db-f1-micro"
    availability_type = "REGIONAL"
    disk_size         = 20

    backup_configuration {
      enabled    = true
      start_time = "03:00"
    }

    ip_configuration {
      ipv4_enabled    = false
      private_network = google_compute_network.main.id
    }

    user_labels = {
    }
  }

  deletion_protection = false
}

resource "google_sql_database" "main" {
  name     = "myapp"
  instance = google_sql_database_instance.postgres.name
  project  = var.project_id
}

resource "google_sql_user" "main" {
  name     = "admin"
  instance = google_sql_database_instance.postgres.name
  password = var.db_password
  project  = var.project_id
}

# Cloud Storage bucket
resource "google_storage_bucket" "data" {
  name     = "${var.namespace}myapp-data"
  location = var.region
  project  = var.project_id

  versioning {
    enabled = true
  }
}

# Memorystore Redis
resource "google_redis_instance" "cache" {
  name           = "${var.namespace}myapp-redis"
  tier           = "BASIC"
  memory_size_gb = 1
  region         = var.region
  project        = var.project_id

  redis_version     = "REDIS_7_0"
  authorized_network = google_compute_network.main.id
}

# Secrets (AWS Secrets Manager - proxied by Tensor9)
resource "aws_secretsmanager_secret" "db_password" {
  name = "prod/db/password"
}

resource "aws_secretsmanager_secret_version" "db_password" {
  secret_id     = aws_secretsmanager_secret.db_password.id
  secret_string = var.db_password
}

variables.tf

#@namespace(max_size=16, delimiter='-')
variable "namespace" {
  type        = string
  description = "Prefix that keeps globally-unique resource names distinct per install"
  default     = ""
}

variable "project_id" {
  type        = string
  description = "Google Cloud project ID"
}

variable "db_password" {
  type        = string
  description = "Database master password"
  sensitive   = true
}

variable "region" {
  type        = string
  description = "Google Cloud region"
  default     = "us-central1"
}

outputs.tf

output "gke_cluster_endpoint" {
  description = "GKE cluster endpoint"
  value       = google_container_cluster.main.endpoint
  sensitive   = true
}

output "database_connection" {
  description = "Cloud SQL connection name"
  value       = google_sql_database_instance.postgres.connection_name
  sensitive   = true
}

output "redis_host" {
  description = "Redis instance host"
  value       = google_redis_instance.cache.host
}

output "data_bucket" {
  description = "Cloud Storage bucket name"
  value       = google_storage_bucket.data.name
}

Best practices

Prefix all resource names with the namespace

Every Google Cloud resource with a name or identifier should be prefixed with ${var.namespace} to prevent conflicts across customer appliances. Don’t skip project-scoped names: nothing stops two installs sharing one project:

# ✓ CORRECT
resource "google_storage_bucket" "data" {
  name = "${var.namespace}myapp-data"
}

resource "google_service_account" "app" {
  account_id = "${var.namespace}myapp"
}

# ✗ INCORRECT - Will cause collisions
resource "google_storage_bucket" "data" {
  name = "myapp-data"
}

Rely on the appliance's own project for scoping

Each appliance gets its own Google Cloud project, so you don’t need an appliance-identifying label. Label resources only for your own cost attribution and inventory.The project boundary provides:

IAM role bindings scoped to one appliance
Cloud Logging and Monitoring isolation
Cost tracking
Resource discovery

Enable Cloud Logging for all services

Configure logging for Cloud Functions, GKE, Cloud SQL, and other services:

# GKE logging
logging_config {
  enable_components = ["SYSTEM_COMPONENTS", "WORKLOADS"]
}

# Cloud Function logging (enabled by default)
# Cloud SQL logging
settings {
  database_flags {
    name  = "log_statement"
    value = "all"
  }
}

This ensures observability data flows to your control plane.

Use AWS Secrets Manager for sensitive data

Never hardcode secrets. Use AWS Secrets Manager or SSM Parameter Store with parameterized names in your AWS origin stack:

# AWS Secrets Manager (recommended)
resource "aws_secretsmanager_secret" "api_key" {
  name = "prod/api/key"
}

# Or AWS Systems Manager Parameter Store
resource "aws_ssm_parameter" "db_password" {
  name  = "/prod/db/password"
  type  = "SecureString"
  value = var.db_password
}

Environment variables supply values at application startup. For runtime AWS Secrets Manager reads, use the configured Secrets Manager service adapter and check the operations your application needs.

Troubleshooting

Deployment fails with permission errors

Symptom: Terraform apply fails with “Permission denied” or “403 Forbidden” errors.Solutions:

Verify your control plane has successfully impersonated the Deploy service account
Check the Deploy service account’s IAM roles include necessary permissions for the resources being created
Ensure the impersonation policy allows your control plane’s service account
Verify the deploy_access label is set and the time window hasn’t expired
Review Cloud Audit Logs in the customer project to see which specific API call was denied

Resources fail to create due to naming conflicts

Symptom: “Resource already exists” or “Name is already in use” errors during deployment.Solutions:

Ensure all resource names are prefixed with ${var.namespace}
Verify the @namespace annotated variable is being passed correctly
Check that no hardcoded resource names exist in your origin stack
For Cloud Storage buckets, remember they must be globally unique - prefix them with ${var.namespace}

Observability data not flowing to control plane

Symptom: Cloud Logging and Monitoring data aren’t appearing in your observability sink.Solutions:

Verify the Steady-state service account has permissions to read logs and metrics
Check that the Steady-state service account is bound in the appliance’s project
Ensure log sinks are configured correctly
Verify resource names are parameterized and follow the expected pattern
Check that the control plane is successfully impersonating the Steady-state service account

API quota limits exceeded

Symptom: “Quota exceeded” errors when creating resources.Solutions:

Ask the customer to request quota increases from Google Cloud Console
Consider deploying appliances in separate Google Cloud regions
Ask the customer to review their current quota usage
Ask the customer to clean up unused resources in their project

Private service connection failures for Cloud SQL

Symptom: Cloud SQL instance creation fails with VPC peering errors.Solutions:

Ensure VPC has a private service connection allocated
Verify the IP address range doesn’t conflict with existing ranges
Check that servicenetworking.googleapis.com API is enabled
Ensure the Deploy service account has compute.networks.updatePolicy permission

Need help?

If you’re experiencing issues not covered here or need additional assistance with Google Cloud deployments, we’re here to help:

Slack: Join our community Slack workspace for real-time support
Email: Contact us at [email protected]

Our team can help with deployment troubleshooting, service account configuration, service equivalents, and best practices for Google Cloud environments.

Next steps

Now that you understand deploying to Google Cloud customer environments, explore these related topics:

Permissions Model: Understand the four-phase permissions model in detail
Deployments: Learn how to create releases and deploy to customer appliances
Operations: Execute remote operations on Google Cloud appliances
Observability: Set up monitoring and logging
Terraform Origin Stacks: Write Terraform origin stacks optimized for Google Cloud

​Overview

​Prerequisites

​Your control plane

​Customer Google Cloud project

​Your development environment

​How Google Cloud appliances work

​Service adapters

​How service equivalents work

​Common service equivalents

​Example: Compiling an AWS origin stack

​Permissions model

​The four permission phases

​Service account structure

​Deployment workflow with service accounts

​Networking

​Tensor9 BYOC controller VPC

​Outbound-only security model

​Application VPC topology

​Resource naming and labeling

​Parameterization pattern

​Labeling resources

​Observability

​Cloud Logging

​Cloud Monitoring

​Cloud Trace

​Cloud Audit Logs

​Artifacts

​Container images (Artifact Registry)

​Function source code

​Secrets management

​Secret naming and injection

​Operations

​kubectl on GKE

​gcloud CLI operations

​Database queries

​Operations endpoints

​Example: Complete Google Cloud appliance

​main.tf

​variables.tf

​outputs.tf

​Best practices

​Troubleshooting

​Next steps

Overview

Prerequisites

Your control plane

Customer Google Cloud project

Your development environment

How Google Cloud appliances work

Service adapters

How service equivalents work

Common service equivalents

Example: Compiling an AWS origin stack

Permissions model

The four permission phases

Service account structure

Deployment workflow with service accounts

Networking

Tensor9 BYOC controller VPC

Outbound-only security model

Application VPC topology

Resource naming and labeling

Parameterization pattern

Labeling resources

Observability

Cloud Logging

Cloud Monitoring

Cloud Trace

Cloud Audit Logs

Artifacts

Container images (Artifact Registry)

Function source code

Secrets management

Secret naming and injection

Operations

kubectl on GKE

gcloud CLI operations

Database queries

Operations endpoints

Example: Complete Google Cloud appliance

main.tf

variables.tf

outputs.tf

Best practices

Troubleshooting

Next steps