Release 1.5.14

What's New

Update libraries and build with the latest Go version.

Release 1.6.15

What's New

• Bug fixes and dependency updates

Component Updates and Bug Fixes

• github.com/openziti/ziti: v1.6.14 -> v1.6.15
  • Issue #3771 - [Backport-1.6] Adaptive rate limiter should use success rate rather than queue position
  • Issue #3770 - Update Token Requests Should Close Channel Connections If Invalid
  • Issue #3764 - [Backport-1.6] coalesce OIDC JWT revocations to reduce controller write pressure
  • Issue #3760 - [Backport-1.6] revocation build-up in db and rdm

Release 1.5.13

What's New

Update libraries and build with the latest Go version.

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)
• Refresh-token revocations are now batched and best-effort, removing the database/raft bottleneck on token refreshes
• ziti edge quickstart now always runs in HA mode. The ha subcommand has been removed. Use
  ziti edge quickstart join to add additional members to the cluster. Note: existing quickstart instances
  are not compatible with the new HA-only mode and will need to be recreated.
• The --clustered flag on ziti create config controller has been removed; the generated config is always
  cluster-ready. If you have scripts passing --clustered, remove it.

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 t...

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)
• Refresh-token revocations are now batched and best-effort, removing the database/raft bottleneck on token refreshes
• ziti edge quickstart now always runs in HA mode. The ha subcommand has been removed. Use
  ziti edge quickstart join to add additional members to the cluster. Note: existing quickstart instances
  are not compatible with the new HA-only mode and will need to be recreated.
• The --clustered flag on ziti create config controller has been removed; the generated config is always
  cluster-ready. If you have scripts passing --clustered, remove it.

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 t...

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)
• Refresh-token revocations are now batched and best-effort, removing the database/raft bottleneck on token refreshes
• ziti edge quickstart now always runs in HA mode. The ha subcommand has been removed. Use
  ziti edge quickstart join to add additional members to the cluster. Note: existing quickstart instances
  are not compatible with the new HA-only mode and will need to be recreated.
• The --clustered flag on ziti create config controller has been removed; the generated config is always
  cluster-ready. If you have scripts passing --clustered, remove it.

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 t...

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)
• Refresh-token revocations are now batched and best-effort, removing the database/raft bottleneck on token refreshes

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.

...

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)
• Refresh-token revocations are now batched and best-effort, removing the database/raft bottleneck on token refreshes

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.

...

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

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, ...