Security Architecture Overview

Overview

This document provides an overview of the platform's security architecture and principles. Security is a core design constraint of the product, which is built to operate entirely within an API publisher's own infrastructure.

The platform's security model is designed to solve several key problems for enterprise operators: ensuring data residency, preventing public network exposure, enforcing granular access control, protecting secrets, and maintaining a complete audit trail of all changes.

The control plane, runtime workers, and metadata database are all deployed inside your network. This ensures that all API traffic, including request and response payloads, remains within your VPC. The platform exposes no public endpoints by default and relies on an identity-aware proxy for operator access. All configuration changes are logged for accountability, and backend credentials are encrypted at rest.

This document is intended for security reviewers, platform teams, and operators who are evaluating or running the platform.

How it works

The platform's security is founded on a set of core principles that govern its architecture and operation.

Data Residency and Network Isolation

The entire platform runs within your own network infrastructure (VPC). This guarantees that your data, including SOAP traffic, request/response payloads, and the metadata database, never leaves your network boundaries. The platform components, such as the control plane and runtime, are designed for internal-only ingress by default, meaning they do not have public IP addresses or URLs. Access is mediated through your internal load balancer.

The only outbound communication from the platform is a minimal, metadata-only signal to the Specaria platform for licensing and product updates. This signal does not contain any payloads, hostnames, or API consumer identifiers.

The following diagram illustrates the network boundaries and data flow:

flowchart TD
    subgraph "Customer VPC / Network"
        direction LR
        subgraph "SOAP-2-REST Platform"
            direction TB
            A[Control Plane]
            B[Runtime & Workers]
            C[Metadata Database]
        end
        D(Internal SOAP Backend)
        E(API Consumer)

        E -- "REST Request" --> B
        B -- "SOAP Request" --> D
        D -- "SOAP Response" --> B
        B -- "REST Response" --> E
        A <--> C
        B <--> C
    end

    subgraph "Specaria Platform"
        F[Licensing & Updates]
    end

    A -- "Metadata-only Telemetry (HTTPS)" --> F

On Google Cloud, the platform can also use IAM database authentication for its database connections.

Access Control and Authentication

Operator access to the control plane is managed through an identity-aware proxy (IAP), which injects an authenticated user identity into requests. At GA, supported identity providers include Google IAP, Azure AD, and standard SAML/OIDC.

Once a user is authenticated, their permissions are determined by role-based access control (RBAC). Every control-plane endpoint enforces permissions based on three distinct roles:

• admin: Full control over the platform configuration.
• operator: Can manage services and configurations.
• reader: Read-only access to view configurations.

Role assignments can be resolved from an organization's identity provider (IdP) groups, direct in-app principal bindings, or an emergency bootstrap list. This multi-faceted approach ensures that administrators are never locked out and are not solely dependent on a single external system for access.

Backend Credential Encryption

Credentials for connecting to backend SOAP services are always stored encrypted at rest in the platform's database using pgcrypto. Supported credential types include:

• Basic authentication
• Bearer tokens
• API key headers
• OAuth2 client credentials
• Mutual TLS (mTLS) client material

Plaintext credential values are never written to logs or returned in API responses. The API only exposes metadata about a credential, such as whether it is set and when it was last updated.

Audit and Telemetry

Every configuration change made through the control plane is recorded as an audit event. Each event includes the actor, their role, the action performed, and the before-and-after state of the configuration, linked by a correlation ID. Audit logs are retained for 60 days by default and are queryable from the UI.

Outbound communication for licensing and updates is strictly limited to metadata. The platform sends only numeric counts, component versions, a hashed host fingerprint, an installation ID, a customer label, and a contact email over HTTPS. It never sends payloads, hostnames, consumer identifiers, or other personally identifiable information (PII).

Security Features Summary

The following table summarizes the platform's approach to key security concerns.

See Also

For more detailed information on specific security topics, refer to the following documents:

• Network & data residency
• RBAC & roles
• Authentication
• Backend credential encryption
• Audit trail
• Data retention
• Licensing
• Licensing egress allow-list

All SOAP-to-REST docs