Installation

Codesealer is designed for high performance and high availability, and is comprised of the following components:

  1. A Redis instance or cluster for shared state,
  2. An InfluxDB 1.8 instance for metrics (optional),
  3. A Management Portal (core-manager),
  4. A number of Codesealer Worker processes (codesealer-core),

Codesealer Self-Hosted Installation

Codesealer Self-Hosted allows you to easily install all of these components using Docker Compose or Helm:

  • Docker Compose: The Docker Compose setup provides a simple setup that can be spun up in seconds, providing a great starting place for getting started with Codesealer.
  • Kubernetes: The entire Codesealer setup can easily be deployed to a Kubernetes cluster using Helm, either in a standalone configuration or as a sidecar to an existing Kubernetes Ingress.

To get started, create a new cluster here. Once created you will be presented with easy copy/paste instructions to install your cluster using your chosen configuration. You can go to the manage clusters to find all your clusters.

Alternatively, you can create a Codesealer Demo Cluster. These clusters contain a deployment of the OWASP Juice Shop protected by Codesealer, and allows you to quickly discover how Codesealer can protect a vulnerable application. Demo clusters can be created as Docker Compose or Kubernetes deployments.

Components

A Codesealer deployment consists of a number of components:

  • Main Components: Codesealer itself consists of two main components, Workers and the Management Portal.
  • Supporting Components: Codesealer relies on a Redis deployment to coordinate state and optionally an InfluxDB deployment to collect metrics.

These components are described in more details below.

Worker processes

The Codesealer Worker processes is the main component of Codesealer Enterprise, functioning as a reverse proxy.

Network requirements

The Codesealer Worker processes must be able access Redis for reading and writing, as well as being to able to write to InfluxDB if metrics are enabled.

A Codesealer Worker process acts as a HTTP(s) reverse proxy. It receives end user HTTP(s) requests and forwards the request to the backend. It then processes the content of these requests and responses.

Codesealer Worker processes can sit anywhere in the chain between the internet connection and final backend server. Other proxies and security products can be placed before and after Codesealer Worker processes. However, being placed behind a Load Balancer is recommended for High Availability configuration. As many Codesealer Worker processes as needed can be deployed.

Management portal

The Management Portal is needed to configure Codesealer Enterprise at runtime.

Network requirements

Administrators of Codesealer Enterprise must be able to access to the Management Portal over HTTP(s) on the configured port. The Management Portal itself must be able to access Redis.

Redis

Codesealer Enterprise relies on Redis for the following functions:

  • Session state is stored and retrieved from Redis so that any Codesealer Worker can answer client requests.
  • New Bootloader instances are stored in Redis, ready to be retrieved by the Workers.
  • Configuration is pushed by the Management Portal to the Worker processes through Redis.
  • Internal state is stored and retrieved from Redis to assist with advanced features such as Application Network Protection.

Version requirements

Redis 6.2.0 and above.

Network requirements

Redis must be accessible for reading and writing from the Codesealer Worker processes and Management portal. The port is configurable - the default non-TLS Redis port is 6379.

Security considerations

No personally identifiable information is stored in Redis, but unauthorized access to Redis could degrade Codesealer security features, e.g. by exposing TLS certificates and keys added through the Management Portal and used by Codesealer Worker processes.

Codesealer recommends enabling TLS on Redis instances, as well as using strong credentials. When enabling TLS, the redis scheme changes to rediss://.

InfluxDB

Codesealer Enterprise optionally relies on InfluxDB for metric collection. If InfluxDB is deployed and configured, these metrics will appear in the Management Portal. See the section on Metrics for more information.

Version requirements

Codesealer Enterprise supports InfluxDB versions 1.8.x.

Network requirements

The InfluxDB instance must be accessible from the following entities:

  • All Codesealer Worker nodes (codesealer-core),
  • The Codesealer Manager (core-manager),
  • Any customer-specific metric dashboards consuming metrics.

The InfluxDB port is configurable - the default non-TLS port is 8086.

Security considerations

Codesealer recommends TLS to be enabled on InfluxDB, as well as the establishment of strong credentials for authentication. Note, however, that no sensitive data is stored in InfluxDB. The data stored includes request- and error-rates at specific times.