v1.6.14

Release 1.6.14

What's New

• Bug fixes and dependency updates
• Update to Golang v1.26

Component Updates and Bug Fixes

• github.com/openziti/sdk-golang: v1.2.4 -> v1.2.4-patch1

  • Issue #892 - Backport-1.2.4: Handle differences in xgress eof/end-of-circuit handling by adding a capabilities exchange

• github.com/openziti/ziti: v1.6.13 -> v1.6.14

  • Issue #3646 - Backport-1.6: Use xgress_common.Connection type for xgress_transport and xgress_proxy

v2.0.0-pre5

Release 2.0.0

What's New

This is the next major version release of OpenZiti, following the 1.0 release in April 2024.
Of particular note is that HA controllers are now considered ready for general use.
This release also introduces a new permissions model, OIDC/JWT token-based enrollment,
clustering performance improvements, and a number of other features and fixes. Because
some of these changes are not backwards compatible with older routers, we're marking this
as a major version bump.

HA Controllers are now considered ready for general use

This is a pretty big milestone and marks the completion of work that's been ongoing for a couple of years.
The HA work has brought with it some notable changes. Authentication now uses JWTs by default. Using JWTs
means the controllers don't need to store session and propagate them to the routers. This removes a bottleneck
from the network and allows the load to be more easily distributed among controllers and routers.

To support distributed authentication, the routers now get a bespoke version of the data model. In addition
to enabling distributed authentication this will allow us to remove the need for service polling and further
reduce the load on controllers in the future.

Router Compatibility

Related to the JWT work, routers with version 2.+ will only work with controllers that are version 2.+. This means
to upgrade your network, controllers should be upgraded first. Routers can then be upgraded individually.

2.x routers should still work fine with older router versions.

We try very hard to avoid breaking changes like this, but sometimes the engineering trade-offs lead there. This change
was first made in the 1.7 release. That release has not been marked stable, and we have no plans to do so, because
of the backwards incompatibility.

If you need to support in the 1.6.12+ range, see the section "OIDC enabled by default".

New Permissions Model (BETA)

As one feature goes out of beta, another arrives into beta. This release introduces a new permissions system
for more fine grained control to the management API. It's not expected to change, but may do so based on feedback
from users.

Updated Release Process

We have moved to creating -preN releases for major and minor versions. This way we can put out release candidates,
or feature previews and put them through internal testing and let interested folks from the community try them out.
Then, when we're ready, we can run the full validation suite against the last pre-release and retag it.

Patch releases won't have -preN and should contain only high priority bug fixes.

Deprecation Cleanup

Since we already have a breaking change, we're removing some other backwards compatibility code.

• Controller managed links
  • Router managed links were introduced in v0.30.0.
  • If you're upgrading from an older versions, you'll want to upgrade to the latest 1.x release before jumping to 2.x
  • Github tracking issue: #3512
• ziti edge create identity <type>
  • Identity types other than router were removed in v0.30.2
  • The type can be dropped from the CLI command
  • Github tracking issue: #3532
• Terminator create/update/delete events
  • These have been superseded by entity change events, which also have create/update/delete events for terminators
  • Entity change events were introduced in v0.28.0
  • Github tracking issue: #3531
• xgress_edge_tunnel v1
  • This is the first implementation of the tunneler in edge-router code (ER/T) which used legacy api sessions and services
  • The v2 version uses the router data model and was introduced in v0.30.x
  • Github tracking issue: #3516

Legacy Session Deprecation

OIDC sessions are now preferred. They are the default, or will become the default for SDKs and tunnelers. They are also required
when running HA. Legacy API and service session are now deprecated and will be removed in the OpenZiti v3.0.0 release.

Additional Features

• Controllers can now optionally bind APIs using an OpenZiti identity
• ziti edge login now supports the --network-identity flag to authenticate and establish connections through the Ziti overlay network
• ziti edge login now supports using a bearer token with --token for authentication. The token is expected to be
  provided as just the JWT, not with the "Bearer " prefix
• Identity configuration can now be loaded from files or environment variables for flexible deployment scenarios
• Identities can now be provisioned just-in-time through OIDC/JWT token-based enrollment
• Multiple model updates can now be in-flight at the same time, improving clustering performance
• Authentication-related model updates can now be non-blocking and even dropped if the system is too busy
• Routers now provide more error context to SDKs for terminator errors, enabling better retry behavior
• New proxy.v1 config type for dynamic service proxies (originally released in 1.7.0)
• New alert event type for surfacing operational issues to network operators - Beta (originally released in 1.7.0)
• New Azure Service Bus event sink for streaming controller events, contributed by @ffaraone (originally released in 1.7.0)
• Bundled ZAC upgraded to 4.0
• Build updated to Go 1.25
• CLI cleaned up to remove calls to os.Exit, making it more friendly for embedding
• OIDC is now enabled by default
• Controller Edge APIs now return WWW-Authenticate response headers on 401 Unauthorized responses, giving clients actionable information about which auth methods are accepted and what went wrong
• HA Controllers can be marked as 'preferredLeader' via config
• Dynamic cost range for smart routing expanded beyond the previous 64K limit
• Dial failures now return the circuit ID and error information for easier debugging
• Router-to-controller control channels now support multiple underlays with priority-based message routing
• The dialing identity's ID and name are now forwarded to the hosting SDK
• Controllers can now dial routers to establish control channels, enabling connectivity when routers are behind firewalls (Beta)

Basic Permission System (BETA)

Added a basic permission system that allows more control over identity access to controller management API operations.
This replaces the previous binary admin/non-admin model with a more flexible permission system.

NOTE: This feature is in BETA, primarily so we can get feedback on which permissions make sense. The implementation is unlikely to change
but the set of exposed permissions may grow, shrink or change based on user feedback.

