Skip to main content

Built-in Security Guardrails

Infrastream is secure by default: zero-trust networking, per-application identities that start with no permissions, generated firewall rules, mTLS between services, and encryption at rest and in transit. You configure none of it, and you cannot deploy a resource that opts out of it.

The Security Framework describes how each of those layers works. This page covers only the part that is yours.

The split​

  • Infrastream secures the cloud. The network, identities, encryption, infrastructure configuration and deployment pipelines.
  • You secure the code. Your application's logic and its third-party dependencies — npm, Maven, Go modules.

What we need from you​

  • Write secure code. Guard against SQL injection, XSS and the rest. If you put a route behind Identity-Aware Proxy, authentication is handled for you — but what your application does with that verified identity (authorization) is still your logic to write.
  • Manage dependencies. Scan and update third-party libraries to patch known vulnerabilities.
  • Never hardcode credentials. Declare a secret in a manifest and the platform injects it at runtime. Read it from an environment variable or a mounted file — never from source.

Wiring authentication onto a route​

The one piece of security you do declare yourself. On an HttpRoute or GrpcRoute rule:

authentication:
  - type: IDENTITY_PROVIDER
    tenants: [your-identity-provider-name]

Use type: INTERNAL instead for IAM-only internal tooling. IAP verifies the caller at the edge, so your application receives an already-authenticated identity and never handles raw credentials.

Your own access​

Your access to a project comes in three tiers — administrators, contributors and viewers — which differ only in what they may do to data. None of them can change infrastructure, read a secret payload, or grant themselves more. Access Tiers lists the exact permissions.