Skip to content

Latest commit

 

History

History
1109 lines (854 loc) · 55.4 KB

CHANGELOG.md

File metadata and controls

1109 lines (854 loc) · 55.4 KB
Raw

Release 0.32.0

What's New

  • Auth Rate Limiter

Backwards compatibility

This release includes new response types from the REST authentication APIS. They are now able to return 429 (server too busy) responses to auth requests. As this is an API change, the version number is being bumped to 0.32.

Auth Rate Limiter

In order to prevent clients from overwhelming the server with auth requests, an auth rate limiter has been introduced. The rate limiter is adaptive, in that it will react to auth attempts timing out by shrinking the number of allowed queued auth attempts. The number will slowly recover over time.

Example configuration:

edge:
  # This section allows configurating the rate limiter for auth attempts
  authRateLimiter:
    # if disabled, no auth rate limiting with be enforced
    enabled: true
    # the smallest window size for auth attempts
    minSize: 5
    # the largest allowed window size for auth attempts
    maxSize: 250

New metrics:

  • auth.limiter.queued_count - current number of queued auth attempts
  • auth.limiter.window_size - current size at which new auth attempts will be rejected
  • auth.limiter.work_timer - tracks the rate at which api sessions are being created and how long it's taking to create them

Component Updates and Bug Fixes

Release 0.31.4

What's New

  • Bug fix for a data flow stall which is especially likely to happen on circuits with single router paths

Thanks

  • @marvkis - for providing high quality debug data which made tracking down a couple of flow control stall issues much easier

Component Updates and Bug Fixes

Release 0.31.3

What's New

  • Services Max Idle Time
  • Add/Remove Peer and Transfer Leadership via REST

Service Max Idle Time

A max idle time can now be configured on services. The default value of 0 indicates that no maximum will be enforced. A circuit is considered idle when no traffic is flowing across through the initiating or terminating router.

ziti edge create service test-service --max-idle-time 5m

Note that the idle time calculation is done on the router, so if max idle time on a service is less than the configured scan interval on the router, it make take longer than expected for idle circuits to be removed.

Raft Cluster Management via REST

The controller now allows some Raft cluster management operations to be performed via REST.

NOTE: If your cluster is not bootstrapped yet, the REST API won't be available. These will only work on a bootstrapped cluster!

The following operations are now supported:

  • Add member
  • Remove member
  • Transfer leadership
ziti fabric raft add-member tls:localhost:6363
ziti fabric raft add-member tls:localhost:6464
ziti fabric raft transfer-leadership 
ziti fabric raft transfer-leadership ctrl3
ziti fabric raft remove-member ctrl2
ziti fabric raft remove-member ctrl3

Component Updates and Bug Fixes

Release 0.31.2

What's New

  • Go version updated from 1.20 to 1.21

Release 0.31.1

What's New

  • SDK Hosting Improvements
  • Terminator validation utility
  • Circuit/Link query support

SDK Hosting Improvements

In previous versions of OpenZiti, if many SDK clients were attempting to establish hosting, the controller could get overwhelmed. In this release, routers will use the rate limiter pool introduced in 0.27.6 when creating terminators on behalf of sdk clients hosting applications. Additionally, routers now have the ability to verify terminator state with the sdk, if the sdk supports it. In general, hosting large numbers of services using the sdk should now be less suceptible to thundering herd issues.

Manual Terminator Validation

There is a new CLI command available to validate terminator state. This is primarily a developer tool to validate that terminator setup logic is correct. However it may also be used to diagnose and resolve issues with production systems, should the need arise.

ziti fabric validate terminators

Circuit/Link Query Support

Previously listing circuit and links always showed the full list. This is because these types are in memory only and are not stored in the bbolt datastore. There's now basic support for querying in-memory types and circuits and links can now be filtered/paged/sorted the same as other entity types.

Component Updates and Bug Fixes

Release 0.31.0

What's New

  • Rate limited for model changes

Rate Limiter for Model Changes

To prevent the controller from being overwhelmed by a flood of changes, a rate limiter can be enabled in the configuration file. A maximum number of queued changes can also be configured. The rate limited is disabled by default for now. If not specified the default number of queued changes is 100.