Permission Model

The permission system supports three levels of authorization:

1. Global Permissions: System-wide access levels

   • admin - Full access to all operations. This is still controlled by the isAdmin flag on identity
   • admin_readonly - Read-only access to all resources except debugging facilities inspect and validate

2. Entity-Level Permissions: Full CRUD access to specific entity types

   • Granting an entity-level permission (e.g., service) provides complete create, read, update, and delete access for that entity type

3. Action-Level Permissions: Specific operation access on entity types

   • Fine-grained control using the pattern <entity>.<action> (e.g., service.read, identity.update)
   • Supports create, read, update, and delete actions per entity type

Supported Entity Permissions

The following entity-level permissions are available:

• auth-policy - Authentication policy management
• ca - Certificate Authority management
• config - Configuration management
• config-type - Configuration type management
• edge-router-policy - Edge router policy management
• enrollment - Enrollment management
• external-jwt-signer - External JWT signer management
• identity - Identity management
• posture-check - Posture check management
• router - Edge and transit router management
• service - Service management
• service-policy - Service policy management
• service-edge-router-policy - Service edge router policy management
• terminator - Terminator management
• ops - Operational resources (API sessions, sessions, circuits, links, inspect and validate)

Permission Assignment

Permissions are assigned to identities via the permissions field in the identity resource. Multiple permissions can be granted to a single identity, and permissions are additive.

Cross-Entity Operations

Listing related entities through an entity's endpoints requires appropriate permissions for the related entity type. For example:

• Listing services for a service-policy requires service.read permission
• Listing identities for an edge-router-policy requires identity.read permission
• Listing configs for a service requires config.read permission

NOTE:
More permissions than expected may be required when performing actions through the CLI or ZAC. Take for example, when an identity
has config.create and is attempting to create a new config. The CLI may fail if the identity doesn't have config-type.read
as well because it will need to look up the config type id that corresponds to the given config type name.

Similar cross entity read permissions may be required when creating services.

Admin Protection

Non-admin identities cannot:

• Create identities with the isAdmin flag
• Create identities with any permissions granted
• Modify admin-related fields on existing identities
• Update or delete admin identities
• Grant permissions to identities

These protections ensure that privilege escalation is prevented and admin access remains controlled.

Binding Controller APIs With Identity

Controller APIs can now be bound to an OpenZiti overlay network identity, ...

v2.0.0-pre4

Release 2.0.0

What's New

This is the next major version release of OpenZiti, following the 1.0 release in April 2024.
Of particular note is that HA controllers are now considered ready for general use.
This release also introduces a new permissions model, OIDC/JWT token-based enrollment,
clustering performance improvements, and a number of other features and fixes. Because
some of these changes are not backwards compatible with older routers, we're marking this
as a major version bump.

HA Controllers are now considered ready for general use

This is a pretty big milestone and marks the completion of work that's been ongoing for a couple of years.
The HA work has brought with it some notable changes. Authentication now uses JWTs by default. Using JWTs
means the controllers don't need to store session and propagate them to the routers. This removes a bottleneck
from the network and allows the load to be more easily distributed among controllers and routers.

To support distributed authentication, the routers now get a bespoke version of the data model. In addition
to enabling distributed authentication this will allow us to remove the need for service polling and further
reduce the load on controllers in the future.

Router Compatibility

Related to the JWT work, routers with version 2.+ will only work with controllers that are version 2.+. This means
to upgrade your network, controllers should be upgraded first. Routers can then be upgraded individually.

2.x routers should still work fine with older router versions.

We try very hard to avoid breaking changes like this, but sometimes the engineering trade-offs lead there. This change
was first made in the 1.7 release. That release has not been marked stable, and we have no plans to do so, because
of the backwards incompatibility.

If you need to support in the 1.6.12+ range, see the section "OIDC enabled by default".

New Permissions Model (BETA)

As one feature goes out of beta, another arrives into beta. This release introduces a new permissions system
for more fine grained control to the management API. It's not expected to change, but may do so based on feedback
from users.

Updated Release Process

We have moved to creating -preN releases for major and minor versions. This way we can put out release candidates,
or feature previews and put them through internal testing and let interested folks from the community try them out.
Then, when we're ready, we can run the full validation suite against the last pre-release and retag it.

Patch releases won't have -preN and should contain only high priority bug fixes.

Deprecation Cleanup

Since we already have a breaking change, we're removing some other backwards compatibility code.

• Controller managed links
  • Router managed links were introduced in v0.30.0.
  • If you're upgrading from an older versions, you'll want to upgrade to the latest 1.x release before jumping to 2.x
  • Github tracking issue: #3512
• ziti edge create identity <type>
  • Identity types other than router were removed in v0.30.2
  • The type can be dropped from the CLI command
  • Github tracking issue: #3532
• Terminator create/update/delete events
  • These have been superseded by entity change events, which also have create/update/delete events for terminators
  • Entity change events were introduced in v0.28.0
  • Github tracking issue: #3531
• xgress_edge_tunnel v1
  • This is the first implementation of the tunneler in edge-router code (ER/T) which used legacy api sessions and services
  • The v2 version uses the router data model and was introduced in v0.30.x
  • Github tracking issue: #3516

Legacy Session Deprecation

OIDC sessions are now preferred. They are the default, or will become the default for SDKs and tunnelers. They are also required
when running HA. Legacy API and service session are now deprecated and will be removed in the OpenZiti v3.0.0 release.

Additional Features

• Controllers can now optionally bind APIs using an OpenZiti identity
• ziti edge login now supports the --network-identity flag to authenticate and establish connections through the Ziti overlay network
• ziti edge login now supports using a bearer token with --token for authentication. The token is expected to be
  provided as just the JWT, not with the "Bearer " prefix
