Architecture

Hardpoint Enterprise is a system consisting of several components with varied responsibilities. This page details the Hardpoint Enterprise system architecture. It's aimed at users and developers looking to familiarise themselves with key system concepts to improve understanding for integration and operations.

Hardpoint provides customers with full physical data isolation, while leveraging the operational efficiency, reliability and benefits that existing investments in containerisation. The solution leverages automated orchestration, cryptographic network isolation, and zero-trust principles to achieve true tenant separation without the overhead of managing fully duplicated compute infrastructure.

Zero-trust This approach provides security additional security to traditional cloud native VPC-based network isolation, which relies heavily on perimeter security and ingress/egress policies based on static infrastructure topologies. This making the assumption that internal traffic is universally trustworthy and safe to mix.

Background

Hardpoint's approach

Many SaaS products can be characterised as having n-tier architectures which can have arbitrary numbers of layers depending on the complexity of the system. However from the perspective of a technical decision-maker faced with the challenge of honoring a complex data placement requirement, these tiers can be summarised into two salient subsystems: the layer holding the data, and the layer processing the data:

Data Layer:

TODO- short overview

Compute Layer:

TODO- short overview

Further detail

Data layer

Tenant databases are deployed to physically isolated infrastructure. No underlying infrastructure is shared with other tenants or with the compute layer. Concretely, in AWS this means a separation of:

• AWS accounts

• VPCs and all associated network components: CIDR blocks, routing tables, subnets, network interfaces, NAT gateways and IP addresses

• Database instances resident in tenant VPCs

Database disk volumes are encrypted using dedicated 256-bit AES keys in Galois counter mode, stored in isolated hardware security modules (HSM). An automated orchestration platform handles provisioning, configuration management, monitoring, backup scheduling, and day-2 operations across this fleet of isolated database instances.

Compute layer

A zero-trust overlay network based on modern WireGuard cryptography connects isolated database instances to dedicated compute nodes inside our Kubernetes compute infrastructure. In addition to ensuring safe connection between these nodes and dedicated databases, the overlay network prevents the mixing of traffic between pooled and isolated tenants. Each database connection is authenticated via public-key cryptography and encrypted end-to-end, with no implicit trust based on network location. Once a point-to-point connection is established, authentication to the database itself is granted on a limited-time basis using dynamic credentials, through the native OIDC mechanism built into the cluster which allows identification of individual compute nodes. Access is audited and revocable at any time.

An API gateway at the system edge integrates with a tenant discovery service to route incoming requests. The gateway identifies the tenant from request metadata (domain, API key, JWT claims), queries the discovery service to resolve the tenant's database endpoint, and forwards traffic through the secure overlay network to the appropriate isolated instance.