Ziti Controller

The Ziti Controller is the process that coordinates a Ziti Networks. It is responsible for authenticating incoming connections from identities. It also authorizes access to services for any given identity. The Ziti Controller provides two RESTful APIs for other processes to interact with it. Take a look at the API doc page for more info.

Prerequisite - PKI

Public Key Infrastructure (PKI) is a complex topic. See the pki page for additional details about the sort of needs and considerations relevant to the Ziti Controller. You will need a correct PKI setup for Ziti to work. If you follow one of the quickstart guides, a full PKI will be generated for you. This is probably the best way to start out.

Sizing Guidelines

The Ziti Controller and Ziti Routers are still in the process of being stress tested. We recommend starting with a small scale deployment until key performance indicators start to hint that the server requires more resources. A Ziti Networks will have two important metrics: CPU and network capacity. Modest sized networks require minimal investments in infrastructure. Start with small machines and increase as needed.

Configuration

The Ziti Controller is configured using a yaml file. If you follow one of the quickstart guides a configuration file will be generated. You can also find a sample config file from the ziti repo.

Each section is annotated and should provide you enough information to modify a given setting. Most of the fields are straight-forward. The pki-related fields are the ones you will need to pay particular attention to. See the pki page for relevant information on pki settings.

Logging

The Ziti components log all output to standard output. Logging to standard out, instead of to configurable files, etc., is a "lighter" approach to logging that is more easily integrated into more different kinds of environments. Logging to files and implementing feautres like file rotation is a solved problem and not one that the Ziti components try to solve. Instead look to alternatives which are capable of watching standard out and aggregating the results for you. There are many solutions available to collect, aggregate and display logs. Search for and implement a solution that works for you and your needs.

Log Format

The output from Ziti components comes in three distinct styles. Choose the style of logging that is right for you.

  1. pfxlog - a human-readible format leveraging ascii escape codes to display colorized log level
  2. json - a machine-readible format targetting automated processes for log aggregation/searching
  3. text - a human-readible format using plain text (no ascii escape codes)

Log Levels

By default the Ziti components will log at the INFO level. This means that log messages INFO, WARNING, ERROR and FATAL will all be captured and output. Ziti components all support verbose logging by adding --verbose or -v to the command being executed. Verbose mode will add DEBUG log messages and as the name implies this log level is much more verbose. Often when debugging adding verbose mode will aid in identifying issues.