• Identity configuration can now be loaded from files or environment variables for flexible deployment scenarios
• Identities can now be provisioned just-in-time through OIDC/JWT token-based enrollment
• Multiple model updates can now be in-flight at the same time, improving clustering performance
• Authentication-related model updates can now be non-blocking and even dropped if the system is too busy
• Routers now provide more error context to SDKs for terminator errors, enabling better retry behavior
• New proxy.v1 config type for dynamic service proxies (originally released in 1.7.0)
• New alert event type for surfacing operational issues to network operators - Beta (originally released in 1.7.0)
• New Azure Service Bus event sink for streaming controller events, contributed by @ffaraone (originally released in 1.7.0)
• Bundled ZAC upgraded to 4.0
• Build updated to Go 1.25
• CLI cleaned up to remove calls to os.Exit, making it more friendly for embedding
• OIDC is now enabled by default
• Controller Edge APIs now return WWW-Authenticate response headers on 401 Unauthorized responses, giving clients actionable information about which auth methods are accepted and what went wrong
• HA Controllers can be marked as 'preferredLeader' via config
• Dynamic cost range for smart routing expanded beyond the previous 64K limit
• Dial failures now return the circuit ID and error information for easier debugging
• Router-to-controller control channels now support multiple underlays with priority-based message routing
• The dialing identity's ID and name are now forwarded to the hosting SDK
• Controllers can now dial routers to establish control channels, enabling connectivity when routers are behind firewalls (Beta)

Basic Permission System (BETA)

Added a basic permission system that allows more control over identity access to controller management API operations.
This replaces the previous binary admin/non-admin model with a more flexible permission system.

NOTE: This feature is in BETA, primarily so we can get feedback on which permissions make sense. The implementation is unlikely to change
but the set of exposed permissions may grow, shrink or change based on user feedback.

Permission Model

The permission system supports three levels of authorization:

1. Global Permissions: System-wide access levels

   • admin - Full access to all operations. This is still controlled by the isAdmin flag on identity
   • admin_readonly - Read-only access to all resources except debugging facilities inspect and validate

2. Entity-Level Permissions: Full CRUD access to specific entity types

   • Granting an entity-level permission (e.g., service) provides complete create, read, update, and delete access for that entity type

3. Action-Level Permissions: Specific operation access on entity types

   • Fine-grained control using the pattern <entity>.<action> (e.g., service.read, identity.update)
   • Supports create, read, update, and delete actions per entity type

Supported Entity Permissions

The following entity-level permissions are available:

• auth-policy - Authentication policy management
• ca - Certificate Authority management
• config - Configuration management
• config-type - Configuration type management
• edge-router-policy - Edge router policy management
• enrollment - Enrollment management
• external-jwt-signer - External JWT signer management
• identity - Identity management
• posture-check - Posture check management
• router - Edge and transit router management
• service - Service management
• service-policy - Service policy management
• service-edge-router-policy - Service edge router policy management
• terminator - Terminator management
• ops - Operational resources (API sessions, sessions, circuits, links, inspect and validate)

Permission Assignment

Permissions are assigned to identities via the permissions field in the identity resource. Multiple permissions can be granted to a single identity, and permissions are additive.

Cross-Entity Operations

Listing related entities through an entity's endpoints requires appropriate permissions for the related entity type. For example:

• Listing services for a service-policy requires service.read permission
• Listing identities for an edge-router-policy requires identity.read permission
• Listing configs for a service requires config.read permission

NOTE:
More permissions than expected may be required when performing actions through the CLI or ZAC. Take for example, when an identity
has config.create and is attempting to create a new config. The CLI may fail if the identity doesn't have config-type.read
as well because it will need to look up the config type id that corresponds to the given config type name.

Similar cross entity read permissions may be required when creating services.

Admin Protection

Non-admin identities cannot:

• Create identities with the isAdmin flag
• Create identities with any permissions granted
• Modify admin-related fields on existing identities
• Update or delete admin identities
• Grant permissions to identities

These protections ensure that privilege escalation is prevented and admin access remains controlled.

Binding Controller APIs With Identity

Controller APIs can now be bound to an OpenZiti overlay network identity, ...

v2.0.0-pre3

Release 2.0.0

What's New

This is the next major version release of OpenZiti, following the 1.0 release in April 2024.
Of particular note is that HA controllers are now considered ready for general use.
This release also introduces a new permissions model, OIDC/JWT token-based enrollment,
clustering performance improvements, and a number of other features and fixes. Because
some of these changes are not backwards compatible with older routers, we're marking this
as a major version bump.

HA Controllers are now considered ready for general use

This is a pretty big milestone and marks the completion of work that's been ongoing for a couple of years.
The HA work has brought with it some notable changes. Authentication now uses JWTs by default. Using JWTs
means the controllers don't need to store session and propagate them to the routers. This removes a bottleneck
from the network and allows the load to be more easily distributed among controllers and routers.

To support distributed authentication, the routers now get a bespoke version of the data model. In addition
to enabling distributed authentication this will allow us to remove the need for service polling and further
reduce the load on controllers in the future.

Router Compatibility

Related to the JWT work, routers with version 2.+ will only work with controllers that are version 2.+. This means
to upgrade your network, controllers should be upgraded first. Routers can then be upgraded individually.

2.x routers should still work fine with older router versions.

We try very hard to avoid breaking changes like this, but sometimes the engineering trade-offs lead there. This change
was first made in the 1.7 release. That release has not been marked stable, and we have no plans to do so, because
of the backwards incompatibility.

If you need to support in the 1.6.12+ range, see the section "OIDC enabled by default".

New Permissions Model (BETA)

As one feature goes out of beta, another arrives into beta. This release introduces a new permissions system
for more fine grained control to the management API. It's not expected to change, but may do so based on feedback
from users.

Updated Release Process