When the rate limit is hit, an error will be returned. If the request came in from the REST API, the response will use HTTP status code 429 (too many requests).

The OpenAPI specs have been updated, so if you're using a generated client to make REST calls, it's recommended that you regenerate your client.

commandRateLimiter:
    enabled:   true
    maxQueued: 100

If the rate limiter is enabled, the following metrics will be produced:

  • command.limiter.queued_count - gauge of the current number of queued operations
  • command.limiter.work_timer - timer for operations. Includes the following:
    • A histogram of how long operations take to complete
    • A meter showing that rate at which operations are executed
    • A count of how many operations have been executed

Component Updates and Bug Fixes

Release 0.30.5

What's New

  • Initial proxy support in host.v1/host.v2

Proxy Support in host.v1/host.v2

host.v1 and host.v2 configurations may now specify a proxy to use. Currently only HTTP Connect proxies which don't require authentication are supported.

Example using host.v1

{
    "address": "192.168.2.50",
    "port": 1234,
    "protocol": "tcp",
    "proxy": {
        "address": "192.168.1.110:3128",
        "type": "http"
    }
}

Component Updates and Bug Fixes

Release 0.30.4

What's New

  • ziti edge quickstart](openziti#1298). You can now download the ziti CLI and have a functioning network with just one command. The network it creates is ephemeral and is intended to be torn down when the process exits. It is intended for quick evaluation and testing of an overlay network. It supports the following flags:

        --already-initialized     Specifies the PKI does not need to be created and the db does not need to be initialized. Recommended to be combined with --home. If --home is not specified the environment will be destroyed on shutdown! default: false
    --ctrl-address string     Sets the advertised address for the control plane and API
    --ctrl-port int16         Sets the port to use for the control plane and API
-h, --help                    help for quickstart
    --home string             Sets the directory the environment should be installed into. Defaults to a temporary directory. If specified, the environment will not be removed on exit.
-p, --password string         Password to use for authenticating to the Ziti Edge Controller. default: admin
    --router-address string   Sets the advertised address for the integrated router
    --router-port int16       Sets the port to use for the integrated router
-u, --username string         Username to use when creating the Ziti Edge Controller. default: admin

    Example Usage:

    ziti edge quickstart \
  --ctrl-address potato \
  --ctrl-port 12345 \
  --router-address avocado \
  --router-port 23456 \
  --home $HOME/.ziti/pet-ziti \
  --already-initialized \
  --username someOtherUsername \
  --password someOtherPassword

  • Bugfixes

Component Updates and Bug Fixes

  • github.com/openziti/ziti: v0.30.3 -> v0.30.4
    • Fixed an issue causing router configs to be rewritten when docker compose was brought up with existing configs

Release 0.30.3

What's New

  • Bugfixes

Component Updates and Bug Fixes

Release 0.30.2

What's New

  • Identity type consolidation
  • HTTP Connect Proxy support for control channel and links

Identity Type Consolidation

Prior to this release there were four identity types:

  • User
  • Service
  • Device
  • Router

Of these four types, only Router has any functional purpose. Given that, the other three have been merged into a single Default identity type. Since Router identities can only be created by the system, it's no longer necessary to specify the identity type when creating identities.

The identity type may still be provided, but a deprecation warning will be emitted.

Backwards Compatibility

Existing non-Router identities will be migrated to the Default identity type. If an identity type other than Default is provided when creating an identity, it will be coerced to the Default type. Existing code may have issues with the new identity type being returned.

HTTP Connect Proxy support

Routers may now specify a proxy configuration which will be used when establishing connections to controllers and data links to other routers. At this point only HTTP Connect Proxies with no authentication required are supported.

Example router config:

proxy:
  type: http
  address: localhost:3128

Component Updates and Bug Fixes

Release 0.30.1

What's New

Component Updates and Bug Fixes

  • github.com/openziti/ziti: v0.30.0 -> v0.30.1
    • Issue #1225 - Updated ZITI_ROUTER_ADVERTISED_HOST to use the more common naming convention of ZITI_ROUTER_ADVERTISED_ADDRESS
    • Issue #1233 - Added lsof to the list of prerequisites to be checked during quickstart

Release 0.30.0

What's New

  • Link management is now delegated to routers
  • Controller and routers can operate with a single listening port

Link Management Updates

Previously, the controller would do its best to determine where links needed to be established. It would send messages to the routers, telling them which addresses to dial on other routes. The routers would in turn let the controller know if link establishment was successful or if the router already had a link to the given endpoint.

With this release, the controller will only let routers know which routers exist, whether they are currently connected to the controller, and what link listeners they are advertising. The routers will now decide which links to make and let the controllers know as links are created and broken.

Link Groups

Both dialers and listeners can now specify a set of groups. If no groups are specified, the dialer or listener will be placed in the default group. Dialers will only attempt to dial listeners who have at least one group in common with them.

Failed Links

Previously when a link failed, the controller would show it in the link list as failed for a time before removing it. Now failed links are removed immediately. There are existing link events for link creation and link failure which can be used for forensics.

Duplicate Links

There is a new link status Duplicate used when a router receives a link request and determines that it's a duplicate of an existing link. This happens when two routers both have listeners and dialers. They will often dial each other at the same time, resulting in a duplicate link.

Compatibility

If you use a 0.30+ controller with older routers, the controller will still do link calculation and send dial messages, as long as the enableLegacyLinkMgmt setting is set to true.

If you use a pre 0.30.0 controller with newer routers, the new routers will still accept the dial messages.

New Configuration

Controller

The controller has three new options:

network:
    routerMessaging:
        queueSize: 100
        maxWorkers: 100
    enableLegacyLinkMgmt: true

When a router connects or disconnects from the controller, we send two sets of updates.

  1. If a router has connected we send it the the state of the other routers
  2. We send all the other routers the updated state of the connecting/disconnecting router

These messages are sent using a worker pool. The size of the queue feeding the worker pool is controlled with routerMessaging.queueSize. The max size of the worker pool is controlled used the routerMessaging.maxWorkers option.

  • queueSize
    • Min value: 0
    • Max value: 1,000,000
    • Default: 100
  • maxWorkers
    • Min value: 1
    • Max value: 10,000
    • Default: 100

If you have routers older than 0.30.0, the controller will calculate which links to dial. This can be disabled by setting enableLegacyLinkMgmt to false. This setting currently defaults to true, but will default to false in a future release. In a subsequent release this functionality will be removed all together.

Router

The router has new configuration options for link dialing.

link:
   dialers:
       - binding: transport
         groups: 
             - public
             - vpc1234
         healthyDialBackoff:
             retryBackoffFactor: 1.5
             minRetryInterval: 5s
             maxRetryInterval: 5m
         unhealthyDialBackoff:
             retryBackoffFactor: 10
             minRetryInterval: 1m
             maxRetryInterval: 1h
    listeners:
        - binding: transport
          groups: vpc1234

Groups

See above for a description of link groups work.

Default value: default

Dial Back-off

Dialers can be configured with custom back-off behavior. Each dialer has a back-off policy for dialing healthy routers (those that are connected to a controller) and a separate policy for unhealthy routers.

The back-off policies have the following attributes:

  • minRetryInterval - duration specifying the minimum time between dial attempts
  • maxRetryInterval - duration specifying the maximum time between dial attempts
  • retryBackoffFactor - factor by which to increase the retry interval between failed dial attempts
    • Min value: 1
    • Max value: 100
    • Default: 1.5 for healthy, 100 for unhealthy

Single Port Support / ALPN

Ziti Controller and Routers can operate with a single open port. In order to implement this feature we use ALPN (Application Layer Protocol Negotiation) TLS extension. It allows TLS client to request and TLS server to select appropriate application protocol handler during TLS handshake.

Protocol Details

The following protocol identifiers are defined:

id purpose
ziti-ctrl Control plane connections
ziti-link Fabric link connections
ziti-edge Client SDK connection to Edge Routers

Standard HTTP protocol identifiers (h2, http/1.1) are used for Controller REST API and Websocket listeners.

Backward Compatibility

This feature is designed to be backward compatible with SDK clients: older client will still be able to connect without requesting ziti-edge protocol.

Breaking

Older routers won't be able to establish control channel or fabric links with updated network. However, newer Edge Routers should be able to join older network in some circumstances -- only outbound links from new Routers would work.

Component Updates and Bug Fixes

Release 0.29.0

What's New

Deprecated Binary Removal

This release removes the following deprecated binaries from the release archives.

  • ziti-controller - replaced by ziti controller
  • ziti-router - replaced by ziti router
  • ziti-tunnel - replaced by ziti tunnel

The release archives now only contain the ziti executable. This executable is now at the root of the archive instead of nested under a ziti directory.

Ziti CLI Demo Consolidation

The ziti CLI functions under ziti learn, namely ziti learn demo and ziti learn tutorial have been consolidated under ziti demo.

Continued Quickstart Changes

The quickstart continues to evolve. A breaking change has occurred as numerous environment variables used to customize the quickstart have changed again. A summary of changes is below

  • All ZITI_EDGE_ROUTER_ variables have been changed to just ZITI_ROUTER_.
    • ZITI_EDGE_ROUTER_NAME -> ZITI_ROUTER_NAME
    • ZITI_EDGE_ROUTER_PORT -> ZITI_ROUTER_PORT
    • ZITI_EDGE_ROUTER_ADVERTISED_HOST -> ZITI_ROUTER_ADVERTISED_HOST
    • ZITI_EDGE_ROUTER_IP_OVERRIDE -> ZITI_ROUTER_IP_OVERRIDE
    • ZITI_EDGE_ROUTER_ENROLLMENT_DURATION -> ZITI_ROUTER_ENROLLMENT_DURATION
    • ZITI_EDGE_ROUTER_ADVERTISED_HOST -> ZITI_ROUTER_ADVERTISED_HOST
    • ZITI_EDGE_ROUTER_LISTENER_BIND_PORT -> ZITI_ROUTER_LISTENER_BIND_PORT
  • Additional variables have been added to support "alternative addresses" and "alternative PKI", for example to support using Let's Encrypt certificates easily in the quickstarts.
  • New variables were introduced to allow automatic generation of the alt_server_certs section. Both variables must be supplied for the variables to impact the configurations.
    • ZITI_PKI_ALT_SERVER_CERT - "Alternative server certificate. Must be specified with ZITI_PKI_ALT_SERVER_KEY"
    • ZITI_PKI_ALT_SERVER_KEY - "Key to use with the alternative server certificate. Must be specified with ZITI_PKI_ALT_SERVER_CERT"
  • New variables were introduced to allow one to override and customize the CSR section of routers which is used during enrollment.
    • ZITI_ROUTER_CSR_C - "The country (C) to use for router CSRs"
    • ZITI_ROUTER_CSR_ST - "The state/province (ST) to use for router CSRs"
    • ZITI_ROUTER_CSR_L - "The locality (L) to use for router CSRs"
    • ZITI_ROUTER_CSR_O - "The organization (O) to use for router CSRs"
    • ZITI_ROUTER_CSR_OU - "The organization unit to use for router CSRs"
    • ZITI_ROUTER_CSR_SANS_DNS - "The DNS name used in the CSR request"
  • New variable ZITI_CTRL_EDGE_BIND_ADDRESS allows controlling the IP the edge API uses

Component Updates and Bug Fixes

Release 0.28.4

Component Updates and Bug Fixes

  • Restores Ziti Edge Client API as the default handler for /version and as the root handler to support previously enrolled GO SDK clients

Release 0.28.3

What's New

Bug fix

Component Updates and Bug Fixes

Release 0.28.2

What's New

  • IMPORTANT: If you update your OpenZiti binaries to this version or later (which can be done easily with the getZiti() function, you will need to migrate any existing network that has been developed using OpenZiti v0.27.5 or earlier binaries as the new binaries will expect the new environment variable names. A function performMigration() has been provided in the ziti-cli-script.sh for this purpose. Simply source the latest ziti-cli-script.sh, and your current network's .env file, then run performMigration() to update environment variable name references. If the migration process cannot find your existing environment file in the default location, you will need to provide the path to the migration function, ex: performMigration <path-to-environment-file>
  • If you were using the ZITI_HOME environment variable to configure where your ziti CLI profiles were stored, you should now use ZITI_CONFIG_DIR instead.

Component Updates and Bug Fixes

Release 0.28.1

What's New

  • ziti CLI now trims jwt files specified for login preventing a confusing invalid header field value for "Authorization" error when trying to use -e flag

Router Health Check Changes

The link health check on routers now supports an initial delay configuration.


healthChecks:
  linkCheck:
    minLinks: 1
    interval: 30s
    initialDelay: 5s

The health check will also now start with an initial state of unhealthy, unless minLinks is set to zero.

Finally, link checks now include the addresses associated with the links:

    {
        "details": [
            {
                "linkId": "6a72EtnLib5nUvjhVLuHOb",
                "destRouterId": "5uUxuQ3u6Q",
                "latency": 2732886.5,
                "addresses": {
                    "ack": {
                        "localAddr": "tcp:127.0.0.1:4023",
                        "remoteAddr": "tcp:127.0.0.1:33520"
                    },
                    "payload": {
                        "localAddr": "tcp:127.0.0.1:4023",
                        "remoteAddr": "tcp:127.0.0.1:33504"
                    }
                }
            }
        ],
        "healthy": true,
        "id": "link.health",
        "lastCheckDuration": "53.213µs",
        "lastCheckTime": "2023-06-01T18:35:11Z"
    }

Event Changes

AMQP Event Writer Changes

A new field is available to the AMQP Event Writer. bufferSize denotes how many messages ziti will hold during AMQP connection outages. Any messages exceeding this limit will be logged and dropped.

Example configuration:

events:
  jsonLogger:
    subscriptions:
      - type: fabric.circuits
    handler:
      type: amqp
      format: json
      url: "amqp://localhost:5672" 
      queue: ziti
      durable: true      //default:true
      autoDelete: false  //default:false
      exclusive: false   //default:false
      noWait: false      //default:false
      bufferSize: 50     //default:50

Component Updates and Bug Fixes

Release 0.28.0

What's New

  • Event changes
    • Added AMQP event writer for events
    • Add entity change events for auditing or external integration
    • Add usage event filtering
    • Add annotations to circuit events
  • CLI additions for ziti to login with certificates or external-jwt-signers
  • NOTE: ziti edge login flag changes:
    • -c flag has been changed to map to --client-cert
    • --cert is now --ca and has no short flag representation
    • -e/--ext-jwt allows a user to supply a file containing a jwt used with ext-jwt-signers to login
    • -c/--client-cert allows a certificate to be supplied to login (used with -k/--client-key)
    • -k/--client-key allows a key to be supplied to login (used with -c/--client-cert)
  • Config type changes
    • address fields in intercept.v1, host.v1, and host.v2 config types now permit hostnames with underscores.
  • Edge Router/Tunneler now supports setting default UDP idle timeout/check interval

Event Changes

AMQP Event Writer

Previously events could only be emitted to a file. They can now also be emitted to an AMQP endpoint.

Example configuration:

events:
  jsonLogger:
    subscriptions:
      - type: fabric.circuits
    handler:
      type: amqp
      format: json
      url: "amqp://localhost:5672" 
      queue: ziti
      durable: true      //default:true
      autoDelete: false  //default:false
      exclusive: false   //default:false
      noWait: false      //default:false

Entity Change Events

OpenZiti can now be configured to emit entity change events. These events describe the changes when entities stored in the bbolt database are created, updated or deleted.

Note that events are emitted during the transaction. They are emitted at the end, so it's unlikely, but possible that an event will be emitted for a change which is rolled back. For this reason a following event will emitted when the change is committed. If a system crashes after commit, but before the committed event can be emitted, it will be emitted on the next startup.

Example configuration:

events:
  jsonLogger:
    subscriptions:
      - type: entityChange
        include:
          - services
          - identities
    handler:
      type: file
      format: json
      path: /tmp/ziti-events.log

See the related issue for discussion: openziti/fabric#562

Example output:

{
  "namespace": "entityChange",
  "eventId": "326faf6c-8123-42ae-9ed8-6fd9560eb567",
  "eventType": "created",
  "timestamp": "2023-05-11T21:41:47.128588927-04:00",
  "metadata": {
    "author": {
      "type": "identity",
      "id": "ji2Rt8KJ4",
      "name": "Default Admin"
    },
    "source": {
      "type": "rest",
      "auth": "edge",
      "localAddr": "localhost:1280",
      "remoteAddr": "127.0.0.1:37578",
      "method": "POST"
    },
    "version": "v0.0.0"
  },
  "entityType": "services",
  "isParentEvent": false,
  "initialState": null,
  "finalState": {
    "id": "6S0bCGWb6yrAutXwSQaLiv",
    "createdAt": "2023-05-12T01:41:47.128138887Z",
    "updatedAt": "2023-05-12T01:41:47.128138887Z",
    "tags": {},
    "isSystem": false,
    "name": "test",
    "terminatorStrategy": "smartrouting",
    "roleAttributes": [
      "goodbye",
      "hello"
    ],
    "configs": null,
    "encryptionRequired": true
  }
}

{
  "namespace": "entityChange",
  "eventId": "326faf6c-8123-42ae-9ed8-6fd9560eb567",
  "eventType": "committed",
  "timestamp": "2023-05-11T21:41:47.129235443-04:00"
}

Usage Event Filtering

Usage events, version 3, can now be filtered based on type.

The valid types include:

  • ingress.rx
  • ingress.tx
  • egress.rx
  • egress.tx
  • fabric.rx
  • fabric.tx

Example configuration:

events:
  jsonLogger:
    subscriptions:
      - type: fabric.usage
        version: 3
        include:
          - ingress.rx
          - egress.rx

Circuit Event Annotations

Circuit events initiated from the edge are now annotated with clientId, hostId and serviceId, to match usage events. The client and host ids are identity ids.

Example output:

 {
  "namespace": "fabric.circuits",
  "version": 2,
  "event_type": "created",
  "circuit_id": "0CEjWYiw6",
  "timestamp": "2023-05-05T11:44:03.242399585-04:00",
  "client_id": "clhaq7u7600o4ucgdpxy9i4t1",
  "service_id": "QARLLTKjqfLZytmSsIqba",
  "terminator_id": "7ddcd421-2b00-4b49-9ac0-8c78fe388c30",
  "instance_id": "",
  "creation_timespan": 1014280,
  "path": {
    "nodes": [
      "U7OwPtfjg",
      "a4rC9DrZ3"
    ],
    "links": [
      "7Ru3hoxsssZzUNOyvd8Jcb"
    ],
    "ingress_id": "K9lD",
    "egress_id": "rQLK",
    "initiator_local_addr": "100.64.0.1:1234",
    "initiator_remote_addr": "100.64.0.1:37640",
    "terminator_local_addr": "127.0.0.1:45566",
    "terminator_remote_addr": "127.0.0.1:1234"
  },
  "link_count": 1,
  "path_cost": 392151,
  "tags": {
    "clientId": "U7OwPtfjg",
    "hostId": "a4rC9DrZ3",
    "serviceId": "QARLLTKjqfLZytmSsIqba"
  }
}

ER/T UDP Settings

The edge router tunneler now allows configuring a timeout and check interval for tproxy UDP intercepts. By default intercepted UDP connections will be closed after five minutes of no traffic, checking every thirty seconds. The configuration is done in the router config file, in the options for the tunnel module. Note that these configuration options only apply to tproxy intercepts, not to proxy or host side UDP connections.

Example configuration:

listeners:
  - binding: tunnel
    options:
      mode: tproxy
      udpIdleTimeout: 10s
      udpCheckInterval: 5s

Component Updates and Bug Fixes

Archived Changelogs

Archives are in the changelogs folder.