Skip to main content

Signadot Operator


The Signadot Operator is the in-cluster component of the Signadot Platform. To see a high-level view of all components, visit the architecture page.

The operator is installed into the Kubernetes cluster using Helm into the signadot namespace. Once authorized, it connects and maintains a persistent connection with the Signadot Control Plane.

It provides the following functionality:

  1. Creating and managing workloads (Kubernetes Deployments, Rollouts, etc) associated with a Sandbox.
  2. Creating and managing resources associated with Sandboxes.
  3. Managing routing for requests between services within the cluster.


The agent is a deployment which maintains a secure persistent connection to the Signadot Control Plane at This connection is used to:

  1. Provide access to the Kubernetes API to the Signadot Control Plane.
  2. Proxy requests from Endpoint URLs to services within the cluster, including performing in-cluster DNS resolution.

Since the agent provides access to the cluster Kubernetes API server, it tends to have scaled down read-only permissions for resources not owned by Signadot, and read-write permissions for Signadot owned objects. You can learn more about the permissions that are requested by the agent here.

Controller Manager

The controller manager implements Kubernetes controllers for various Signadot CRDs, including

  1. Sandboxes (sds)
  2. Sandbox Resources (sdre)
  3. Sandbox Resource Plugins (sdrp)
  4. Signadot Routes (sdr)

Additionally, the controller manager implements controllers for CRDs not owned by Signadot in specific cases when routing is managed by a service mesh. For example, the Signadot Operator makes use of VirtualServices for request routing if you are running Istio. The controller-manager needs read-write permissions for any resources which are manipulated on behalf of sandboxes. You can learn more about the permissions that are requested by the controller manager here.

Sandbox CRD & Controller

The sandbox CRD is a low-level implementation of the Signadot Sandbox specification. The controller for a Sandbox performs all the important actions associated with creating a Sandbox such as:

  1. Creating new workloads (and associated Kubernetes Services) according to the Sandbox specification.
  2. Coordinating the addition and removal of Signadot Routes
  3. Creating and finalizing sandbox resources

Sandbox Resource CRDs & Controller

A Sandbox Resource Plugin CRD represents a specification for allocating and deallocating resources associated with a sandbox.

A Sandbox Resource CRD represents the state of a resource associated with a sandbox. Controlling a resource entails making it available to sandboxed workloads according to the associated resource plugin spec, and deprovisioning the resource when the associated sandbox is terminating.

Signadot Route CRD & Controller

In the Sandboxes model, each request is tagged with specific headers that control the route taken by the request within the cluster. The Signadot Route CRD is a representation of these routing rules within the cluster.

When operating on a cluster with a service mesh installed, the Route Controller may in turn modify a CRD like Istio's VirtualService in order to realize the effect of the routing rule. When using Signadot Sidecars for in-cluster routing, the Route Server component is updated corresponding to the specified Route.

Route Server

The route server is a Kubernetes Deployment that is tasked with keeping track of where to route requests provided the destination address and associated sandbox. It is intended for internal Signadot use only, and serves an HTTP API for use by Signadot sidecars. For performance reasons, the route server is not intended to intervene on every request. Rather, it expects its clients to cache the results periodically.

Signadot Sidecar

The Signadot Operator also contains optional functionality to add an annotation to inject sidecars into baseline workloads. The injection occurs into pods using a Kubernetes Mutating webhook. The sidecar automatically integrates with the Route Server and provides dynamic request routing capabilities in a cluster that does not have a Service Mesh installed.