We have moved to creating -preN releases for major and minor versions. This way we can put out release candidates,
or feature previews and put them through internal testing and let interested folks from the community try them out.
Then, when we're ready, we can run the full validation suite against the last pre-release and retag it.

Patch releases won't have -preN and should contain only high priority bug fixes.

Deprecation Cleanup

Since we already have a breaking change, we're removing some other backwards compatibility code.

• Controller managed links
  • Router managed links were introduced in v0.30.0.
  • If you're upgrading from an older versions, you'll want to upgrade to the latest 1.x release before jumping to 2.x
  • Github tracking issue: #3512
• ziti edge create identity <type>
  • Identity types other than router were removed in v0.30.2
  • The type can be dropped from the CLI command
  • Github tracking issue: #3532
• Terminator create/update/delete events
  • These have been superseded by entity change events, which also have create/update/delete events for terminators
  • Entity change events were introduced in v0.28.0
  • Github tracking issue: #3531
• xgress_edge_tunnel v1
  • This is the first implementation of the tunneler in edge-router code (ER/T) which used legacy api sessions and services
  • The v2 version uses the router data model and was introduced in v0.30.x
  • Github tracking issue: #3516

Legacy Session Deprecation

OIDC sessions are now preferred. They are the default, or will become the default for SDKs and tunnelers. They are also required
when running HA. Legacy API and service session are now deprecated and will be removed in the OpenZiti v3.0.0 release.

Additional Features

• Controllers can now optionally bind APIs using an OpenZiti identity
• ziti edge login now supports the --network-identity flag to authenticate and establish connections through the Ziti overlay network
• ziti edge login now supports using a bearer token with --token for authentication. The token is expected to be
  provided as just the JWT, not with the "Bearer " prefix
• Identity configuration can now be loaded from files or environment variables for flexible deployment scenarios
• Identities can now be provisioned just-in-time through OIDC/JWT token-based enrollment
• Multiple model updates can now be in-flight at the same time, improving clustering performance
• Authentication-related model updates can now be non-blocking and even dropped if the system is too busy
• Routers now provide more error context to SDKs for terminator errors, enabling better retry behavior
• New proxy.v1 config type for dynamic service proxies (originally released in 1.7.0)
• New alert event type for surfacing operational issues to network operators - Beta (originally released in 1.7.0)
• New Azure Service Bus event sink for streaming controller events, contributed by @ffaraone (originally released in 1.7.0)
• Bundled ZAC upgraded to 4.0
• Build updated to Go 1.25
• CLI cleaned up to remove calls to os.Exit, making it more friendly for embedding
• OIDC is now enabled by default
• Controller Edge APIs now return WWW-Authenticate response headers on 401 Unauthorized responses, giving clients actionable information about which auth methods are accepted and what went wrong
• HA Controllers can be marked as 'preferredLeader' via config
• Dynamic cost range for smart routing expanded beyond the previous 64K limit
• Dial failures now return the circuit ID and error information for easier debugging
• Router-to-controller control channels now support multiple underlays with priority-based message routing
• The dialing identity's ID and name are now forwarded to the hosting SDK

Basic Permission System (BETA)

Added a basic permission system that allows more control over identity access to controller management API operations.
This replaces the previous binary admin/non-admin model with a more flexible permission system.

NOTE: This feature is in BETA, primarily so we can get feedback on which permissions make sense. The implementation is unlikely to change
but the set of exposed permissions may grow, shrink or change based on user feedback.

Permission Model

The permission system supports three levels of authorization:

1. Global Permissions: System-wide access levels

   • admin - Full access to all operations. This is still controlled by the isAdmin flag on identity
   • admin_readonly - Read-only access to all resources except debugging facilities inspect and validate

2. Entity-Level Permissions: Full CRUD access to specific entity types

   • Granting an entity-level permission (e.g., service) provides complete create, read, update, and delete access for that entity type

3. Action-Level Permissions: Specific operation access on entity types

   • Fine-grained control using the pattern <entity>.<action> (e.g., service.read, identity.update)
   • Supports create, read, update, and delete actions per entity type

Supported Entity Permissions

The following entity-level permissions are available:

• auth-policy - Authentication policy management
• ca - Certificate Authority management
• config - Configuration management
• config-type - Configuration type management
• edge-router-policy - Edge router policy management
• enrollment - Enrollment management
• external-jwt-signer - External JWT signer management
• identity - Identity management
• posture-check - Posture check management
• router - Edge and transit router management
• service - Service management
• service-policy - Service policy management
• service-edge-router-policy - Service edge router policy management
• terminator - Terminator management
• ops - Operational resources (API sessions, sessions, circuits, links, inspect and validate)

Permission Assignment

Permissions are assigned to identities via the permissions field in the identity resource. Multiple permissions can be granted to a single identity, and permissions are additive.

Cross-Entity Operations

Listing related entities through an entity's endpoints requires appropriate permissions for the related entity type. For example:

• Listing services for a service-policy requires service.read permission
• Listing identities for an edge-router-policy requires identity.read permission
• Listing configs for a service requires config.read permission

NOTE:
More permissions than expected may be required when performing actions through the CLI or ZAC. Take for example, when an identity
has config.create and is attempting to create a new config. The CLI may fail if the identity doesn't have config-type.read
as well because it will need to look up the config type id that corresponds to the given config type name.

Similar cross entity read permissions may be required when creating services.

Admin Protection

Non-admin identities cannot:

• Create identities with the isAdmin flag
• Create identities with any permissions granted
• Modify admin-related fields on existing identities
• Update or delete admin identities
• Grant permissions to identities

These protections ensure that privilege escalation is prevented and admin access remains controlled.

Binding Controller APIs With Identity

Controller APIs can now be bound to an OpenZiti overlay network identity, allowing secure communication through
the Ziti network. This is useful for scenarios where you want to expose controller APIs onl...

