Skip to main content

Signadot Control Plane

Overview

The Signadot Control Plane is one of the components of the Signadot Platform. To see a high-level view of all components, visit the architecture page.

The Signadot Control Plane maintains a secure tunnel connection with each Kubernetes cluster that has the Signadot Operator installed. It exposes the following two important pieces of functionality:

  1. REST API to create and manage Sandbox Environments within connected Kubernetes clusters.
  2. Sandbox Endpoints used to access Sandbox Environments.

REST API

The control plane provides a REST API hosted at api.signadot.com which is used to interact with all entities associated with the Signadot platform. All operations related to creating or managing sandboxes are performed via this API.

Higher-level abstractions such as the Signadot CLI and SDKs that are layered on top of the REST API. As an end user, it is likely that you will use one of these higher-level interfaces to create and manage Sandboxes.

In addition to these interfaces, there is also the Signadot Dashboard (app.signadot.com) that is available for administrative purposes, such as for managing users, clusters, analytics & reporting, billing etc.

Sandbox Endpoints

Sandbox Environments are accessed via Sandbox Endpoints. These endpoints are made available to you when you create the sandbox and typically take the form:

https://your-endpoint--your-sandbox-name.preview.signadot.com

The Signadot Control Plane hosts these endpoint URLs and provides authenticated access to them. When you access a sandbox endpoint, the following occurs under the hood:

  1. The Signadot Auth cookie, or Signadot API Key is validated.
  2. Signadot Authorization information is stripped from the request.
  3. The host, port and protocol of the service within the Kubernetes cluster corresponding to the endpoint is looked up.
  4. If the request is intended for a sandboxed workload, Headers containing the Sandbox Routing Key are injected into the request.
  5. Standard proxy headers such as Forwarded are added to the request.
  6. A connection is established to the destination Kubernetes service over the secure tunnel via the agent in the operator.
  7. The request is forwarded over this connection to the destination.