"Appliance" refers to the virtual or physical instance on which the system is running. Each appliance is a stateless, configurable machine that can operate as a Controller, Gateway, Connection Broker, Connector, Portal, LogServer, LogForwarder, Metrics Aggregator, or a combination of functions in a single appliance. All appliances use the AppGate ZTNA Linux build, which is derived from a customized version of Ubuntu and contains all necessary dependencies to perform any of the different functions.
The first appliance must be configured as a Controller and forms the beginning of what is referred to as the "Collective", or group of appliances. A unique Collective ID is generated at this time. This Controller will initially host the admin UI and hold the operational and system configuration data in an internal database.
From the admin UI it is possible to add additional appliances. Once they are deployed and registered, any configuration changes to that appliance are made automatically. However, all operational information is handled using tokens so no information relating to user access rights are passed in this way.
This section introduces the different appliance functions available in the AppGate ZTNA system.
Capabilities of the seven appliance functions
The Controller
The Controller is the central point of administration for AppGate ZTNA. A stateless appliance with an internal database, the Controller is used to store system configuration. The Controller has a number of roles:
the Certificate Authority for the system
responsible for creating and signing tokens that are used by the system for authentication, authorization, and Policy distribution
responsible for user authentication when the user logs in either through the Client or the Management Console
responsible for assigning Policies to the right users and creating the list of valid Entitlements for each user
responsible for assigning admin roles to administrators and enforcing admin privileges
The first appliance in the system must always be configured as a Controller. Additional HA Controllers may then be added to a Collective.
The Gateway
The Gateway is the enforcement point, responsible for controlling user access to protected resources. After seeding, it registers with the Controller and will then be listed for the Site to receive Client connections. Once registered, it runs as a stateless appliance and only needs to receive the token revocation list from the Controller. Even after a loss of connectivity to the Controller, it will continue to serve both existing and new connections for a period of 12 hours, after which user access will no longer be allowed through that Gateway.
The Gateway uses the Claims and Entitlement tokens from each user to manage firewall rules and provide real-time access control. User interactions allow the Gateway to elevate privilege levels on-demand. The DNS forwarder and name resolvers automatically resolve any firewall rules based on real-time information from DNS servers and Cloud APIs. After a user's access session has ended (e.g., their Entitlement token has been revoked or has expired), no data about the user, their Entitlements, claims, or firewall rules is retained.
A Gateway can be enabled on the same appliance as the Controller or on a separate appliance. Multiple Gateways can be deployed on a Site to improve performance and availability.
The Connection Broker
This feature is currently in Beta. For more information contact your AppGate representative. The Connection Broker is responsible for establishing a connection between the Client and the Gateway when the Gateway is behind network address translation (NAT) and cannot be reached directly by the Client.
The Connection Broker can serve one or multiple Sites, and there can be one or more Connection Brokers per Site.
All communications with the Connection Broker are protected by SPA when SPA-UDP-TCP is enabled. This ensures that the Connection Broker is invisible even though it’s exposed to the Internet.
The LogServer
AppGate ZTNA includes a built-in LogServer function using OpenSearch. The LogServer is an appliance that collects logs from the other members of the Collective, providing an audit trail of actions and user access. Only one LogServer can be deployed, therefore HA configuration is not supported. Its primary use case is to help customers during set up, configuration, evaluation, and during initial deployment. It is also suitable for use in smaller-scale production environments.
The LogServer is not included in the base appliance image, so when this is enabled the required image will be automatically downloaded from a public container registry. The Controller will check that access to this registry is available when you save the configuration.
For initial testing, the LogServer is often configured on a Controller appliance. But once testing is complete, it should not continue to co-habit as it will have a negative impact on the Controller's performance and reliability. The LogServer's operational limits for production environments are detailed in the System Logs section, where you will find more information about using a LogServer.
The LogServer and LogForwarder cannot co-exist in the same Collective.
The LogForwarder
LogForwarders can be configured for HA operation using two or more appliances. They can be deployed to export logs by Site to different destinations. Multiple export protocols can be specified at the same time including one for the ELK stack. This means that if there is an ongoing requirement to retain the ELK stack (effectively a copy of the LogServer) in an enterprise environment, then one can be deployed outside of the AppGate ZTNA Collective, and the logs can be forwarded there while also exporting the log data into an enterprise-class logging system.
See System Logs for more information about using a LogForwarder.
The LogForwarder and LogServer cannot co-exist in the same Collective.
The Connector
The Connector protects remote networks and/or groups of under-protected devices. The Connector (Advanced) has multiple configuration options, however by using the Connector (Express), only minimal configuration is required to allow users to connect to local resources. In a typical environment, a Connector would be deployed as a standalone appliance in a remote location such as in the Cloud or at a site office.
The Connector can be configured for HA operation if required.
For more detailed information there are separate sections for the Connector (Express) and the Connector (Advanced).
The Portal
AppGate ZTNA's Portal appliance provides zero-install, browser-based access to protected resources, with comparable security to the full Client. From the user's perspective, there is no need for any installation or set-up processes, as a modern browser is enough for secure access.
The Portal can be used in addition to, or instead of, the full Client. In this version it is recommended to be used to give zero-install secure access to a few internal resources for third party consultants. Future versions will be enhanced to provide secure access for remote offices or employee groups that only need access to web-based resources.
The Portal does not require any change to the protected resources/applications nor to their related networks, aside from new DNS records. One of the most important properties of the Portal is that secure access is provided without altering the domain name of the application being accessed, so it is transparent from both the end users and the applications points of view. Users access the protected resources in the usual way and are presented with the AppGate ZTNA Client user interface in their browser, when required.
See the Portal section for more information about deploying a Portal and how it works.
The Metrics Aggregator
The Metrics Aggregator provides a means of collecting, grouping by Site, and then exporting Prometheus metrics from the Collective. This avoids the need to configure the Prometheus exporter on each individual appliance and the need to configure firewalls to allow inbound access to each appliance in the Collective.
The Metrics Aggregator also monitors the collection of metrics, so if an appliance's metrics are not being collected it will report a warning.
See System monitoring and Logs for more information about Prometheus and the Metrics Aggregator.
The Prometheus Exporter and Metrics Aggregator cannot co-exist on the same appliance.
While not recommended, some deployments may require installation of third party add-ons for monitoring or reporting through Appliance Customization scripts.