Skip to main content

Sandbox Endpoints


In order to access a Sandbox Environment manually, or from your test, Endpoints should be used. Endpoints are entities that provide an authenticated URL that points to a service accessible from your Kubernetes cluster.

Endpoints automatically set the routing-key header context on every request made through them, so they will automatically exercise the services within the sandbox as long as header propagation is implemented. They are authenticated and require a Signadot API Key or cookie-based authentication to access.

Specifying Endpoints

In the below example, the fork endpoint is specified under spec.defaultRouteGroup. Note that once created, all endpoint URLs will assume a similar form,

name: sandbox-better-route
description: sandbox env to test a new route service change
cluster: demo
- forkOf:
kind: Deployment
name: route
namespace: hotrod
- image: signadot/hotrod:cace2c797082481ac0238cc1310b7816980e3244
defaultRouteGroup: # CLI v0.3.7+ required (see sandbox specification for details)
- name: endpoint-name
target: http://my-app.example.svc:8080

Endpoints Response

Given a specification of endpoints such as above, a sandbox GET or PUT response from the Signadot API will contain a set of endpoints in json (or yaml via the cli) such as below.

- host: frontend.hotrod.svc
name: frontend-hotrod-svc
port: 8080
protocol: http
routeType: host

The URL under the field url accesses a service which may or may not have a backing forked workload. In any event, requests to this URL inject a sandbox context propagation header.

More information regarding context propagation is available here.