Skip to main content

Built-in Security Guardrails

A core philosophy of the Infrastream platform is "Security by Default." Our primary goal is to provide a fundamentally secure environment so that you can focus on your primary goal: building and delivering high-quality applications.

This document outlines the security features that are automatically managed for you by the platform and clarifies your role in our shared security model.

The Shared Responsibility Model

Security is a partnership. Infrastream's responsibility is to provide a secure, compliant, and hardened platform. Your responsibility is to write secure application code and manage your application's internal logic and dependencies.

  • Infrastream Secures the Cloud: We manage the network, the identities, the encryption, the infrastructure configuration, and the deployment pipelines.
  • You Secure the Code: You manage your application's code, its dependencies (e.g., NPM, Maven, or Go libraries), and its internal business logic.

By working together, we can maintain a robust security posture from the foundational infrastructure all the way up to the end-user experience.

Key Security Features Managed for You​

You do not need to be a cloud security expert to deploy applications on Infrastream. The following critical security domains are automatically configured and enforced by the platform according to enterprise best practices.

Secure-by-Default Networking
  • Zero Trust Network: By default, no application or service can communicate with another. All traffic, both internal and external, is denied unless explicitly permitted.
  • Automated Firewall Rules: You do not need to manage firewall rules. When you declare that service-a needs to talk to service-b in a manifest, the platform creates the specific, least-privilege firewall rule required for that communication and nothing more.
  • Encrypted Traffic: All communication between your services is automatically encrypted using mutual TLS (mTLS) via the platform's built-in service mesh. You do not need to manage certificates or configure TLS.
Identity and Access Management (IAM) with Least Privilege
  • Minimal Identity Permissions: Every application you deploy is given its own unique cloud identity (a Service Account). By default, this identity has zero permissions. It cannot access any other resource.
  • Explicit, Manifest-Driven Permissions: For your application to access another resource (like a storage bucket or a database), you must explicitly declare that permission in a manifest. This declaration is then subject to a mandatory review and approval process by the security team. This prevents any application from being over-provisioned with unnecessary permissions.
Customer Authentication (IAP + Identity Platform)
  • Managed Sign-In: Any customer-facing route can be placed behind Google Identity-Aware Proxy (IAP), backed by a dedicated Google Cloud Identity Platform (GCIP) tenant — declared with an IdentityProvider manifest. This gives you social sign-in (Google, GitHub, and others), email/password and phone auth, password policy, and a hosted, brandable login page without writing any auth code.
  • Tenant-Level Policy: The same manifest controls signup rules (email-domain allow/block lists), Terms of Service acceptance tracking, and maintenance/suspension switches that block sign-in for that tenant on demand.
  • Wiring It Up: A route (HttpRoute or GrpcRoute) opts into this by setting authentication: [{type: IDENTITY_PROVIDER, tenants: [<your IdentityProvider name>]}] on its rule. IAP verifies the caller against that tenant at the edge — your application receives only the already-authenticated identity, never raw credentials. Use type: INTERNAL instead for internal/IAM-only tools rather than customer-facing routes.
  • Optional Fine-Grained Authorization: For policies more granular than "which tenant can reach this route," a PublicIngress can reference a Database via authorizationDatabase, which provisions a relation-based (Ory Keto-backed) authorization service your applications can query and manage policies against.
Encryption at Rest and In Transit
  • Automatic Encryption: All data stored in resources provisioned by Infrastream, such as databases and storage buckets, is automatically encrypted at rest using Google-managed encryption keys. All network traffic is automatically encrypted in transit. You do not need to take any action to enable this.
Secure Secret Management
  • Never Hardcode Credentials: The platform provides a secure and integrated way to manage secrets (like API keys or database passwords). You will define the need for a secret in a manifest, and the platform will securely inject it into your application's runtime environment. Your code should always read secrets from environment variables or mounted files, never from hardcoded values in your source code.
Your Role: What We Need From You

While the platform handles the infrastructure security, your role is critical. We rely on you to:

  • Write Secure Code: Follow best practices for application security to prevent common vulnerabilities like SQL injection and cross-site scripting (XSS). If you use the platform's IAP + Identity Platform integration (see above), authentication — verifying who the caller is — is handled for you; what your application does with that verified identity (authorization) is still your logic to write.
  • Manage Dependencies: Regularly scan and update your third-party libraries and dependencies to patch known vulnerabilities.
  • Use Secrets Correctly: Leverage the platform's secret management capabilities for all sensitive data.

By focusing on the security of your application's code, you complete the security picture and help us maintain a safe and reliable environment for everyone.