Skip to main content

The Infrastream Security Framework

Security in Infrastream is a property of the platform, not a configuration choice. Best practices are codified into the reusable Core Modules that every piece of infrastructure is built from, so a developer has no option to deploy an insecure resource — the guardrails are applied automatically. This removes the two most common causes of cloud breaches: configuration drift and human error.

The sections below describe each layer of that posture.

Governance through CODEOWNERS​

Infrastream uses GitOps for active governance, not just auditing. It does this by maintaining the CODEOWNERS file in the central GitOps repository.

  • Git is the audit log. Every infrastructure change is tied to a commit showing who requested it, who approved it, and when it was applied.
  • Ownership follows the manifest. When you declare administrators for a resource — an OrganizationalUnit or Project, say — the platform finds where that manifest lives and writes a matching CODEOWNERS rule. Naming team-alpha-admins as administrators of a Project produces an entry like /path/to/your-project/ @your-github-org/team-alpha-admins.
  • Reviews are then unavoidable. Any pull request touching a file in that directory requires approval from team-alpha-admins. You keep freedom over where files live, and the guardrails move with the resources.
  • Duties stay separated. A development team cannot change production network configuration, and the network team cannot change an application's resource limits, without the other's approval. Governance becomes automatic and auditable rather than ticket-driven.

IAM and least privilege​

  • Permissions are hierarchical. IAM policies inherit down the hierarchy (Organization → OU → Environment → Project). Broad policies are set at the top; more specific, additive permissions are granted below.
  • Every application gets its own identity. Each deployment is assigned a dedicated Google Service Account which starts with zero permissions and can reach nothing.
  • Access is granted explicitly. To reach a database or bucket, the permission must appear in the application's accessControl block. The platform then creates a narrow IAM binding between that service account and that resource.
  • Human access uses three tiers. People are granted through a manifest's permissions block rather than directly in IAM. The control plane is read-only in all three tiers, and no tier can set an IAM policy, impersonate a service account, or read a secret payload — see Access Tiers for exactly what each one grants.

Network security​

The network is zero-trust by default.

  • Hub and spoke. The Core Project's VPC is the hub, giving centralised control and auditing of all traffic. Each service project is a spoke, connected by VPC Peering or Private Service Connect and isolated from other spokes.
  • Firewall rules are derived, not written. The platform generates least-privilege rules covering only the traffic declared in manifests — ingress routes and accessControl blocks.
  • One service mesh across all compute. GKE, Cloud Run and Compute Engine VMs are enrolled automatically in Google Cloud Service Mesh, which provides identity-based mutual TLS for all service-to-service traffic, fine-grained traffic management, and uniform metrics and traces regardless of the underlying compute platform.
  • Egress is allowlisted. Each project has a default-deny firewall and a dedicated NAT gateway, permitting only the destinations named in the allowedEgress field.

End-user authentication​

  • Authentication happens at the edge. Customer-facing traffic can be routed through Google Identity-Aware Proxy, backed by a per-application Cloud Identity Platform (GCIP) tenant. IAP authenticates the caller at the load balancer, so the application receives an already-verified identity and never handles raw credentials.
  • Tenants are declarative. An IdentityProvider manifest configures one GCIP tenant: sign-in providers, password policy, custom claims injected into the ID token, and tenant-wide maintenance or suspension controls applied on every sign-in attempt.
  • Enforcement is per route. Each HttpRoute or GrpcRoute rule declares its own requirement — IDENTITY_PROVIDER, naming which tenants may access it, or INTERNAL for IAM-only internal tooling. One PublicIngress can therefore front customer-facing and internal-only routes under different auth models.
  • Authorization is a separate, opt-in layer. A PublicIngress may attach an authorizationDatabase, which provisions a dedicated Ory Keto-backed service that applications query for relation-based access decisions.

Application sandboxing​

Least-privilege IAM plus a zero-trust network gives every application a secure sandbox. Experimental and AI-generated code is contained by default: an application cannot reach unauthorized databases or secrets, and cannot exfiltrate data, without an explicit manifest change. Because that change is a pull request, it inherits the CODEOWNERS review above — so teams can move quickly without rogue code gaining reach.

AI agent sandboxing​

The same model covers agents. An Agent manifest's accessControl block declares exactly which databases, secrets and Pub/Sub topics the agent may reach, PR-gated like any other change. The engine separately provisions the agent's own runtime identity and enforces 3-legged consent for actions taken on behalf of a specific person. MCP tool access is governed the same way through McpConfig. See Agentic Governance for the full model.

Encryption​

  • In transit. All mesh traffic is encrypted with mTLS. Public ingress is terminated with Google-managed SSL certificates.
  • At rest. Everything the platform provisions — google_storage_bucket, google_alloydb_cluster, google_compute_disk and the rest — is encrypted at rest with Google-managed keys. Customer-Managed Encryption Keys (CMEK) are supported for resources such as Pub/Sub topics.