Skip to main content

Introduction

Overview​

ColorTokens offers on-premises deployment of the Xshield Security Platform for customers looking to host the software in-house with no data stored in the cloud for compliance, security and various other factors.

This offers a fully air gapped environment that does not require any internet connectivity to perform its operations. The customer must provide the networking for the Xshield agents to be able to communicate to the in-house Xshield platform.

Architecture​

The following diagram provides a high level overview of Xshield platform architecture with focus on the on-premise deployment.

Xshield Platform - Architecture

The Xshield Security Platform is a modern, zero-trust micro-segmentation solution designed to secure hybrid enterprise environments. In an on-premise deployment, the platform is hosted within a customer-managed data center as a Kubernetes-based microservices architecture. This document outlines the core infrastructure components and data flows involved in a typical on-premise deployment.

Colortokens agent to On-Prem Communication​

Similar to the Saas Agent, the Colortokens agent for on-premises deployment is a low-impact software that can be installed on servers and endpoints running modern operating systems. The agent is responsible for sending telemetry data to the on-premises platform and receiving policy updates from the on-premises platform.

Agent to On-Prem Platform Communication

1. Core Deployment Architecture​

At the heart of the deployment is a Kubernetes Cluster, which hosts the Xshield platform components. This cluster runs within a customer’s on-premise data center (DC) and integrates with internal infrastructure, endpoints, and users. The architecture also includes dedicated zones for persistent data and image storage, ensuring high availability and operational continuity.

2. Technical Components​

a. Users and Endpoints​

  • Users (e.g., security analysts, administrators) and endpoints (e.g., servers, workstations, IoT devices) access the platform through services exposed via a Kubernetes ingress.
  • MetalLB is used to provide external IPs for services, enabling user and agent access from outside the cluster.

b. Kubernetes Cluster​

  • The Kubernetes Control Plane orchestrates the containerized workloads, ensuring services are scheduled, monitored, and scaled based on resource demands.
  • High availability and resiliency are achieved through Kubernetes-native mechanisms like replica sets and pod affinity rules.

c. Ingress and Load Balancing​

  • The ingress layer, paired with MetalLB, enables secure traffic routing into the Kubernetes environment.
  • This setup ensures that traffic from endpoints and users is balanced and directed to the appropriate services within the cluster.

d. Observability Stack​

  • An integrated observability stack provides system-level metrics, logs, and traces.
  • It supports platform monitoring, troubleshooting, and alerting, helping ensure platform uptime and performance visibility.

e. Redis Cache​

  • A distributed in-memory cache is deployed to support high-speed access to transient data.
  • It is typically used for short-lived state, session management, and platform performance optimization.

f. Ceph Object Storage​

  • Ceph provides scalable and durable storage for platform artifacts such as telemetry data, logs, and event records.
  • It supports integration with external analytics or backup workflows where long-term retention is necessary.

3. Database Layer​

The platform utilizes a PostgreSQL-based DB Cluster configured in a high-availability topology:

  • Master Node: Accepts all write and transactional operations.
  • Replica Node: Maintains up-to-date read-only copies for redundancy and read scaling.
  • HAProxy: Balances database traffic and ensures failover routing between master and replica nodes.

4. Image Registry and CI/CD Integration​

  • A Docker Registry hosted on a dedicated VM serves as the source for container images used within the Kubernetes cluster.
  • Semaphore, or a similar CI/CD tool, is integrated to automate image builds, testing, and deployment workflows, enabling consistent and secure updates to the platform.

5. Networking Overview​

  • Networking is handled through MetalLB and Kubernetes Ingress Controllers, allowing external communication while maintaining internal segmentation.
  • All communication is secured and policy-controlled, aligning with enterprise security standards.

Postgres Database - HA Architecture​

If customer has a requirement for database redundancy, then the Postgresql database can be deployed in a high availability (HA) configuration as shown below:

Xshield Postgres Database - HA Architecture

Supported Platforms​

We support deploying on-premises Xshield software on the below platforms. We are able to leverage managed service offerings from respective cloud providers for kubernetes, Postgres Database, Blob Storage to deploy the Xshield software

Public Clouds​

The Xshield Security Platform can be configured both as a SaaS as well as a standalone (single tenant) cluster on public clouds. It is offered as a multi-tenant SaaS platform across multiple regions by ColorTokens. Customers can also host it as a standalone cluster in their own accounts on public clouds. The Xshield Security Platform has been qualified for the following public clouds:

  • Azure Cloud
  • Amazon (AWS)
  • Google (GCP)
  • Oracle (OCI)

Private Data Center​

Additionally, the Xshield Security Platform has been qualified on the following private data center management systems:

  • VMWare
  • Nutanix
  • Openshift

Summary​

The on-premise deployment of the Xshield Security Platform offers a robust, self-managed security solution that integrates directly into enterprise infrastructure. By leveraging a Kubernetes-native microservices approach, along with HA database design, object storage, observability, and CI/CD integration, the deployment ensures agility, security, and operational continuity in customer-controlled environments.