v2.0.0-pre2

Release 2.0.0

What's New

This is the next major version release of OpenZiti, following the 1.0 release in April 2024.
Of particular note is that HA controllers are now considered ready for general use.
This release also introduces a new permissions model, OIDC/JWT token-based enrollment,
clustering performance improvements, and a number of other features and fixes. Because
some of these changes are not backwards compatible with older routers, we're marking this
as a major version bump.

HA Controllers are now considered ready for general use

This is a pretty big milestone and marks the completion of work that's been ongoing for a couple of years.
The HA work has brought with it some notable changes. Authentication now uses JWTs by default. Using JWTs
means the controllers don't need to store session and propagate them to the routers. This removes a bottleneck
from the network and allows the load to be more easily distributed among controllers and routers.

To support distributed authentication, the routers now get a bespoke version of the data model. In addition
to enabling distributed authentication this will allow us to remove the need for service polling and further
reduce the load on controllers in the future.

Router Compatibility

Related to the JWT work, routers with version 2.+ will only work with controllers that are version 2.+. This means
to upgrade your network, controllers should be upgraded first. Routers can then be upgraded individually.

2.x routers should still work fine with older router versions.

We try very hard to avoid breaking changes like this, but sometimes the engineering trade-offs lead there. This change
was first made in the 1.7 release. That release has not been marked stable, and we have no plans to do so, because
of the backwards incompatibility.

New Permissions Model (BETA)

As one feature goes out of beta, another arrives into beta. This release introduces a new permissions system
for more fine grained control to the management API. It's not expected to change, but may do so based on feedback
from users.

Updated Release Process

We have moved to creating -preN releases for major and minor versions. This way we can put out release candidates,
or feature previews and put them through internal testing and let interested folks from the community try them out.
Then, when we're ready, we can run the full validation suite against the last pre-release and retag it.

Patch releases won't have -preN and should contain only high priority bug fixes.

Deprecation Cleanup

Since we already have a breaking change, we're removing some other backwards compatibility code.

• Controller managed links
  • Router managed links were introduced in v0.30.0.
  • If you're upgrading from an older versions, you'll want to upgrade to the latest 1.x release before jumping to 2.x
  • Github tracking issue: #3512
• ziti edge create identity <type>
  • Identity types other than router were removed in v0.30.2
  • The type can be dropped from the CLI command
  • Github tracking issue: #3532
• Terminator create/update/delete events
  • These have been superseded by entity change events, which also have create/update/delete events for terminators
  • Entity change events were introduced in v0.28.0
  • Github tracking issue: #3531
• xgress_edge_tunnel v1
  • This is the first implementation of the tunneler in edge-router code (ER/T) which used legacy api sessions and services
  • The v2 version uses the router data model and was introduced in v0.30.x
  • Github tracking issue: #3516

Legacy Session Deprecation

OIDC sessions are now preferred. They are the default, or will become the default for SDKs and tunnelers. They are also required
when running HA. Legacy API and service session are now deprecated and will be removed in the OpenZiti v3.0.0 release.

Additional Features

• Controllers can now optionally bind APIs using an OpenZiti identity
• ziti edge login now supports the --network-identity flag to authenticate and establish connections through the Ziti overlay network
• ziti edge login now supports using a bearer token with --token for authentication. The token is expected to be
  provided as just the JWT, not with the "Bearer " prefix
• Identity configuration can now be loaded from files or environment variables for flexible deployment scenarios
• Identities can now be provisioned just-in-time through OIDC/JWT token-based enrollment
• Multiple model updates can now be in-flight at the same time, improving clustering performance
• Authentication-related model updates can now be non-blocking and even dropped if the system is too busy
• Routers now provide more error context to SDKs for terminator errors, enabling better retry behavior
• New proxy.v1 config type for dynamic service proxies (originally released in 1.7.0)
• New alert event type for surfacing operational issues to network operators - Beta (originally released in 1.7.0)
• New Azure Service Bus event sink for streaming controller events, contributed by @ffaraone (originally released in 1.7.0)
• Bundled ZAC upgraded to 4.0
• Build updated to Go 1.25
• CLI cleaned up to remove calls to os.Exit, making it more friendly for embedding
• Controller Edge APIs now return WWW-Authenticate response headers on 401 Unauthorized responses, giving clients actionable information about which auth methods are accepted and what went wrong
• HA Controllers can be marked as 'preferredLeader' via config
• Dynamic cost range for smart routing expanded beyond the previous 64K limit
• Dial failures now return the circuit ID and error information for easier debugging
• Router-to-controller control channels now support multiple underlays with priority-based message routing
• The dialing identity's ID and name are now forwarded to the hosting SDK

Basic Permission System (BETA)

Added a basic permission system that allows more control over identity access to controller management API operations.
This replaces the previous binary admin/non-admin model with a more flexible permission system.

NOTE: This feature is in BETA, primarily so we can get feedback on which permissions make sense. The implementation is unlikely to change
but the set of exposed permissions may grow, shrink or change based on user feedback.

Permission Model

The permission system supports three levels of authorization:

1. Global Permissions: System-wide access levels

   • admin - Full access to all operations. This is still controlled by the isAdmin flag on identity
   • admin_readonly - Read-only access to all resources except debugging facilities inspect and validate

2. Entity-Level Permissions: Full CRUD access to specific entity types

   • Granting an entity-level permission (e.g., service) provides complete create, read, update, and delete access for that entity type

3. Action-Level Permissions: Specific operation access on entity types

   • Fine-grained control using the pattern <entity>.<action> (e.g., service.read, identity.update)
   • Supports create, read, update, and delete actions per entity type

Supported Entity Permissions

The following entity-level permissions are available:

