diff --git a/docusaurus/docs/_cli-login.md b/docusaurus/docs/_cli-login.md index 1f425b98d..bca22453e 100644 --- a/docusaurus/docs/_cli-login.md +++ b/docusaurus/docs/_cli-login.md @@ -1,13 +1,13 @@
-The `ziti` CLI will help you get a session from the controller's management API. You will be prompted to trust any new server certificates. Your session cache and trust store are managed by the CLI in your home directory. +The `ziti` CLI will help you get an API Session from the controller's management API. You will be prompted to trust any new server certificates. Your login token cache and trust store are managed by the CLI in your home directory. -```bash +```text # implies https://localhost:1280 ziti edge login -u admin -p admin ``` -```bash +```text # implies https:// ziti edge login ziti.example.com:8441 -u admin -p admin ``` diff --git a/docusaurus/docs/guides/data-flow-explainer.md b/docusaurus/docs/guides/data-flow-explainer.md index 4d44f8a51..7584faa11 100644 --- a/docusaurus/docs/guides/data-flow-explainer.md +++ b/docusaurus/docs/guides/data-flow-explainer.md @@ -1,11 +1,8 @@ --- title: Data Flow Explainer -sidebar_label: Data Flow Explainer sidebar_position: 30 --- -# Data Flow Explainer - This explainer walks through how data flow is established in an OpenZiti network. ## Baseline @@ -19,9 +16,9 @@ It has the following components: * An OpenZiti controller * Two OpenZiti routers that are available via the public internet * Two private networks, each containing a router and an application server - * The application servers are serving up the same application. There are multiple servers, so - that load can be spread across them. They are in separate regions to ensure that the - application can still be accessed, even if a datacenter becomes unavailable. + * The application servers are serving up the same application. There are multiple servers, so + that load can be spread across them. They are in separate regions to ensure that the + application can still be accessed, even if a datacenter becomes unavailable. * An SDK application which wants to access the application hosted by the application servers ## Control Channels @@ -82,7 +79,7 @@ When an SDK wants to connect to an OpenZiti hosted service, it will initiate the of events: 1. Authenticate to the controller -2. Create a Service Session for the desired service +2. Create a Session for the desired service 3. Connect to one or more edge routers 4. Send a Dial request to the selected edge router 5. The edge router will send a create circuit request to the controller @@ -105,18 +102,18 @@ An API Session can be extended, so a single API Session can generally be used fo the application. A new API Session may be required if the application is unable to reach the controller for an extended period of time. -### Create Service Session +### Create Session -The SDK must now create a Service Session. When creating a Service Session, the controller will +The SDK must now create a Session. When creating a Session, the controller will verify that the identity used by the SDK has permission to access the service. The controller will also see which edge routers can be used to access the session. The set of edge routers will be -returned along with the Service Session token. +returned along with the Session token. ![image](/img/data-flow/client-session.png) ### Connect to Edge Routers -The returned Service Session contains the edge routers that can be used for this service along with +The returned Session contains the edge routers that can be used for this service along with the address or addresses that each router is listening on for SDK connections. The SDK will connect to the edge routers and use whichever one connects the fastest. The edge router connections are not per-service, but will be shared by all services. If the connections are already made, the SDK will @@ -131,7 +128,7 @@ routers will be notified and connections associated with that API Session will b ### Dial the Service The SDK will pick an edge router and send it a Dial request for desired service along with the -Service Session token. The edge router selected is known as the initiating router. The edge router +Session token. The edge router selected is known as the initiating router. The edge router will translate this into a 'create circuit' request to the controller. The controller will select a path and will message the routers in the path, so they can update their routing tables and/or make connections to application servers as necessary. @@ -159,4 +156,3 @@ controller notifies the initiating router and data can now flow between the SDK server. ![image](/img/data-flow/circuit.png) - diff --git a/docusaurus/docs/learn/core-concepts/clients/process-sequences/ServiceDial.md b/docusaurus/docs/learn/core-concepts/clients/process-sequences/ServiceDial.md index 07852a98a..dcf3d97eb 100644 --- a/docusaurus/docs/learn/core-concepts/clients/process-sequences/ServiceDial.md +++ b/docusaurus/docs/learn/core-concepts/clients/process-sequences/ServiceDial.md @@ -19,7 +19,7 @@ Application Client ->Ziti SDK : TCP Connection (3 way handshake) note over Ziti SDK : Edge Router Selection Ziti SDK ->Controller : Dial Request -Ziti SDK -> Controller :Initiating Edge Router\nEdge Session Token\nService ID\nDial Options +Ziti SDK -> Controller :Initiating Edge Router's\nSession Token\nService ID\nDial Options diff --git a/docusaurus/docs/learn/core-concepts/metrics/15-available-metrics.md b/docusaurus/docs/learn/core-concepts/metrics/15-available-metrics.md index d57d0e42a..a0e18e0f0 100644 --- a/docusaurus/docs/learn/core-concepts/metrics/15-available-metrics.md +++ b/docusaurus/docs/learn/core-concepts/metrics/15-available-metrics.md @@ -5,7 +5,7 @@ Metrics are reported to the log files, locale in /var/log/ziti by default. Ther | Metric | Type | Source | Description| |------------------------|-----------|------------|-----------------------------------------------------------------------------------------------------| |api-session.create | Histogram | controller | Time to create api sessions| -|api.session.enforcer.run | Timer | controller | How long it takes the api session policy enforcer to run| +|api.session.enforcer.run | Timer | controller | How long it takes the API Session policy enforcer to run| |bolt.open_read_txs | Gauge | controller | Current number of open bbolt read transactions| |ctrl.latency | Histogram | controller | Per control channel latency| |ctrl.queue_time | Histogram | controller | Per control channel queue time (between send and write to wire)| @@ -15,8 +15,8 @@ Metrics are reported to the log files, locale in /var/log/ziti by default. Ther |ctrl.tx.bytesrate | Meter | controller | Per control channel send data rate| |ctrl.tx.msgrate | Meter | controller | Per control channel send message rate| |ctrl.tx.msgsize | Histogram | controller | Per control channel send messsage size distribution| -|edge.invalid_api_tokens | Meter | router | Number of invalid api session token encountered| -|edge.invalid_api_tokens_during_sync | Meter | router | Number of invalid api session token encountered while a sync is in progress| +|edge.invalid_api_tokens | Meter | router | Number of invalid API Session token encountered| +|edge.invalid_api_tokens_during_sync | Meter | router | Number of invalid API Session token encountered while a sync is in progress| |egress.rx.bytesrate | Meter | router | Data rate of data received via xgress, originating from terminators. Per router.| |egress.rx.msgrate | Meter | router | Message rate of data received via xgress, originating from terminators. Per router.| |egress.rx.msgsize | Histogram | router | Message size distribution of data received via xgress, originating from terminators. Per router.| @@ -49,7 +49,7 @@ Metrics are reported to the log files, locale in /var/log/ziti by default. Ther |service.policy.enforcer.run | Timer | controller | How long it takes the service policy enforcer to run| |service.policy.enforcer.run.deletes | Meter | controller | How many sessions are deleted by the service policy enforcer| |services.list | Histogram | controller | Time to list services| -|session.create | Histogram | controller | Time to create a session| +|session.create | Histogram | controller | Time to create an API Session| |xgress.ack_duplicates | Meter | router | Number of duplicate acks received. Indicates over-eager retransmission| |xgress.ack_failures | Meter | router | Number of failures sending acks| |xgress.acks.queue_size | Gauge | router | Number of acks queued to send| diff --git a/docusaurus/docs/learn/core-concepts/metrics/50-grafana.md b/docusaurus/docs/learn/core-concepts/metrics/50-grafana.md index ebe02d53a..f8d39ba97 100644 --- a/docusaurus/docs/learn/core-concepts/metrics/50-grafana.md +++ b/docusaurus/docs/learn/core-concepts/metrics/50-grafana.md @@ -11,7 +11,7 @@ Grafana has a marvelous datasource type called [Infinity](https://grafana.com/gr ### Configure the datasource The configuration of the datasource is simple, but a little nonintuitive. -We set the name of the server, in this case our OpenZiti Network Controller, but no authentication. This seems odd for a secure network, but the datasource does not provide (at this level) the tools we need to interact with the authentication endpoint to receive an API session token. +We set the name of the server, in this case our OpenZiti Network Controller, but no authentication. This seems odd for a secure network, but the datasource does not provide (at this level) the tools we need to interact with the authentication endpoint to receive an API Session token. ![Infinity datasource authentication configuration](/img/Infinity_noAuth.png) @@ -33,7 +33,7 @@ In the network section, we can provide the CA certificate for the controller, or ![Variable query URL Options configuration](/img/bearer_token_variable_url_options.png) -- In the Parsing options and Result fields, enter the below. The Infinity datasource provides JSONPath functionality, which is used here to extract the API session token for use in the panel queries. +- In the Parsing options and Result fields, enter the below. The Infinity datasource provides JSONPath functionality, which is used here to extract the API Session token for use in the panel queries. ![Variable parsing options configuration](/img/bearer_token_variable_parsing.png) diff --git a/docusaurus/docs/learn/core-concepts/security/SessionsAndConnections.md b/docusaurus/docs/learn/core-concepts/security/SessionsAndConnections.md index 780792ae0..3ee063f5f 100644 --- a/docusaurus/docs/learn/core-concepts/security/SessionsAndConnections.md +++ b/docusaurus/docs/learn/core-concepts/security/SessionsAndConnections.md @@ -31,11 +31,11 @@ end par Edge Control Plane SDK 1 ->> Network Controller: and - SDK 2 ->>Network Controller: Edge Session (per service) + SDK 2 ->>Network Controller: Session (per service) and - Edge Router 1 ->> Network Controller: Edge Session (per service) + Edge Router 1 ->> Network Controller: Session (per service) and - Edge Router 2 ->> Network Controller: Edge Session (per service) + Edge Router 2 ->> Network Controller: Session (per service) end par Data Plane (TCP) @@ -56,7 +56,7 @@ Edge Router 1 ->> Edge Router 2: Circuit ## Control Plane 1. The API Session is the first and primary session between and endpoint and the OpenZiti network instance. This session is created during attachment, after validating the certificates in both directions, and the endpoint name. This makes the endpoint present on the network, and all endpoints and routers have API sessions to the Controller(s) -2. The Edge Session is created with the API session authorization, and is specific to each service configured for the endpoint. The edge session object holds information such as the service policies, parent API session, service ID, and other information the endpoint and network require to properly service each given service. +2. The Session is created with the API Session authorization, and is specific to each service configured for the endpoint. The Session object holds information such as the service policies, parent API Session, service ID, and other information the endpoint and network require to properly service each given service. 3. Channels are formed between the endpoint and each Edge Router available and within the policies. These channels are monitored for latency to select best path, and are the control connections for incoming connections for hosted services. 4. Links connect Edge Routers logically. Edge Routers can advertise a listener socket, which is distributed during client initialization to other Edge Routers. All Edge Routers will attach to all others in a mesh, provided the policy dictates/allows it. Each pair of routers will have one link per link type (TLS, WSS, etc.) Links are a split connection, having both control plane and data plane messaging. diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/60-identities.md b/docusaurus/docs/learn/core-concepts/security/authentication/60-identities.md index 8f2c1cfa7..d719295fe 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/60-identities.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/60-identities.md @@ -175,4 +175,4 @@ It does not remove entities are that re-usable between Identities: - [Edge Router Policies](/learn/core-concepts/security/authorization/policies/overview.mdx) Deleting an Identity immediately removes it and all current and future access it would have to a Ziti Network and its -Services. \ No newline at end of file +Services. diff --git a/docusaurus/docs/learn/core-concepts/security/authorization/policies/overview.mdx b/docusaurus/docs/learn/core-concepts/security/authorization/policies/overview.mdx index 75ab785ad..fe79adf89 100644 --- a/docusaurus/docs/learn/core-concepts/security/authorization/policies/overview.mdx +++ b/docusaurus/docs/learn/core-concepts/security/authorization/policies/overview.mdx @@ -101,8 +101,8 @@ in the policy. All Ziti policies work the same way. and service must have at least one on-line edge router in common in order for a connection to be made. -When an identity is trying to establish a session to use or host a service the Ziti -controller will verify that they access via service policy. Once the session is +When an identity is trying to establish an API Session to use or host a service, the Ziti +controller will verify that they access via service policy. Once the API Session is established, the controller will return a list of edge routers that the identity can use to connect to that service. The list will be all edge routers which **both** the identity and service have access to. It is possible that an identity may have diff --git a/docusaurus/docs/learn/core-concepts/security/connection-security.md b/docusaurus/docs/learn/core-concepts/security/connection-security.md index d8ea3fdb9..abad89aaa 100644 --- a/docusaurus/docs/learn/core-concepts/security/connection-security.md +++ b/docusaurus/docs/learn/core-concepts/security/connection-security.md @@ -36,7 +36,7 @@ the mesh. Controller APIs provide ways for clients (SDKs or otherwise) to interact with a network. The [Edge Management API](/reference/developer/api/02-edge-management-reference.mdx) is used for configuration and maintenance. The [Edge Client API](/reference/developer/api/01-edge-client-reference.mdx) -is used to allow clients to authenticate, discover services, request service [Sessions](sessions.md#session), +is used to allow clients to authenticate, discover services, request [Sessions](sessions.md#session), discover Edge Routers, and to perform basic self-maintenance. Access to the APIs requires [authentication](authentication/auth.md) which results in an [API Session](authentication/auth.md#api-sessions) @@ -67,9 +67,9 @@ establish a `service` connection of either type the following is required: - a [Session](sessions.md#session) for the target service and intent (dial/bind) [Sessions](sessions.md#session) are issued by the controller's Edge Client API. A valid [Sessions](sessions.md#session) token -must be included with dial and bind requests. Edge Routers validate Session tokens continuously. If valid, the Edge +must be included with dial and bind requests. Edge Routers validate API Session tokens continuously. If valid, the Edge Router will facilitate the connecting the client to a service or registering the client as a host. Should a [Session](sessions.md#session) become invalid at any point, any existing `service` connection that -was established using the invalidated session will be terminated. Attempts to re-establish connection with the -invalidated [Session](sessions.md#session) will be refused. \ No newline at end of file +was established using the invalidated Session will be terminated. Attempts to re-establish connection with the +invalidated [Session](sessions.md#session) will be refused. diff --git a/docusaurus/docs/learn/core-concepts/security/sessions.md b/docusaurus/docs/learn/core-concepts/security/sessions.md index 73ad53d8b..8a958c4f1 100644 --- a/docusaurus/docs/learn/core-concepts/security/sessions.md +++ b/docusaurus/docs/learn/core-concepts/security/sessions.md @@ -1,5 +1,7 @@ # Session Types +Ziti has API Session and Session types. + ## API Session API Sessions represent a client that is either partially or fully authenticated as a specific Ziti Identity. @@ -193,11 +195,11 @@ A client may terminate its own API Session at any time by calling: `DELETE /edge ## Session -Session represent access to a specific service for dialing or binding. They are scoped to the +A Session represents access to a specific service for dialing or binding. They are scoped to the [API Session](#api-session) that was used to create them. They are requested from the controller by a client through the Edge Client API. The result of that request is a security token representing the Session and a list of Edge Routers that the client may use to dial or bind the target service through. Sessions are removed when the parent [API Session](authentication/auth.md#api-sessions) is removed, -[policies](authorization/policies/overview.mdx) are changed to deny access, or when [Posture Checks](authorization/posture-checks.md) enter an -invalid state for the target service. \ No newline at end of file +[policies](authorization/policies/overview.mdx) are changed to deny access, or when [Posture +Checks](authorization/posture-checks.md) enter an invalid state for the target service. diff --git a/docusaurus/docs/learn/core-concepts/services/overview.mdx b/docusaurus/docs/learn/core-concepts/services/overview.mdx index 7cb412210..bd2bf6cfc 100644 --- a/docusaurus/docs/learn/core-concepts/services/overview.mdx +++ b/docusaurus/docs/learn/core-concepts/services/overview.mdx @@ -12,11 +12,13 @@ A service is defined by the following components: * **Authorization** - For a details on controlling access to services, see [Policies](/docs/learn/core-concepts/security/authorization/policies/overview). ## Service Name + Ziti services must have names that are unique to their Ziti installation. Service names are how clients address services in order to consume them. Services which are provided by applications with Ziti embedded also use the service name to indicate which service is being provided. Services defined on a Ziti Network have an almost limitless "namespace" available for identifying services. A Ziti service is to be defined by a name and this name is registered with the Ziti Controller. Once declared, services can then be addressed directly by name from Ziti-aware clients. This means there are effectively a **limitless** number names available with no need for global DNS registration. The names assigned are unique to a Ziti Network and the application developer has total control over service names. ## Service Termination + In Ziti, service termination refers to how a network traffic going over Ziti reaches the application (or application cluster) which is actually providing a service. There are a few basic ways in which a service can be terminated at an application. There are some trade-offs to consider for each type of termination. @@ -26,6 +28,7 @@ There are some trade-offs to consider for each type of termination. 1. How accessible to non-zero trust clients do you want your server application to be? With the proper configuration applications can be fully 'dark', meaning they do not listen for connections. ### SDK Embedded Applications + The server application can embed the Ziti Edge SDK. The application will have an enrolled identity and provisioned certificates. This has several advantages: 1. Connections between the application and Ziti will be secured using certificates. This enables true zero trust and end-to-end encrypted connections between SDK based clients and SDK based servers. @@ -35,6 +38,7 @@ The server application can embed the Ziti Edge SDK. The application will have an The downside to this approach, specifically for existing applications, is that the application must be refactored to use a Ziti Edge SDK. Depending on language and frameworks used, the effort required can range from updating a few lines of code to writing a new SDK from scratch for a language that's not supported yet. ### Proxied Applications + For applications where it doesn't make sense to embed the SDK a Ziti SDK based proxy can provide access to the application. Often the proxy may take the form of a sidecar and be co-located with the application. This minimizes the attack surface. There are a few things to note about this approach. 1. The application will not be completely dark. It must accept connections from wherever the proxy is located. The proxy may be co-located with the application, so the attack surface area may be tiny. However, tiny is still bigger than zero. @@ -44,6 +48,7 @@ For applications where it doesn't make sense to embed the SDK a Ziti SDK based p Services which use proxies for server side termination may require extra configuration, so that the proxying application knows how to connect to the server application. Service configurations are discussed more below. ### Ziti Router Terminated Services + Routers also have the ability to connect to applications providing services. This approach has its own advantages and disadvantages. 1. Like the proxy approach, the application cannot be completely dark. The application must be reachable from the Ziti router. @@ -58,6 +63,7 @@ Routers also have the ability to connect to applications providing services. Thi | Ziti Router | No | No | No. If desired, end-to-end must be done externally | No. Can be relatively locked down, though. | ### Terminators + Terminators represent a way to connect to a specific server application for a specific service. For an SDK based server (whether embedded or proxied), these are created automatically as the application connects and removed when the application disconnects. @@ -71,9 +77,11 @@ For router terminated services they must be created manually. When creating a te 1. Example: `tcp:localhost:5432` ## Availability and Scaling + Services can be made highly available and/or horizontally scalable. There are two kinds of availability that server applications need to concern themselves with. -### Router HA/Scaling +### Router HA/Scaling + The first is allowing multiple routers to connect to a single application. **Multiple Routers** @@ -83,6 +91,7 @@ The first is allowing multiple routers to connect to a single application. This ensures that the application will still be able to service requests even if a router fails or there is network partition separating a router and server application. It also will help ensure that the router layer doesn't become a bottleneck, as more routers can be added as necessary to scale out connectivity. Finally, it provides multiple network paths to the application. This gives smart routing more to choose optimal routes from as network conditions change. ### Application HA/Scaling + The second is application availability and/or scalability. There will often be multiple instances of a service application running, either for failover or in a load balanced deployment. **Failover Deployment** @@ -94,52 +103,62 @@ The second is application availability and/or scalability. There will often be m ![image](/img/horizontal-scale.png) ### Xt -All types of availability and scalability involve multiple terminators. What distinguishes an HA failover setup from a load-balanced horizontal scale setup is how new sessions are assigned to terminators. For failover, we want sessions to always go to the same service instance. For horizontal scale, we want to load balance sessions across available instances. + +All types of availability and scalability involve multiple terminators. What distinguishes an HA failover setup from a load-balanced horizontal scale setup is how new Sessions are assigned to terminators. For failover, we want Sessions to always go to the same service instance. For horizontal scale, we want to load balance Sessions across available instances. The fabric contains a framework called Xt (eXtensible Terminators) which allows defining terminator strategies and defines how terminator strategies and external components integrate with smart routing. The general flow of terminator selection goes as follows: - 1. A client requests a new session for a service - 1. Smart routing finds all the active terminators for the session (active meaning the terminator's router is connected) + 1. A client requests a new Session + 1. Smart routing finds all the active terminators for the Session (active meaning the terminator's router is connected) 1. Smart routing calculates a cost for each terminator then hands the service's terminator strategy a list of terminators and their costs ranked from lowest to highest 1. The strategy returns the terminator that should be used - 1. A new session is created using that path. + 1. A new Session is created using that path. Strategies will often work by adjusting terminator costs. The selection algorithm then simply returns the lowest cost option presented by smart routing. #### Costs + There are a number of elements which feed the smart routing cost algorithm. ##### Route Cost + The cost of the route from the initiating route to the terminator router will be included in the terminator cost. This cost may be influenced by things such as link latencies and user determined link costs. ##### Static Cost + Each terminator has a static cost which can be set or updated when the terminator is created. SDK applications can set the terminator cost when they invoke the Listen operation. #### Precedence + Each terminator has a precedence. There are three precedence levels: `required`, `default` and `failed`. -Smart routing will always rank terminators with higher precedence levels higher than terminators with lower precedence levers. So required terminators will always be first, default second and failed third. Precedence levels can be used to implement HA. The primary will be marked as required and the secondary as default. When the primary is determined to be down, either by some internal or external set of heuristics, it will be marked as Failed and new sessions will go to the secondary. When the primary recovers it can be bumped back up to Required. +Smart routing will always rank terminators with higher precedence levels higher than terminators with lower precedence levers. So required terminators will always be first, default second and failed third. Precedence levels can be used to implement HA. The primary will be marked as required and the secondary as default. When the primary is determined to be down, either by some internal or external set of heuristics, it will be marked as Failed and new Sessions will go to the secondary. When the primary recovers it can be bumped back up to Required. ##### Dynamic Cost -Each terminator also has a dynamic cost that will move a terminator up and down relative to its precedence. This cost can be driven by strategies or by external components. A strategy might use number of active of open sessions or dial successes and failures to drive the dynamic cost. + +Each terminator also has a dynamic cost that will move a terminator up and down relative to its precedence. This cost can be driven by strategies or by external components. A strategy might use number of active of open Sessions or dial successes and failures to drive the dynamic cost. ##### Effective Cost Each terminator has an associated precedence and dynamic cost. This can be reduced to a single cost. The cost algorithm ensures terminators at different precedence levels do not overlap. So a terminator which is marked failed, with dynamic cost 0, will always have a higher calculated cost than a terminator with default precedence and maximum value for dynamic cost. #### Strategies + The fabric currently provides four strategy implementations. ##### `smartrouting` + This is the default strategy. It always uses the lowest cost terminator. It drives costs as follows: - * Cost is proportional to number of open sessions + * Cost is proportional to number of open Sessions * Dial failures drive the cost up * Dial successes drive the cost down, but only as much as they were previously driven up by failures ##### `weighted` + This strategy drives costs in the same way as the `smartrouting` strategy. However instead of always picking the lowest cost terminator it does a weighted random selection across all terminators of the highest precedence. If a terminator has double the cost of another terminator it should get picked approximately half as often. ##### `random` + This strategy does not change terminator weights. It does simple random selection across all terminators of the highest precedence. diff --git a/docusaurus/docs/reference/30-configuration/controller.md b/docusaurus/docs/reference/30-configuration/controller.md index 33147c020..7cca93278 100644 --- a/docusaurus/docs/reference/30-configuration/controller.md +++ b/docusaurus/docs/reference/30-configuration/controller.md @@ -256,8 +256,8 @@ omitted, it will not be output. The list of valid event types and their options - `edge.entityCounts` - (optional) Edge entity counts (API Sessions, sessions, routers, etc.) - `interval` - (optional) the time interval to generate entity count events on (e.g. "5s", " 5000ms", "1h") -- `edge.sessions` - (optional) Edge Session events - - `include` - (optional) a string or array of strings that specify which session events to +- `edge.sessions` - (optional) Session events + - `include` - (optional) a string or array of strings that specify which Session events to include ("created" and/or "deleted") - `fabric.circuits` - (optional) Fabric circuit events diff --git a/docusaurus/docs/reference/deployments/02-router/01-deployment.md b/docusaurus/docs/reference/deployments/02-router/01-deployment.md index 0d774c55b..e453dc15c 100644 --- a/docusaurus/docs/reference/deployments/02-router/01-deployment.md +++ b/docusaurus/docs/reference/deployments/02-router/01-deployment.md @@ -10,7 +10,7 @@ import CliLogin from '../../../_cli-login.md' import CliLogFormats from '../../../_cli-log-levels-and-formats.md' The Ziti Router is the entry point for Ziti-based clients. It is responsible for authenticating incoming connections by -verifying the connecting client has a valid network session. It also routes traffic to whatever the +verifying the connecting client has a valid Session. It also routes traffic to whatever the destination is for the given service. In simple deployments can have a single router as is the case with the [Ziti Network Quickstart](/docs/learn/quickstarts/network/). diff --git a/docusaurus/docs/reference/glossary.md b/docusaurus/docs/reference/glossary.md index 63b5e5c6b..d80282e45 100644 --- a/docusaurus/docs/reference/glossary.md +++ b/docusaurus/docs/reference/glossary.md @@ -7,63 +7,80 @@ import SERPBrief from '../learn/core-concepts/security/authorization/policies/_s Here you will find a list of terms you may come across as you are using Ziti. -## Edge Router Policy +## [Edge Router Policy](/learn/core-concepts/security/authorization/policies/overview.mdx#edge-router-policies) + ## Network Overlay, Overlay + A Ziti network is implemented as an "overlay". A network overlay abstracts away the layers beneath it, providing a new set of abstractions for designing and implementing software and systems. Good programming abstractions allow developers to focus on the rules implemented by those abstractions without being concerned with the layers below the abstraction. Ziti's overlay allows developers to focus on connectivity between components without having to be concerned with low-level details of how that connectivity is managed. ## Service Definition + A service definition is used to "bind" a service to a specific underlay network expression, through one or more nodes on a Ziti overlay network. A service definition usually includes a terminating router (or routers) and one or more SDK or underlay network endpoints where the service can be reached. -## Service Edge Router Policy +## [Service Edge Router Policy](/learn/core-concepts/security/authorization/policies/overview.mdx#service-edge-router-policies) + -## Session -A session is an "instance" of a service on behalf of an initiating endpoint, which is connected to a terminating endpoint. A session has strong identity and security between the initiating endpoint, terminating endpoint, and throughout the links between. A session selects a specific set of routers to traverse between the endpoints, and that path can change dynamically due to network performance. +## [Session](/learn/core-concepts/security/sessions.md#session) + +A Session is an "instance" of a service on behalf of an initiating endpoint, which is connected to a terminating endpoint. A Session has strong identity and security between the initiating endpoint, terminating endpoint, and throughout the links between. A Session selects a specific set of routers to traverse between the endpoints, and that path can change dynamically due to network performance. ## Initiating Router, Terminating Router -An initiating router is the router which initiates a request for a session on behalf of a connected endpoint. A terminating router is the router which provides access to the service associated with the session request. Every session links an initiating endpoint (through an initiating router), with a terminating endpoint (through a terminating router). + +An initiating router is the router which initiates a request for a Session on behalf of a connected endpoint. A terminating router is the router which provides access to the service associated with the Session request. Every Session links an initiating endpoint (through an initiating router), with a terminating endpoint (through a terminating router). ## Initiating Endpoint, Terminating Endpoint + See "initiating router" and "terminating router" above. The initiating endpoint is the endpoint responsible for requesting connectivity to a service. The terminating endpoint is the endpoint that provides the service. -## Path -The path is the set of Ziti Routers traversed by a session from an initiating router to a terminating router. Ziti aggressively optimizes the path for throughput and reliability, and so it may change during the session. +## [Path](/guides/data-flow-explainer.md) + +The path is the set of Ziti Routers traversed by a Session from an initiating router to a terminating router. Ziti aggressively optimizes the path for throughput and reliability, and so it may change during the Session. ## Underlay We refer to lower-level network concerns as "underlay". IP networking would be an example of an underlay concept. ## Xgress (Xctrl, Xmgmt), Ziti Fabric SDK + Xgress is a set of extension components for the Ziti fabric, which enable overlay applications to participate in the overlay network. Xgress focuses on extending the data plane, providing interfaces for creating initiating and terminating endpoints. Xctrl and Xmgmt focus on extending the control and management planes of the fabric. Xgress is the core of the Ziti Fabric SDK. ## Ziti Controller, Controller + A Ziti Controller is a process that is installed on a host, which allows it to coordinate a Ziti network. The Ziti Controller is designed to be extensible through Ziti fabric extension mechanisms (Xctrl, Xmgmt), which means that it is capable of hosting extensions to the fabric control and management planes. ## Ziti Edge, Edge + The Ziti Edge implements the zero trust connectivity framework as an overlay application on top of the Ziti Fabric. The Ziti Edge provides connectivity implementations for a number of important endpoint types, including applications that embed Ziti connectivity through the Ziti Edge SDK. The Ziti Edge provides fallback connectivity solutions for non-Ziti applications using components like the Ziti tunnelers, and the Ziti proxy. ## Ziti Enabled Application + A Ziti Enabled Application is an application that embeds the Ziti Endpoint SDK, such that it can participate on a Ziti network to either access or host services. -## Ziti Endpoint SDK, Endpoint SDK, SDK +## [Ziti Endpoint SDK, Endpoint SDK, SDK](/reference/developer/sdk/index.mdx) + The Ziti Endpoint SDK provides software components that are designed to be embedded into customer applications so that they can participate natively in a Ziti network. The SDK targets golang, Swift, C, C#, and potentially other programming languages, allowing programs in those languages to work with idioms and concepts native to those environments. The SDK provides support for both accessing and hosting services that are available on a Ziti network. -## Ziti Fabric, Fabric +## [Ziti Fabric, Fabric](/learn/introduction/30-openziti-is-software.md#fabric) + The Ziti Fabric provides the core of the network overlay. The Ziti Fabric implements a routable mesh network, which can provide reliable connectivity between any two points on the network. The fabric provides software extension mechanisms that allow the overlay to be embedded into new overlay applications. The Ziti Edge is an example of an overlay application implemented on top of Ziti Fabric extension mechanisms (Xgress, Xctrl, Xmgmt). ## Ziti Network, Ziti + Ziti is a modern, programmable network overlay with associated edge components, for application-embedded, zero trust network connectivity, written by developers for developers. Ziti is NetFoundry's next-generation programmable networking product. Ziti is used to create Ziti Networks. ## Ziti Router, Router + A Ziti Router is a process that is installed on a host, which allows it to participate in a Ziti Fabric. The router is designed to be extensible through Ziti fabric extension mechanisms (Xgress), which means that it is capable of "hosting" overlay network applications like the Ziti Edge. -## Ziti Service, Service +## [Ziti Service, Service](/learn/core-concepts/services/overview.mdx) + A Ziti network is primarily concerned with providing access to "services". A service encapsulates the definition of any resource that could be accessed by a client on a traditional network. A Ziti Service is defined by a strong, extensible identity, rather than by an expression of an underlay concept. This means that services defined on a Ziti Network have @@ -71,13 +88,16 @@ an almost limitless "namespace" available for identifying services. A Ziti servi certificate, rather than by a DNS name or an IP address (underlay concepts). ## Ziti Service, Service - Hosted + Similar to a Ziti Service however the destination is not described as an IP address and port but rather it is expressed as a Ziti Identity. When used with a Ziti SDK it is possible to create a truly zero trust application. -## Ziti Tunneler, Tunneler +## [Ziti Tunneler, Tunneler](/reference/tunnelers/index.mdx) + A Ziti Tunneler provides connectivity for applications that are not Ziti enabled. Our tunneler implementations provide an underlay connectivity component (TUN, tproxy, etc.), and then use the Ziti Endpoint SDK such that they can bridge connectivity onto the Ziti network. ## Zitification, Zitified, Zitify + "Zitification", "Zitified", "Zitify" are words which the project has created to describe "embedding an OpenZiti SDK into a project". After an OpenZiti SDK is added to a project, it is said to be "zitified" (ziti-fied). The verb form of adding OpenZiti to -a project is called "zitify" (ziti-fy). A project which has had OpenZiti added to it, is often rerferred to as a "zitification" (ziti-fication). \ No newline at end of file +a project is called "zitify" (ziti-fy). A project which has had OpenZiti added to it, is often rerferred to as a "zitification" (ziti-fication).