Skip to content

Architecture & Security

SchemaDock is designed as a narrow connectivity component between SchemAlign and authorized private-network destinations.

Its security model combines encrypted transport, authenticated agent identity, organization authorization, destination policy, and fail-closed routing.

Connectivity boundary

The architectural boundary is intentional:

SchemAlign
    -> executes pipelines and connectors
    -> resolves credentials and runtime values
    -> manages artifacts, retries, jobs, and RBAC

SchemaDock
    -> maintains an authenticated gateway connection
    -> enforces destination authorization
    -> opens authorized TCP streams
    -> relays bytes between SchemAlign and the private destination

SchemaDock does not become a remote SchemAlign worker.

Encrypted SchemaDock channel

The customer-side SchemaDock agent establishes an outbound TLS-protected connection to the SchemAlign SchemaDock gateway over TCP port 443.

This provides encryption in transit for the SchemaDock cloud-to-customer channel and avoids requiring a normal inbound Internet-facing listener on the customer network.

Native protocol security is preserved

SchemaDock transports TCP streams rather than replacing the application protocol.

For protocols that already provide their own encryption, that native protection continues through the tunnel:

Protocol Native security behavior through SchemaDock
HTTPS Destination TLS, hostname validation, SNI, and certificate verification remain part of the originating HTTPS connection.
LDAPS The originating LDAPS/TLS session is carried through SchemaDock to the directory service.
SFTP The SSH/SFTP session remains the application protocol used to authenticate and transfer data.

Conceptually, encrypted application protocols have two transport protection layers while crossing the SchemAlign-to-customer boundary:

Application protocol encryption
    HTTPS / LDAPS / SFTP
            inside
SchemaDock encrypted transport

For a plaintext private protocol such as http://, the SchemaDock channel is still encrypted between SchemAlign and the SchemaDock agent, but the final private-network hop uses the plaintext protocol that was explicitly configured.

SchemaDock does not upgrade application protocols

SchemaDock does not silently change HTTP to HTTPS or otherwise rewrite the selected destination protocol. Use encrypted destination protocols when end-to-end application-layer encryption is required.

Enrollment and identity

New SchemaDock registrations use a one-time bootstrap for enrollment.

The bootstrap identifies:

  • the SchemAlign SchemaDock gateway
  • the SchemaDock registration
  • a one-time enrollment token

After enrollment, SchemaDock stores its persistent identity locally and reconnects using that identity. Normal update or reinstall operations preserve the existing identity.

Do not reuse a bootstrap from an already enrolled Dock on a different host.

Authorization layers

Before a selected Dock can be used, SchemAlign validates the runtime context, including:

  • the Dock exists
  • the Dock is enabled
  • the Dock is enrolled
  • the Dock is authorized for the pipeline organization
  • the Dock is usable and online
  • the requested destination is authorized

A selected Dock that fails validation causes the node to fail.

SchemaDock unavailable
    -> node fails
    -> no silent Direct fallback

Destination-policy defense in depth

Restricted destination policy is deny-by-default.

The effective model is:

SchemAlign destination policy allows
        AND
SchemaDock agent policy allows
        =
private destination connection permitted

A matching Deny rule wins over an Allow rule.

See Destination Policy for the complete rule model.

Organization boundaries

A Dock has explicit ownership and availability.

Ownership may be:

  • a specific organization
  • Global

Availability may be limited to:

  • the owner organization
  • selected organizations
  • all organizations

Organization availability does not replace user RBAC. Runtime authorization remains authoritative.

Fail-closed behavior

SchemaDock is designed to fail closed when security or availability requirements are not satisfied.

Examples include:

  • selected Dock is offline
  • Dock is disabled
  • Dock is not enrolled
  • pipeline organization is not authorized
  • destination is denied by policy
  • agent policy information is missing or invalid

The node fails instead of attempting an alternate Direct route.

Security design principles

SchemaDock is designed around commonly accepted secure-connectivity principles:

  • TLS encryption in transit
  • outbound-initiated agent connectivity
  • authenticated persistent agent identity
  • one-time enrollment bootstrap
  • least-privilege organization availability
  • deny-by-default destination authorization
  • defense-in-depth policy enforcement
  • fail-closed routing behavior
  • preservation of native HTTPS, LDAPS, and SFTP security
  • minimal customer-side execution surface