1-Click BYOC Cloud Setup: Google Cloud, Terraform & Zero-Trust Secrets

1. Executive Architecture Overview

Traditional secret management forces startups and enterprises into an uncomfortable trade-off: upload production database passwords and API keys into a third-party multi-tenant SaaS (Doppler, Infisical Cloud, 1Password), or take on the massive operational burden and licensing costs of HashiCorp Vault.

Sovereign Vault Bring Your Own Cloud (BYOC) resolves this trade-off:

• The Vault Stays in Your Cloud: Runs as a single static Rust container inside your private subnet (10.10.0.0/24) with no public IP address.
• The Root Key Stays in Your KMS: The master Data Encryption Key (DEK) is wrapped by your own Google Cloud KMS key (acme-vault-envelope-dek) with automated 90-day cryptographic rotation.
• Zero Vendor Access: Oakai Security has no IAM permissions, no network route, and no cryptographic keys into your VPC. Even if Oakai were legally subpoenaed or compromised, your secrets are mathematically inaccessible.
• 100% Free Tier Eligible: Engineered on e2-micro compute and a 30 GB pd-standard persistent disk. Total infrastructure spend: $0.00/month.

2. Step 1: Copy and Configure the Terraform Module

Sovereign Vault provides a turnkey, production-ready Terraform module in terraform-google-sovereign-vault.

Add the module to your infrastructure repository or create a drop-in main.tf:

module "sovereign_vault" {
  source = "github.com/oakai-security/terraform-google-sovereign-vault"

  project_id   = "your-company-prod-123"
  region       = "us-central1"
  zone         = "us-central1-a"
  vault_name   = "acme-vault"

  # 100% Free Tier Compliant
  machine_type = "e2-micro"
  disk_type    = "pd-standard"
  disk_size_gb = 30

  # Private Network Configuration (Zero Public IPs)
  subnet_cidr  = "10.10.0.0/24"
}

output "vault_internal_ip" {
  value       = module.sovereign_vault.vault_internal_ip
  description = "Private IP of Sovereign Vault node inside the VPC"
}

3. Step 2: Provision Infrastructure with Terraform

Authenticate with your Google Cloud project and apply the Terraform configuration:

# 1. Authenticate with Google Cloud
gcloud auth application-default login
gcloud config set project your-company-prod-123

# 2. Initialize and Apply
terraform init
terraform plan
terraform apply -auto-approve

What Terraform Provisions in 3 Minutes:

1. Isolated VPC & Private Subnet: Dedicated VPC with private subnet (10.10.0.0/24) and zero external IPs.
2. Cloud Router & Cloud NAT: Secure outbound-only egress for OS updates and container image pulls. Inbound internet traffic is physically impossible.
3. Cloud KMS Envelope Key: Dedicated KeyRing (acme-vault-ring) and CryptoKey (acme-vault-envelope-dek) for zero-touch auto-unseal.
4. Least-Privilege Service Account: Instance identity granted only cloudkms.cryptoKeyEncrypterDecrypter, storage object admin for encrypted backups, and Secret Manager reader.
5. Compute Instance: e2-micro VM with mlock RAM protection, automated TLS 1.3 certificate generation, and auto-restart policies.

4. Step 3: Vault Initialization & Secret Escrow

Because the instance has no public IP, connect securely via Google Cloud Identity-Aware Proxy (IAP):

# Connect via secure IAP tunnel
gcloud compute ssh acme-vault-node --zone=us-central1-a --tunnel-through-iap

On first boot, Sovereign Vault prints a single-use anti-hijack bootstrap nonce to the container logs:

# 1. Retrieve the anti-hijack nonce
NONCE=$(sudo docker logs sovereign-vault 2>&1 | grep -o 'init_[a-f0-9]*' | head -n 1)

# 2. Initialize the vault and capture cryptographic credentials
INIT_RESPONSE=$(curl -sk -X POST https://127.0.0.1:8443/v1/sys/init \
  -H "Content-Type: application/json" \
  -d "{\"bootstrap_nonce\":\"$NONCE\"}")

UNSEAL_KEY=$(echo "$INIT_RESPONSE" | jq -r .unseal_key)
ADMIN_TOKEN=$(echo "$INIT_RESPONSE" | jq -r .admin_token)

# 3. Escrow Emergency Disaster-Recovery Keys into Google Secret Manager
echo -n "$UNSEAL_KEY" | gcloud secrets create sovereign-vault-unseal-key --data-file=-
echo -n "$ADMIN_TOKEN" | gcloud secrets create sovereign-vault-admin-token --data-file=-

5. Step 4: Connecting Customer Enterprise Identity (Active Directory / OIDC)

Human operators authenticate via their corporate enterprise directory (Microsoft Active Directory, Entra ID, Okta, or Google Workspace), ensuring complete segregation from developer laptops and vendor accounts.

Customer Enterprise Personas:

• Alex Chen (CISO / Admin): [email protected]: Full read/write/admin permissions across all paths (*).
• Sarah Jenkins (Lead Developer): [email protected]: Scoped access to application secrets (apps/*).
• Marcus Vance (Compliance Auditor): [email protected]: Read-only access to HMAC audit streams and telemetry.

Enrolling the Enterprise Directory Binding:

# Enroll corporate OIDC directory into Sovereign Vault
curl -sk -X POST https://127.0.0.1:8443/v1/sys/oidc/bindings \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "enterprise-directory",
    "project": "acmecorp",
    "issuer": "https://identity.acme-corp.internal",
    "audience": "sovereign-vault-console",
    "subject_claim": "email",
    "subject_pattern": "*@acme-corp.com",
    "allowed_paths": ["*"],
    "capabilities": ["read", "write", "delete", "admin"]
  }'

6. Step 5: Creating and Querying Customer Secrets

Once authenticated, customer operators and automated workloads can create and retrieve secrets:

Writing a Production Secret:

curl -sk -X PUT https://127.0.0.1:8443/v1/secret/apps/payments/stripe_api_key \
  -H "Authorization: Bearer $ALEX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"value":"sk_live_prod_9948271049281"}'

Reading a Secret Back:

curl -sk https://127.0.0.1:8443/v1/secret/apps/payments/stripe_api_key \
  -H "Authorization: Bearer $ALEX_TOKEN"

Response:

{
  "path": "apps/payments/stripe_api_key",
  "project": "payments",
  "version": 1,
  "value": "sk_live_prod_9948271049281"
}

7. Step 6: Verifying Zero Vendor Access

To verify that Oakai Security (or any unauthorized actor) is completely blocked, test with an external or vendor token:

curl -sk -i https://127.0.0.1:8443/v1/secret/apps/payments/stripe_api_key \
  -H "Authorization: Bearer vendor-or-unauthorized-token"

Output:

HTTP/2 401 Unauthorized
{"error":"Invalid machine token or OIDC JWT format"}

Any token issued outside of the customer's verified OIDC binding returns JWT claims did not match any configured OIDC workload binding. The customer has complete, sovereign ownership of their secrets.