• auth-policy - Authentication policy management
• ca - Certificate Authority management
• config - Configuration management
• config-type - Configuration type management
• edge-router-policy - Edge router policy management
• enrollment - Enrollment management
• external-jwt-signer - External JWT signer management
• identity - Identity management
• posture-check - Posture check management
• router - Edge and transit router management
• service - Service management
• service-policy - Service policy management
• service-edge-router-policy - Service edge router policy management
• terminator - Terminator management
• ops - Operational resources (API sessions, sessions, circuits, links, inspect and validate)

Permission Assignment

Permissions are assigned to identities via the permissions field in the identity resource. Multiple permissions can be granted to a single identity, and permissions are additive.

Cross-Entity Operations

Listing related entities through an entity's endpoints requires appropriate permissions for the related entity type. For example:

• Listing services for a service-policy requires service.read permission
• Listing identities for an edge-router-policy requires identity.read permission
• Listing configs for a service requires config.read permission

NOTE:
More permissions than expected may be required when performing actions through the CLI or ZAC. Take for example, when an identity
has config.create and is attempting to create a new config. The CLI may fail if the identity doesn't have config-type.read
as well because it will need to look up the config type id that corresponds to the given config type name.

Similar cross entity read permissions may be required when creating services.

Admin Protection

Non-admin identities cannot:

• Create identities with the isAdmin flag
• Create identities with any permissions granted
• Modify admin-related fields on existing identities
• Update or delete admin identities
• Grant permissions to identities

These protections ensure that privilege escalation is prevented and admin access remains controlled.

Binding Controller APIs With Identity

Controller APIs can now be bound to an OpenZiti overlay network identity, allowing secure communication through
the Ziti network. This is useful for scenarios where you want to expose controller APIs only through the overlay
network rather than on a standard network interface.

Configuration Structure

A standard `bindPo...

v2.0.0-fp1

Release 2.0.0-fp1 (Feature Preview for Controller initiated control channel connections)

NOTE: This is a special feature branch release, specifically for people interested in trying the controller-initiated control channels work. Others should try the -preN releases instead. This work should be included in a -preN release shortly.

Relevant release notes have been copied to the top

Controller-Initiated Control Channel Dials (BETA)

Controllers can now dial routers to establish control channels. Previously, routers were solely
responsible for dialing controllers. This is useful in deployments where controllers are behind
firewalls and cannot be reached by all routers, but the controllers can reach the routers.

Router Configuration

Routers can configure one or more control channel listeners. Each listener specifies a bind address,
an advertise address (reported to the controller), and optional groups for matching.

ctrl:
  listeners:
    - bind: tls://0.0.0.0:6262
      advertise: tls://router.example.com:6262
      groups:
        - default

The advertise address is stored in the router's ctrlChanListeners model field and reported to
the controller. Groups default to ["default"] if not specified.

Routers will also report their configured ctrlChanListeners to the controller when they connect,
and the controller data model will be updated automatically.

The ctrlChanListeners field can also be set via the CLI:

ziti edge update edge-router myRouter --ctrl-chan-listener 'tls://router.example.com:6262=group1,group2'

Controller Configuration

The controller dialer is disabled by default and must be explicitly enabled. When enabled, the
controller will dial routers that have control channel listeners configured and are not already
connected.

ctrl:
  dialer:
    enabled: true
    groups:
      - default
    dialDelay: 30s

• enabled - Enables the controller dialer (default: false)
• groups - List of groups to match against router listener groups (default: ["default"])
• dialDelay - Delay before the controller attempts to dial a disconnected router (default: 30s)

The controller will only dial routers whose listener groups overlap with the controller's configured
groups.

2.0.0 Release Notes Below

What's New

This is the next major version release of OpenZiti, following the 1.0 release in April 2024.
Of particular note is that HA controllers are now considered ready for general use.
This release also introduces a new permissions model, OIDC/JWT token-based enrollment,
clustering performance improvements, and a number of other features and fixes. Because
some of these changes are not backwards compatible with older routers, we're marking this
as a major version bump.

HA Controllers are now considered ready for general use

This is a pretty big milestone and marks the completion of work that's been ongoing for a couple of years.
The HA work has brought with it some notable changes. Authentication now uses JWTs by default. Using JWTs
means the controllers don't need to store session and propagate them to the routers. This removes a bottleneck
from the network and allows the load to be more easily distributed among controllers and routers.

To support distributed authentication, the routers now get a bespoke version of the data model. In addition
to enabling distributed authentication this will allow us to remove the need for service polling and further
reduce the load on controllers in the future.

Router Compatibility

Related to the JWT work, routers with version 2.+ will only work with controllers that are version 2.+. This means
to upgrade your network, controllers should be upgraded first. Routers can then be upgraded individually.

2.x routers should still work fine with older router versions.

We try very hard to avoid breaking changes like this, but sometimes the engineering trade-offs lead there. This change
was first made in the 1.7 release. That release has not been marked stable, and we have no plans to do so, because
of the backwards incompatibility.

New Permissions Model (BETA)

As one feature goes out of beta, another arrives into beta. This release introduces a new permissions system
for more fine grained control to the management API. It's not expected to change, but may do so based on feedback
from users.

Updated Release Process

We have moved to creating -preN releases for major and minor versions. This way we can put out release candidates,
or feature previews and put them through internal testing and let interested folks from the community try them out.
Then, when we're ready, we can run the full validation suite against the last pre-release and retag it.

Patch releases won't have -preN and should contain only high priority bug fixes.

Deprecation Cleanup

Since we already have a breaking change, we're removing some other backwards compatibility code.

• Controller managed links
  • Router managed links were introduced in v0.30.0.
  • If you're upgrading from an older versions, you'll want to upgrade to the latest 1.x release before jumping to 2.x
  • Github tracking issue: #3512
• ziti edge create identity <type>
  • Identity types other than router were removed in v0.30.2
  • The type can be dropped from the CLI command
  • Github tracking issue: #3532
• Terminator create/update/delete events
  • These have been superseded by entity change events, which also have create/update/delete events for terminators
  • Entity change events were introduced in v0.28.0
  • Github tracking issue: #3531
• xgress_edge_tunnel v1
  • This is the first implementation of the tunneler in edge-router code (ER/T) which used legacy api sessions and services
  • The v2 version uses the router data model and was introduced in v0.30.x
  • Github tracking issue: #3516

Legacy Session Deprecation

OIDC sessions are now preferred. They are the default, or will become the default for SDKs and tunnelers. They are also required
when running HA. Legacy API and service session are now deprecated and will be removed in the OpenZiti v3.0.0 release.

Additional Features

• Controllers can now optionally bind APIs using an OpenZiti identity
• ziti edge login now supports the --network-identity flag to authenticate and establish connections through the Ziti overlay network
• ziti edge login now supports using a bearer token with --token for authentication. The token is expected to be
  provided as just the JWT, not with the "Bearer " prefix
• Identity configuration can now be loaded from files or environment variables for flexible deployment scenarios
• Identities can now be provisioned just-in-time through OIDC/JWT token-based enrollment
• Multiple model updates can now be in-flight at the same time, improving clustering performance
• Authentication-related model updates can now be non-blocking and even dropped if the system is too busy
• Routers now provide more error context to SDKs for terminator errors, enabling better retry behavior
• New proxy.v1 config type for dynamic service proxies (originally released in 1.7.0)
• New alert event type for surfacing operational issues to network operators - Beta (originally released in 1.7.0)
• New Azure Service Bus event sink for streaming controller events, contributed by @ffaraone (originally released in 1.7.0)
• Bundled ZAC upgraded to 4.0
• Build updated to Go 1.25
• CLI cleaned up to remove calls to os.Exit, making it more friendly for embedding
• Controller Edge APIs now return WWW-Authenticate response headers on 401 Unauthorized responses, giving clients actionable information about which auth methods are accepted and what went wrong
• HA Controllers can be marked as 'preferredLeader' via config
• Dynamic cost range for smart routing expanded beyond the previous 64K limit
• Dial failures now return the circuit ID and error information for easier debugging
• Router-to-controller control channels now support multiple underlays with priority-based message routing
• The dialing identity's ID and name are now forwarded to the hosting SDK
• Controllers can now dial routers to establish control channels, enabling connectivity when routers are behind firewalls (Beta)

Basic Permission System (BETA)

Added a basic permission system that allows more control over identity access to controller management API operations.
This replaces the previous binary admin/non-admin model with a more flexible permission system.

NOTE: This feature is in BETA, primarily so we can get feedback on which permissions make sense. The implementation is unlikely to change
but the set of exposed permissions may grow, shrink or change based on user feedback.

Permission Model

The permission system supports three levels of authorization:

1. Global Permissions: System-wide access levels

   • admin - Full access to all operations. This is still controlled by the isAdmin flag on identity
   • admin_readonly - Read-only access to all resources except debugging facilities inspect and validate

2. Entity-Level Permissions: Full CRUD access to specific entity types

   • Granting an entity-level permission (e.g., service) provides complete create, read, update, and delete access for that entity type

3. Action-Level Permissions: Specific operation access on entity types

   • Fine-grained control using the pattern <entity>.<action> (e.g., service.read, identity.update)
   • Supports create, `r...

