Release 0.19.8

What's New

• Transwarp beta_1
• Converged Tunneler/Router (Beta)
  • Updates to the host.v1 config type
  • New host.v2 config type
  • New health events

Fixes

• Service Policies with no Posture Checks properly grant access even if an identity has another Service Policies with posture checks
• Removing entities with no referencing entities via attributes no longer panics
• API Sessions and Current Api Session now share the same modeling logic
• API Sessions now have lastActivityAt and cachedLastActivityAt
• Enrolling and unenrolling in MFA sets MFA posture data

Transwarp beta_1

See the Transwarp beta_1 guide here.

Converged Tunneler/Router (Beta)

ziti-router can now run with the tunneler embedded. It has the same capabilities as ziti-tunnel. As ziti-tunnel gains new features, the combined ziti-router/tunnel should maintain feature parity.

Beta Status

This is a beta release. It should be relatively feature complete and bug-free for hosting services but intercept support is still nascent. Some features are likely to be changed based on user feedback.

Os Compatibilty

Like ziti-tunnel, tproxy mode will only work on linux. proxy and host modes should work on all operating systems.

The converged tunneler/router does not support running in tun mode. This mode may be deprecated for ziti-tunnel as well at some point in the future if no advantages over tproxy mode are evident.

Supported configurations

The following configurations are supported:

• ziti-tunneler-client.v1
• ziti-tunneler-server.v1
• host.v1 (updated)
• host.v2 (new)

Support for intercept.v1 will be added in a follow-up release.

Router Identities

When an edge router is marked as being tunneler enabled, a matching identity will be created, of type Router, as well as an edge router policy. The edge router policy ensures that the identity always
has access to the edge router. The identity allows the router to be included in service policies, to configure which services will intercepted/hosted.

1. The identity will have the same id and name as the edge router
2. If an identity with the same name as the router already exists, the router create/update will fail
3. When the router name is changed, the identity name will be updated as well.
4. The identity name and type cannot be changed directly. The type may not be changed at all and the name may only be changed by changing the name of the router.
5. The identity may not be deleted except by deleting the router or disabling tunneler support for the identity.
6. When the router is deleted, the accompanying identity and edge router policy will also be deleted
7. If tunneler support is disabled in the router, the accompanying identity and edge router policy will also be deleted.
8. The edge router policy will have the same id as the router and have a name of the form edge-router-<edge-router-id>-system, where <edge-router-id> is replaced by the id of the edge router.
9. The edge router policy is considered a system entity, and cannot be updated and cannot deleted except by the system when the associated router is deleted.

Tunneler Prerequisites

In order for a router instance to host a tunneler, it must meet the following criteria:

1. It must be represented in the model by an edge router
2. The edge router field isTunnelerEnabled must be set to true
3. Edge functionality in the router must be enabled, which means the edge: config section must be present. NOTE: The edge listener does not need to be enabled.
4. The tunnel listener must be enabled.

Making an Edge Router Tunneler enabled

The ziti CLI can be used to enable/disable tunneler support on edge routers. When creating an edge router, the -t flag can be passed in to enable running the tunneler.

ziti edge create edge-router myEdgeRouter --tunneler-enabled

or

ziti edge create edge-router myEdgeRouter -t

An existing edge router can be marked as tunneler enabled as follows:

ziti edge update edge-router myEdgeRouter --tunneler-enabled

or

ziti edge update edge-router myEdgeRouter -t

An existing edge router can be marked as not supporting the tunneler as follows:

ziti edge update edge-router myEdgeRouter -t=false

or

ziti edge update edge-router myEdgeRouter --tunneler-enabled=false

Tunnel listener configuration

listeners:
  - binding: tunnel
    options:
      mode: tproxy # mode to run in. Valid values [tproxy, host, proxy]. Default: tproxy
      svcPollRate: 15s # How often to poll for service changes. Default: 15s
      resolver: udp://127.0.0.1:53 # DNS resolve. Default: udp://127.0.0.1:53 for tproxy, blank for others
      dnsSvcIpRange: 100.64.0.1/10 # cidr to use when assigning IPs to unresolvable intercept hostnames (default "100.64.0.1/10")
      services: # services to intercept in proxy mode. Default: none
        - echo:1977
      lanIf: tun1 # if specified, INPUT rules for intercepted service addresses are assigned to this interface. Defaults to unspecified.

Updates to health checks/health check events

Health checks now have a new trigger option change. This will trigger the action whenever the health state changes from pass to fail or fail to pass.

There's now a new action, send event, which will send a health event to the controller. This will be reported via the recently introduced service events.

The change option is designed to be sued with send event as a way to send events only when the state changes, rather than sending every single pass/fail.

An example configuration:

{
  "address": "localhost",
  "port": 8171,
  "protocol": "tcp",
  "portChecks": [
    {
      "address": "localhost:8171",
      "interval": "5s",
      "timeout": "100ms",
      "actions": [
        {
          "trigger": "change",
          "action": "send event"
        }
      ]
    }
  ]
}

What the service events look like:

{
  "namespace": "service.events",
  "event_type": "service.health_check.failed",
  "service_id": "vH3QndzRYt",
  "count": 2,
  "interval_start_utc": 1616703360,
  "interval_length": 60
}
{
  "namespace": "service.events",
  "event_type": "service.health_check.failed",
  "service_id": "vH3QndzRYt",
  "count": 1,
  "interval_start_utc": 1616703720,
  "interval_length": 60
}
{
  "namespace": "service.events",
  "event_type": "service.health_check.passed",
  "service_id": "vH3QndzRYt",
  "count": 2,
  "interval_start_utc": 1616703720,
  "interval_length": 60
}

Changes to host.v1

The host.v1 config type now support health checks. The configuration is the same for ziti-tunneler-server-v1.

See here: https://github.com/openziti/edge/blob/v0.19.54/tunnel/entities/host.v1.json for the full schema

host.v2

There is a new host configuration, host.v2, which should supercede host.v1. The primary difference from host.v1 is that it supports multiple terminators. This means that when a service is hosted by a router, it can connect to multiple service instances if the service is horizontally scaled, or in a primary/failover setup.

Each terminator definition is the same as a host.v1 configuration, which one exception: listOptions.connectTimeoutSeconds is now listenOptions.connectTimeout and is specified as a duration (5s, 2500ms, etc).

Example:

{
  "terminators": [
    {
      "address": "localhost",
      "port": 8171,
      "protocol": "tcp",
      "listenOptions": {
        "cost": 50,
        "precedence": "required"
      },
      "portChecks": [
        {
          "address": "localhost:8171",
          "interval": "5s",
          "timeout": "100ms",
          "actions": [
            {
              "trigger": "change",
              "action": "send event"
            },
            {
              "trigger": "fail",
              "action": "increase cost 25"
            },
            {
              "trigger": "pass",
              "action": "decrease cost 10"
            }
          ]
        }
      ]
    },
    {
      "address": "localhost",
      "port": 8172,
      "protocol": "tcp",
      "listenOptions": {
        "cost": 51,
        "precedence": "required"
      },
      "portChecks": [
        {
          "address": "localhost:8172",
          "interval": "5s",
          "timeout": "100ms",
          "actions": [
            {
              "trigger": "change",
              "action": "send event"
            },
            {
              "trigger": "fail",
              "action": "increase cost 25"
            },
            {
              "trigger": "pass",
              "action": "decrease cost 10"
            }
          ]
        }
      ]
    }
  ]
}