Technology

The ADC Portal is built on a zero-trust security model and uses full end-to-end encryption. This approach ensures that all data within the Portal is always encrypted (both at rest and in transit) using a unique pair of organisation and account private keys. This means that no one can ever see or read your data, and that all data encryption and decryption occurs within your own environment.

Communication

All communication takes place via a secure WebSocket protocol (WSS) with mTLS. With mTLS, the client is required to present its certificate to the server (and visa versa). Hence mutual certificate authentication occurs. This double layer of authentication provides an additional layer of protection against impersonation attacks. And it is only once this two-way authentication has taken place that a secure connection is established, leading to the exchange of data.

bi directional comms

Within this encrypted WSS channel, there are two methods of communication:

Event-driven requests

Explicitly defined requests are sent as events to the Shuttle for added security and efficiency.

Remote HTTP proxy

This is a WARP-enabled, remote HTTP proxy to your network. It allows you to see the WebUI of each appliance and provides a facility to manage it over an encrypted connection across the Loadbalancer.org ADC Portal network.

WARP

WARP is a proxy that helps you connect to the internet while simultaneously optimizing and securing (i.e. encrypting) your connection, giving you access to you appliance, no matter where you are.

PGP Encryption for Extra Security

In addition to the secure WebSocket encryption outlined above, the Portal also contains a second layer of security: PGP encryption.

pgp encryption chain

Once the initial mTLS handshake has been completed, the Shuttle then creates its own PGP keys, which are then used for communication and verification with the ADCs. However, before data can be transferred from the client to the Shuttle, it must first pass through an intermediary key. This Certificate Chain enables the receiver to verify that the sender and all Certificate Authorities are trustworthy.

Every user needs not only their own private key, but also a copy of the organisation key to read the data that’s coming in from the Shuttle. This means new users will need to be invited by the organisation to register, and actively given a copy of the organisation key (as well as activating their own private user key). In this way it is the organisation who is the owner of everything - not the user.

And with the potential for multiple levels of encryption using different keys, it would be almost impossible to decrypt what is imprinted on the public key without also being in possession of a private key. In this way, if someone were to compromise or intercept the messages being transmitted by the Shuttle, break the TLS encryption and obtain the encrypted PGP data, they would still need the Shuttle’s private key to be able to read it.

In this way, data communications are sent via the Shuttle which acts as an intermediary or sidecar agent. but the Shuttle is unable to read these messages. Its only role is to act as a vector to forward this information when, and only when, the private and public keys match.

ADC Communication Services & Methods

As discussed above, the Shuttle is a key component in ADC portal communication. In addition, the gateway service is used on Loadbalancer.org appliance and API calls are used with 3rd party appliances.

Shuttle Service

A Shuttle can be provisioned as a standalone Linux instance running the Shuttle service or as a Loadbalancer.org ADC appliance with its Shuttle service enabled.

Gateway Service

The gateway service applies to Loadbalancer.org ADC appliances only. When enabled, it’s used to gather Loadbalancer.org appliance details and pass them to a Shuttle. It also enables appliance backups and other remote tasks to be run.

Vendor Specific API Calls

Used to gather details for ADC appliances from 3rd party vendors and pass them to a Shuttle. API calls are also used to control ADC appliance backups and other remote tasks.

Connection Options

There are a number of ways that the connection to the ADC Portal can be provided. The sections below describe each option.

Single Shared Connection with Single Dedicated Shuttle

All Portal communication is handled by a dedicated Shuttle separate from all load balancing workload.

concept dedicated shuttle

  • Requires a single shared connection to the ADC Portal.

  • Requires a single Shuttle, this can be either:

  • All appliances communicate with the ADC Portal via the standalone Shuttle/dedicated loadbalancer.org ADC.

    If the Shuttle is to be used to monitor & control ADCs in remote subnets, those subnets must be configured on the Shuttle (subnets can be configured for the standalone Shuttle only). For more information, please refer to Network Topology. Alternatively, an additional Shuttle can be added to each remote subnet to serve those ADCs.

  • The Gateway service on each Loadbalancer.org appliance must be enabled.

  • The API must be enabled on all non Loadbalancer.org appliances.

Single Shared Connection with Single Non-Dedicated Shuttle

All Portal communication is handled by a designated Loadbalaner.org appliance in addition to its own load balancing workload.

concept single shuttle

  • Requires a single shared connection to the ADC Portal.

  • Requires a single Shuttle - the Shuttle service on a Loadbalancer.org ADC must be enabled.

  • All appliances communicate with the ADC Portal via the Shuttle service on the chosen ADC.

    The Shuttle should be deployed in a subnet that has access to all ADCs to be monitored & managed. If this is not possible, an additional Shuttle can be added to each remote subnet to serve those ADCs. Alternatively, a standalone Shuttle with all remote subnets configured can be used as described in Single Shared Connection with Single Dedicated Shuttle.

  • The gateway service on each Loadbalancer.org appliance must be enabled.

  • The API must be enabled on all non Loadbalancer.org appliances.

Multiple Connections and Multiple Non-dedicated Shuttles (Loadbalancer.org ADCs Only)

Each Loadbalancer.org appliance handles its own Portal communication in addition to its own load balancing workload.

concept multi shuttle

  • Each appliance has its own connection to the Portal.

  • The gateway and Shuttle services on each Loadbalancer.org appliance must be enabled.