v1.6.13

Release 1.6.13

What's New

• Bug fixes and dependency updates

Component Updates and Bug Fixes

• github.com/openziti/metrics: v1.4.2 -> v1.4.3

  • Issue #56 - underlying resources of reference counted meters are not cleaned up when reference count hits zero

• github.com/openziti/ziti: v1.6.12 -> v1.6.13

v1.5.12

Release 1.5.12

What's New

Update libraries and build with the latest Go version.

v2.0.0-pre1

Release 2.0.0

What's New

This is the next major version release of OpenZiti, following the 1.0 release in April 2024.
Of particular note is that HA controllers are now considered ready for general use.
This release also introduces a new permissions model, OIDC/JWT token-based enrollment,
clustering performance improvements, and a number of other features and fixes. Because
some of these changes are not backwards compatible with older routers, we're marking this
as a major version bump.

HA Controllers are now considered ready for general use

This is a pretty big milestone and marks the completion of work that's been ongoing for a couple of years.
The HA work has brought with it some notable changes. Authentication now uses JWTs by default. Using JWTs
means the controllers don't need to store session and propagate them to the routers. This removes a bottleneck
from the network and allows the load to be more easily distributed among controllers and routers.

To support distributed authentication, the routers now get a bespoke version of the data model. In addition
to enabling distributed authentication this will allow us to remove the need for service polling and further
reduce the load on controllers in the future.

Router Compatibility

Related to the JWT work, routers with version 2.+ will only work with controllers that are version 2.+. This means
to upgrade your network, controllers should be upgraded first. Routers can then be upgraded individually.

2.x routers should still work fine with older router versions.

We try very hard to avoid breaking changes like this, but sometimes the engineering trade-offs lead there. This change
was first made in the 1.7 release. That release has not been marked stable, and we have no plans to do so, because
of the backwards incompatibility.

New Permissions Model (BETA)

As one feature goes out of beta, another arrives into beta. This release introduces a new permissions system
for more fine grained control to the management API. It's not expected to change, but may do so based on feedback
from users.

Updated Release Process

We have moved to creating -preN releases for major and minor versions. This way we can put out release candidates,
or feature previews and put them through internal testing and let interested folks from the community try them out.
Then, when we're ready, we can run the full validation suite against the last pre-release and retag it.

Patch releases won't have -preN and should contain only high priority bug fixes.

Deprecation Cleanup

Since we already have a breaking change, we're removing some other backwards compatibility code.

• Controller managed links
  • Router managed links were introduced in v0.30.0.
  • If you're upgrading from an older versions, you'll want to upgrade to the latest 1.x release before jumping to 2.x
  • Github tracking issue: #3512
• ziti edge create identity <type>
  • Identity types other than router were removed in v0.30.2
  • The type can be dropped from the CLI command
  • Github tracking issue: #3532
• Terminator create/update/delete events
  • These have been superseded by entity change events, which also have create/update/delete events for terminators
  • Entity change events were introduced in v0.28.0
  • Github tracking issue: #3531
• xgress_edge_tunnel v1
  • This is the first implementation of the tunneler in edge-router code (ER/T) which used legacy api sessions and services
  • The v2 version uses the router data model and was introduced in v0.30.x
  • Github tracking issue: #3516

Legacy Session Deprecation

OIDC sessions are now preferred. They are the default, or will become the default for SDKs and tunnelers. They are also required
when running HA. Legacy API and service session are now deprecated and will be removed in the OpenZiti v3.0.0 release.

Additional Features

• Controllers can now optionally bind APIs using an OpenZiti identity
• ziti edge login now supports the --network-identity flag to authenticate and establish connections through the Ziti overlay network
• ziti edge login now supports using a bearer token with --token for authentication. The token is expected to be
  provided as just the JWT, not with the "Bearer " prefix
• Identity configuration can now be loaded from files or environment variables for flexible deployment scenarios
• Identities can now be provisioned just-in-time through OIDC/JWT token-based enrollment
• Multiple model updates can now be in-flight at the same time, improving clustering performance
• Authentication-related model updates can now be non-blocking and even dropped if the system is too busy
• Routers now provide more error context to SDKs for terminator errors, enabling better retry behavior
• New proxy.v1 config type for dynamic service proxies (originally released in 1.7.0)
• New alert event type for surfacing operational issues to network operators - Beta (originally released in 1.7.0)
• New Azure Service Bus event sink for streaming controller events, contributed by @ffaraone (originally released in 1.7.0)
• Bundled ZAC upgraded to 4.0
• Build updated to Go 1.25
• CLI cleaned up to remove calls to os.Exit, making it more friendly for embedding
• Controller Edge APIs now return WWW-Authenticate response headers on 401 Unauthorized responses, giving clients actionable information about which auth methods are accepted and what went wrong
• HA Controllers can be marked as 'preferredLeader' via config
• Dynamic cost range for smart routing expanded beyond the previous 64K limit
• Dial failures now return the circuit ID and error information for easier debugging
• Router-to-controller control channels now support multiple underlays with priority-based message routing
• The dialing identity's ID and name are now forwarded to the hosting SDK

Basic Permission System (BETA)

Added a basic permission system that allows more control over identity access to controller management API operations.
This replaces the previous binary admin/non-admin model with a more flexible permission system.

NOTE: This feature is in BETA, primarily so we can get feedback on which permissions make sense. The implementation is unlikely to change
but the set of exposed permissions may grow, shrink or change based on user feedback.

Permission Model

The permission system supports three levels of authorization:

1. Global Permissions: System-wide access levels

   • admin - Full access to all operations. This is still controlled by the isAdmin flag on identity
   • admin_readonly - Read-only access to all resources except debugging facilities inspect and validate

2. Entity-Level Permissions: Full CRUD access to specific entity types

   • Granting an entity-level permission (e.g., service) provides complete create, read, update, and delete access for that entity type

3. Action-Level Permissions: Specific operation access on entity types

   • Fine-grained control using the pattern <entity>.<action> (e.g., service.read, identity.update)
   • Supports create, read, update, and delete actions per entity type

Supported Entity Permissions

The following entity-level permissions are available:

• auth-policy - Authentication policy management
• ca - Certificate Authority management
• config - Configuration management
• config-type - Configuration type management
• edge-router-policy - Edge router policy management
• enrollment - Enrollment management
• external-jwt-signer - External JWT signer management
• identity - Identity management
• posture-check - Posture check management
• router - Edge and transit router management
• service - Service management
• service-policy - Service policy management
• service-edge-router-policy - Service edge router policy management
• terminator - Terminator management
• ops - Operational resources (API sessions, sessions, circuits, links, inspect and validate)

Permission Assignment

Permissions are assigned to identities via the permissions field in the identity resource. Multiple permissions can be granted to a single identity, and permissions are additive.

Cross-Entity Operations

Listing related entities through an entity's endpoints requires appropriate permissions for the related entity type. For example:

• Listing services for a service-policy requires service.read permission
• Listing identities for an edge-router-policy requires identity.read permission
• Listing configs for a service requires config.read permission

NOTE:
More permissions than expected may be required when performing actions through the CLI or ZAC. Take for example, when an identity
has config.create and is attempting to create a new config. The CLI may fail if the identity doesn't have config-type.read
as well because it will need to look up the config type id that corresponds to the given config type name.

Similar cross entity read permissions may be required when creating services.

Admin Protection

Non-admin identities cannot:

• Create identities with the isAdmin flag
• Create identities with any permissions granted
• Modify admin-related fields on existing identities
• Update or delete admin identities
• Grant permissions to identities

These protections ensure that privilege escalation is prevented and admin access remains controlled.

Binding Controller APIs With Identity

Controller APIs can now be bound to an OpenZiti overlay network identity, allowing secure communication through
the Ziti network. This is useful for scenarios where you want to expose controller APIs only through the overlay
network rather than on a standard network interface.

Configuration Structure

A standard `bindPo...

v1.5.11

Release 1.5.11

What's New

Update libraries and build with the latest Go version.