什么是OpenZiti?
OpenZiti 是一个免费的开源项目,专注于将零信任网络原则直接引入任何应用程序。该项目提供了实施零信任覆盖网络所需的所有部分,并提供了将零信任集成到现有解决方案中所需的所有工具。OpenZiti项目认为,零信任的原则不应该止步于你的网络,这些想法应该存在于你的应用程序中。
OpenZiti 覆盖网络示例
在 OpenZiti 中,您会发现
- 由控制器、edge路由器和fabric路由器组成的零信任叠加网状网络
- 众多 SDK,可以轻松地将零信任原则直接嵌入到您的应用程序中
- 隧道应用程序,为那些您无法直接嵌入零信任的应用程序提供零信任访问
- 零信任原则,例如先授权后连接、持续授权、最低权限访问
OpenZiti 可以轻松地将零信任、可编程网络直接嵌入到您的应用程序中。使用 OpenZiti,您可以在任何互联网连接上拥有零信任、高性能的网络,而无需 VPN!
🏃♂️准备好部署您的第一个网络了吗?直接按照我们的快速入门指南进行操作!
组件
已部署的组件
控制器
控制器是网络的核心功能。控制器提供配置平面。它负责配置服务,并作为管理用户、设备和组成网络的节点使用的身份的中心点。最后但至关重要的是,控制器负责对网络中的每个连接进行身份验证和授权。
控制器必须配置公钥基础结构 (PKI)。配置的 PKI 用于在网络的任意两个部分之间创建安全、相互身份验证的 TLS (mTLS) 网络连接。控制器不提供自己的 PKI,但要使控制器签署证书签名请求 (CSR),控制器需要配置用于签名的密钥和证书。ziti pki
命令可以生成 PKI。
如果网络运营商有他们希望复用的现有 PKI,控制器还支持使用第三方 PKI。使用第三方 CA 会将获取和分发正确签名证书的负担推给网络运营商,但对于经验丰富的客户来说,这可能会使网络的整体管理更容易。
控制器使用基于 bbolt 的本地数据库来存储管理网络所需的信息。
控制器的 TLS 服务器使用 SNI 在有多个证书时选择正确的证书进行呈现。Ziti 客户端使用 ALPN 协商与控制平面 ( ziti-ctrl
) 或 REST API ( h2
, http/1.1
) 的连接。
路由器
路由器是网络的基本构建块。这些路由器负责安全可靠地将流量从一个网络节点传送到目的地。
Ziti路由器连接在一起,形成一个网状网络。此网格会持续受到延迟监控,并且在将流量路由到目的地时使用最快的路径。该监控还允许主动故障转移,以确保即使在节点发生故障的情况下也能保持可靠的网络连接。
路由器是客户端连接的网络入口点。路由器与控制器一起负责对客户端进行身份验证和授权。
边缘客户端
连接到网络需要边缘客户端。Edge 客户端设计用于处理brownfield和greenfield应用程序。
如果正在开发的解决方案包括开发新软件,Ziti SDK会针对各种语言和运行时,以提供快速、可靠和安全的连接。这些 SDK 提供了安全连接到网络所需的功能,并且旨在轻松集成到目标应用程序中。
在向现有解决方案添加安全连接时,OpenZiti提供了称为tunnelers隧道器的专用边缘客户端,这些客户端提供无缝,安全的连接,并且不需要对目标应用程序进行更改。
阅读更多关于客户端的信息
BrowZer
BrowZer 是一组可选组件,它们有助于在 Web 浏览器中引导信任,而无需客户端安装。这意味着无需在 Web 浏览器中安装扩展,也无需安装移动或桌面客户端(隧道器)之一!
它支持将零信任网络自动嵌入到 Web 应用程序中,从而将 Web 浏览器(例如 Chrome、Brave 或 Edge)转变为成熟的客户端。用户唯一需要的软件是他们每天使用的无处不在的浏览器。
同样值得注意的是,BrowZer 不会给 Web 应用程序开发人员带来任何负担,让他们首先检测或以其他方式对 Web 应用程序本身进行任何修改,以实现安全的远程访问。
BrowZer 可以操作从第三方获得许可的 Web 应用程序并对其进行保护,而无需对其进行更改。同样,如果可以修改 Web 应用程序,但不希望这样做,BrowZer 也允许 OpenZiti 保护这些应用程序。BrowZer Bootstrapper 在从 Web 服务器加载到用户的浏览器时,会自动动态地对 Web 应用程序进行必要的检测。
要在给定网络中启用 BrowZer,必须对其进行配置。有关如何将 BrowZer 添加到网络的信息,请按照 BrowZer 快速入门指南进行操作
逻辑组件
一旦建立并部署了网络,下一步就是配置软件驱动的网络。配置网络所需的三个主要概念是:身份、服务和策略。
服务
服务封装了传统网络上的客户端可以访问的任何资源的定义。服务由强大的、可扩展的标识定义,而不是由底层概念的表达定义。这意味着在网络上定义的服务具有几乎无限的“命名空间”,可用于识别服务。服务由名称和/或证书定义,而不是由 DNS 名称或 IP 地址定义(底层概念)。服务还声明了一个节点,在退出网络之前,需要将退出网络的流量发送到该节点。流量进入网络的节点可能与流量退出的节点相同。或者,流量可能需要遍历网络路由器才能到达出口节点。最终用户只需指定节点即可,其余部分由网络处理。
阅读更多关于服务的信息
身份
身份标识表示网络中可以建立连接的各个端点。在网络内建立的所有连接都使用 X509 证书进行相互身份验证。每个身份都映射到给定证书的签名。Edge 客户端在启动与网络的连接时提供此证书。网络使用提供的证书来授权客户端并列举身份被授权使用的服务。
策略
策略控制允许身份、服务和边缘路由器进行交互的方式。要使用服务,必须向标识授予对服务的访问权限。此外,由于对服务的所有访问都通过另一个边缘路由器,因此必须授予服务和标识才能访问同一边缘路由器或边缘路由器。
Role Attributes角色属性
可以按 ID 或名称明确将身份、服务和边缘路由器等实体添加到策略中。还可以使用角色属性对实体进行标记。角色属性是简单的字符串,如 sales
、 Boston
或 us-employees
support
。它们的含义由管理员决定。策略可以通过指定一组要匹配的角色属性来包含实体。
Service Policies服务策略
服务策略将身份和服务之间的映射封装在软件驱动的网络中。用最简单的术语来说,服务策略是一组服务和一组身份。将服务添加到服务策略的操作将授予该服务策略中的身份对给定服务的访问权限。同样,将身份添加到服务策略将授予该身份访问该服务策略中映射的服务的权限。
服务策略控制哪些身份可以拨打服务(使用服务)以及哪些身份可以绑定服务(提供或托管服务)。每个服务策略都可以授予拨号或绑定访问权限,但不能同时授予两者。
Edge 路由器策略
Edge 路由器策略管理身份和 Edge 路由器之间的映射。边缘路由器策略是一组边缘路由器和一组身份。将路由器添加到 Edge 路由器策略将授予该 Edge 路由器策略中的身份对给定 Edge 路由器的访问权限。同样,向 Edge 路由器策略添加身份将授予该身份对该边缘路由器策略中映射的边缘路由器的访问权限。
Service Edge Router Policies 服务边缘路由器策略
服务边缘路由器策略管理服务与边缘路由器之间的映射。服务边缘路由器策略是一组边缘路由器和一组服务。将边缘路由器添加到服务边缘路由器策略将授予该服务边缘路由器策略中的服务对给定边缘路由器的访问权限。同样,将服务添加到服务边缘路由器策略将授予该服务访问该服务边缘路由器策略中映射的边缘路由器的权限。
关键概念
零信任/应用程序分段
许多网络安全解决方案就像内部网络周围的一堵墙。一旦你穿过墙,你就可以接触到里面的一切。零信任解决方案不仅强制执行对网络的访问,还强制执行对该网络中各个应用程序的访问。
Ziti 系统中的每个客户端都必须具有预置证书的标识。这些证书用于建立安全通信通道,以及对关联身份进行身份验证和授权。每当客户端尝试访问网络应用程序时,Ziti 都会首先确保该身份有权访问该应用程序。如果访问权限被撤销,打开的网络连接将被关闭。
此模型使 Ziti 系统能够提供对多个应用程序的访问,同时确保客户端只能访问已授予访问权限的那些应用程序。
除了要求客户端进行基于证书的身份验证外,Ziti 还使用证书来授权 Ziti 组件之间的通信。
暗服务和路由器
There are various levels of accessibility a network application/service can have. 网络应用程序/服务可以具有不同级别的可访问性。
- 许多网络服务可供全世界使用。然后,该服务依赖于身份验证和授权策略来防止不必要的访问。
- 防火墙可用于限制对特定 IP 或范围的访问。这以牺牲灵活性为代价提高了安全性。添加用户可能很复杂,用户可能无法轻松切换设备或远程访问服务。
- 服务可以放在 VPN 后面,也可以仅供内部网络访问,但这种方法有一些缺点。
- 如果您出于任何原因可以访问 VPN 或内部网络,则该 VPN 中的所有服务都更容易受到您的攻击。
- VPN 通常不适合外部客户或用户。
- 对于最终用户,VPN 会添加一个额外的步骤,每次他们想要访问服务时都需要完成该步骤。
- 服务可以变暗,这意味着它们没有任何端口可供任何人尝试和连接。
可以通过几种方式使某些东西变暗,但在 Ziti 中通常处理的方式是服务伸出并建立一个或多个与 Ziti 网络结构的连接。然后,进入结构的客户端在经过身份验证和授权后可以通过这些连接访问服务。
构成结构的 Ziti 路由器也可能是暗的。位于专用网络中的路由器通常会变暗。这些路由器将伸出专用网络与控制器通信,并建立连接以加入网络结构网格。这允许专用网络中的服务和路由器仅建立出站连接,因此无需为入站流量打开任何漏洞。
如果使用 Ziti SDK 实现服务,它们可能会完全黑暗。如果无法做到这一点,Ziti 隧道器或代理可以与服务位于同一位置。然后,服务只需要允许来自本地计算机或网络的连接,具体取决于代理与服务的托管距离。
端到端加密
Ziti 确保当您使用 Ziti 网络连接到服务时,您的连接从头到尾都是加密的。每个连接都通过 libsodium 提供的公钥-私钥加密技术进行保护。这意味着,即使您的服务数据本身没有加密,SDK 之间的连接也会被加密,并且只能由目标方读取。此功能适用于所有使用 Ziti SDK 的应用程序,包括 Ziti 的 tunneler、桌面和移动应用程序。
在连接安全性页面上阅读有关其他连接的端到端加密和安全性的更多信息。
特征
安全
Private ‘Dark’ Networking私人“黑暗”网络
应用程序越来越多地暴露在公共互联网(以及网络,一般是第 3/4 层)中。开放端口容易受到威胁/容易受到漏洞利用,或者传统的专用网络(VPN、防火墙等)繁琐或无法使用。OpenZiti 使它们在互联网上变得黑暗且不可见,防火墙没有漏洞。它使服务器管理更加可靠和集中,防止任何未经授权的用户进入服务器。
Built-In, Not Bolted On
传统的网络安全暴露在互联网上,至少有一些开放端口允许攻击者扫描并可能发现漏洞。OpenZiti 提供了使用 SDK 直接嵌入到应用程序中的能力,从而消除了这种威胁并使安全性更加强大——也就是说,我们甚至不信任主机操作系统网络,开发人员也不需要知道端口/IP。
Zero Trust 零信任
传统系统允许用户在进行身份验证之前进行连接。许多在不使用单独的防火墙和访问控制点的情况下访问网络,这降低了开发人员的速度并增加了操作员的负担。OpenZiti 要求在使用强身份建立任何连接之前进行身份验证和授权。创建连接时,可以使用最小权限和基于属性的访问控制对其进行微分段。
Trusting Endpoints 信任端点
如果客户端和服务器符合更高级别的访问控制,则假定它们受信任。OpenZiti 作为连接前身份验证和授权的一部分,允许设置终端安全评估检查以检查终端是否通过某些测试,包括 MFA、AD 域成员资格、MAC 地址、操作系统版本和所需进程。
E2E Encryption E2E 加密
我们希望提高整个网络数据的安全性,一般来说,我们正在从 TLS 迁移到 mTLS,但需要处理密钥、PKI 和分发。OpenZiti 实现自己的 PKI,处理引导信任,并默认提供 mTLS 和端到端加密(基于 Libsodium 构建)。我们的方法确保了低开销,不需要密钥,并防止意外用户查看和修改数据。
Flexible Identity 灵活的身份
其他技术堆栈需要使用来自大型组织的身份提供商 (IdP)。OpenZiti 使用 x509 和 JWT 提供其内部强身份系统。它还允许您携带外部 IdP。
Private Authenticated DNS 经过身份验证的专用 DNS
我们需要建立和维护一个可以查询或攻击的公共DNS,而命名必须遵循特定的IP/DNS规范。OpenZiti 不需要依赖全球 DNS;经过身份验证的专用 DNS 仅由已注册的终结点实现和访问。您不需要根据顶级域等来命名服务。
No Port Inference无端口推理
攻击者可以使用端口嗅探来识别数据流的信息(例如,端口 22 是 SSH 数据)。使用 OpenZiti,所有内容都将合成到端口 443 中,所有流量将显示为端口 443。攻击者无法弄清楚您使用/免疫端口嗅探的服务。无源/目标推断 – 攻击者可以拦截流量并确定源和目标作为攻击的宝贵信息。OpenZiti 在元数据穿过覆盖层时对其进行加密,从而消除了这种威胁。
性能和可靠性
The Fabric [Overlay Mesh Network] The Fabric [叠加网格网络]
传统的连接是点对点的,这意味着底层网络上任何位置的任何问题(例如,高延迟)都会导致性能和可靠性问题。OpenZiti 提供跨网格的高可用性和可扩展性的叠加层,结合主动负载均衡和智能路由,以自动选择最低延迟路径。
Service Health服务运行状况
如果应用程序的端到端路径中存在问题,则在不知道原因的情况下停止工作。OpenZiti 实现了服务拨号运行状况指标,以成功了解返回哪些路由响应。这使我们能够了解应用程序网络的整体服务运行状况以及不正常连接的位置,从而快速确定最可能的原因。
易于管理
Addressability可寻址性
我们通常受到 DNS 的限制,同时对谁在连接、何时、何地等的可见性很差——尤其是当一家公司拥有大量设备和应用程序时。OpenZiti 将身份构建到每个连接中,允许直接寻址并规避顶级域命名。网络管理 – 大规模网络难以测量和报告使用情况、成功和其他测量结果。OpenZiti 使用其每个连接的嵌入式标识来轻松理解、衡量和报告服务以及“确切”尝试连接的人员、利用率、成功率、延迟等。
Server to Client服务器到客户端
让服务器与服务器通信的各种方法(例如,HTTP 轮询或 WebSocket)都有缺点,并且不是零信任。OpenZiti 允许任何端点与其他端点通信。没有客户端/服务器的概念。因此,应用程序可以由任何其他参与的终结点托管和访问(只要它已通过其身份验证和授权检查)。
Application Portability应用程序可移植性
应用程序操作员和用户必须考虑其应用程序的托管方式和位置,并设置各种控制措施(例如防火墙)。OpenZiti 驱动的应用程序可以托管在任何地方,而无需担心管理端口、IP、DNS 等,而用户可以从任何地方访问它们,而无需考虑“在网络上”,因为网络会移动到任何地方。
Easy Integration易于集成
开发人员需要识别/配置其应用程序以与网络交互,例如,指定将使用的应用程序端口/IP。OpenZiti 是无缝且易于集成的,如果使用 SDK,开发人员无需指定(甚至不关心)端口/IP 或底层网络。
Multiple options of deployment多种部署选项
将软件部署到桌面/服务器从来都不是一件容易的事。由OpenZiti提供支持的应用程序使您能够减少部署时间和工作量。可以将 SDK 直接集成到已部署的应用程序中。如果无法集成,则可以将预构建的隧道程序和代理用于各种操作系统(包括移动设备),以允许现有应用程序和网络利用 OpenZiti 部署。
软件
OpenZiti首先是软件。以软件的速度发展是任何现代项目的重要特征。
下面简单介绍 OpenZiti 的内部软件架构。在大多数情况下,此信息对于部署和操作网络不是必需的。虽然不是绝对必要的,但了解内部模型可以帮助操作者了解 OpenZiti 提供的功能,了解设计决策,并为贡献者铺平道路。
从广义上讲,OpenZiti 项目主要集中在四个领域:Fabric、Edge、SDK、Clients。下面将对这些领域进行扩展。
Fabric
所有 OpenZiti 存储库都以 Fabric 存储库为基础相互构建。它是唯一可以单独使用并具有网络连接外观的存储库。仅从 Fabric 存储库中,就可以构建仅 Fabric 控制器和路由器二进制文件。这些组件的功能将受到限制,需要低级别的配置和维护。如果完成,将建立一个网状网络,该网络可用于通过定义客户端、目标服务和终端将数据从网络上的任何点发送到任何其他点。
如果没有额外的代码,将普遍缺乏启动端的安全性(即,任何可以连接的东西),并且客户端和服务端都明显缺乏连接选项。Fabric 本身不提供任何允许 SDK 连接到它的功能。它不知道 Edge 和 SDK 组件可以做什么。Fabric 对其网状网络之外的概念“视而不见”。
Fabric 提供了允许其他人定义其他功能的扩展点。 Controller
为此,主要接口在 和 Router
结构中提供。两者都公开了支持集成的代码级 API。
Controller
实例允许定义和管理服务、路由器和终端的持久性数据。它还通过以下接口公开扩展点:
xctrl
- 允许定义可在控制器和路由器之间的控制平面上发送的消息和消息处理程序xmgmt
- 允许定义可在管理连接上发送的消息和消息处理程序xweb
- 允许定义 HTTP Web API,控制器使用这些 API 公开 Fabric API 和 HealthCheck API
Router
实例提供了一个 API,允许设置和销毁电路。它还通过以下接口公开扩展点:
xctrl
- 允许定义可在控制器和路由器之间的控制平面上发送的消息和消息处理程序xweb
- 允许定义 HTTP Web API,路由器使用这些 API 公开 HealthCheck APIxgress
- 允许定义启动和终止连接功能
此外,路由器和控制器允许其他组件检查用于启动实例的静态文件配置。模块 xctrl
、 xweb
和 xgress
利用它来添加配置部分。这些配置部分允许特定于类型的自定义配置。
Edge
Fabric 提供了多个扩展点。这些扩展点的主要使用者是 Edge。Edge 扩展了控制器和路由器,以添加额外的安全控制并启用 SDK 连接。Edge 添加了端点身份的概念,这些身份表示可以连接到网络的 OpenZiti SDK。此概念充当一整套身份生命周期和访问管理功能的跳板。以下是 Fabric 扩展点以及它们启用的 Edge 功能。
xctrl
- 为控制器和路由器添加 API 会话/会话控制和强制执行xweb
- 在控制器上公开edge管理和客户端 REST APIxgress
- 定义了一个新的协议,xgress_edge
使 SDK 能够连接到路由器以充当服务客户端和主机
Edge 还公开了 SDK 的配置扩展点。SDK 开发人员可以使用 JSON 架构定义配置类型。此配置可以存储在服务、标识或标识 + 服务特定级别,并根据请求交付给连接的应用程序。此机制允许 SDK 应用程序定义和分发配置,以支持高级应用程序功能。预构建的 OpenZiti 客户端使用此功能来支持 DNS/IP 拦截地址等功能。
SDKs
Ziti SDK 有多种语言版本。在适当的情况下,它们是 Ziti C SDK 的包装器。SDK 利用控制器上的边缘客户端 REST API 和路由器上的 xgress_edge
协议,将 OpenZiti 网络扩展到路由器的网状网络之外,扩展到应用程序和设备。SDK 依靠 Edge 通过网络实现服务连接。SDK 不直接与 Fabric 交互。它们充当了利用网络力量的支点。
SDK 公开了一个 API,该 API 允许端点注册、身份验证、列出服务、接收集中配置以及根据安全访问配置连接或托管服务。
Clients
OpenZiti 客户端是使用 OpenZiti SDK 连接到网络的任何代码。OpenZiti项目可以提供这些应用程序,也可以由任何软件开发人员定制。他们直接依赖于 OpenZiti SDK,间接依赖于 Edge,然后是 Fabric。它们可以充当服务的启动客户端或终止主机。客户可能会也可能不会公开扩展点 - 这是作者的自由裁量权。
Contributing
OpenZiti 项目欢迎贡献,包括但不限于代码、文档和错误报告。OpenZiti 已经发展到拥有许多存储库。这里只是一些值得注意的存储库,还有更多:
- 所有代码都可以在 OpenZiti 组织的 GitHub 上找到。
- ziti:构建所有 OpenZiti 可执行文件的顶级项目
- foundation:包含跨多个项目使用的库代码的项目
- SDKs
- ziti-sdk-c:C SDK
- ziti-sdk-golang: Go SDK
- ziti-sdk-jvm: 基于 JVM 语言的 SDK
- ziti-sdk-py: Python SDK
- ziti-sdk-swift: Swift SDK
- ziti-sdk-nodejs: NodeJS SDK
- ziti-sdk-csharp: C# SDK
- ziti-doc: 文档(您当前正在阅读)
- 提供交流论坛
OpenZiti 由 NetFoundry Inc. 开发并开源。NetFoundry继续为OpenZiti提供资金和贡献。
快速开始
开始使用Ziti
了解如何开始将零信任直接集成到您的应用程序中!浏览我们的快速入门,了解如何获得自己的开源零信任网络覆盖设置。
OpenZiti 正在将零信任带入世界各地的网络!要真正充分利用 Ziti,您需要将其直接嵌入到您的应用程序中。Ziti 为此提供了许多 SDK。如果尚未准备好将零信任直接嵌入到应用程序中,仍可以使用一个或多个隧道应用开始。
INFO 信息
快速入门是短暂的网络,非常适合学习如何 Ziti 所有 things!有关长期生产部署,请参阅部署指南。
TIP 提示
如果您遇到任何问题,请记住,指向讨论网站的链接位于所有文档页面的右上角。不要害怕向社区寻求帮助!
Getting Started - Network
当您刚刚开始时,您需要做的第一件事是访问网络。对于刚起步的人来说,有四个基本选项:
Run all the binaries locally:在本地运行所有二进制文件。您将自行启动和停止组件。这非常适合学习,但由于它都是本地的,因此将您定义的任何服务与本地计算机分开有点困难。
Run locally using Docker:使用 Docker 在本地运行。这允许您执行一些更复杂的事情,例如将服务与您自己隔离。
Run on your own server:在您自己的服务器上运行。此选项适用于两种情况。如果您有服务器:如果您有其他人,则这很好,您希望可以访问您的网络并且不在本地网络上。
- 如果您不想处理设置网络的问题,那么可以在 NetFoundry 控制台上注册免费套餐帐户
哪种网络选项适合您
网络
本地 - 无docker
本页将向您展示如何完全在本地快速轻松地启动和运行您的网络。由于您将在本地运行所有内容,因此在网络组件之间进行通信不会有任何问题。所有进程都将在本地运行,当您想要打开或关闭覆盖网络时,您将负责启动和停止它们。
先决条件
NOTE 注意
在运行单行
expressInstall
代码之前,请确保已安装tar
、hostname
jq
和curl
。
目前,本指南预计您将在 bash
shell 中运行命令。如果您运行的是 Windows,则需要确保您现在已经安装了适用于 Linux 的 Windows 子系统。我们计划在未来提供一个 Powershell 脚本,但现在该脚本要求您能够使用 bash
.在运行控制器之前,请确保您的本地端口 1280 , 6262 , 10000 是空闲的。这些端口是控制器使用的默认端口。此外,请确保端口 10080 和 3022 已打开,因为这些是边缘路由器将使用的默认端口。
Run expressInstall
One-liner
在本地运行最新版本的 Ziti 就像运行以下命令一样简单:
|
|
此脚本将执行 Ziti 的“快速”安装,该安装将执行以下操作:
- 下载最新版本的 OpenZiti 二进制文件 (
ziti
) - 将二进制文件解压缩到预定义的位置:~/.ziti/quickstart/$(hostname -s)
- 创建完整的 PKI 供您探索
- 使用默认值和上面创建的 PKI 创建控制器配置
- 使用默认值和上面创建的 PKI 创建 edge-router 配置
- 将帮助程序函数和环境变量添加到 shell(浏览脚本以查看全部)
启动组件
一旦下载了最新版本的 Ziti 并将其添加到您的路径中,就可以启动您的控制器和edge路由器了。
启动控制器
|
|
输出示例:
|
|
验证控制器是否正在运行
运行 expressInstall
后,您将设置名为 ZITI_CTRL_EDGE_ADVERTISED_ADDRESS
和 ZITI_CTRL_EDGE_ADVERTISED_PORT
的环境变量。控制器启动后,您的控制器应侦听地址:端口。(请注意,如果您没有这些环境变量,则您可能已经关闭了 shell 并再次打开它。您可以通过获取“.env”文件来获取环境变量。有关详细信息,请参阅页面底部的部分)
您可以通过运行 echo ${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}:${ZITI_CTRL_EDGE_ADVERTISED_PORT}
来查看您的值设置了什么。此值默认为: $(hostname -s):1280
。尝试curl到地址,确保控制器可用,然后启动边缘路由器。
|
|
输出示例:
|
|
启动edge路由器
现在控制器已准备就绪,您可以启动使用“快速”(express)过程创建的边缘路由器。您可以通过运行以下命令在本地启动此路由器:
|
|
输出示例:
|
|
您可以通过 echo $ZITI_ROUTER_ADVERTISED_ADDRESS:$ZITI_ROUTER_PORT
来验证边缘路由器是否正在侦听。同样,这将默认用作 $(hostname -s)
主机名和端口 3022。
停止控制器和路由器
|
|
输出示例:
|
|
测试Overlay叠加层
在这一点上,你应该有一个正常运行的网络。您获取的脚本提供了另一个登录到您的网络的功能。现在就试试这个方法,运行 zitiLogin
。您应该看到类似于以下内容的内容:
|
|
您现在可以使用 ziti
CLI 与 Ziti 进行交互!默认情况下, ziti
二进制文件不会添加到您的路径中,但将在 "${ZITI_BIN_DIR-}/ziti"
中可用。将该文件夹添加到您的路径中,如果您愿意,可以添加 ziti
别名。让我们尝试使用此命令,通过运行以下命令来查看边缘路由器是否在线。 "${ZITI_BIN_DIR-}/ziti" edge list edge-routers
|
|
我们的边缘路由器出现并在线!
运行第一个服务
You can try out creating and running a simple echo service through ziti by running the first-service
tutorial.
您可以通过运行 first-service
教程来尝试通过 ziti 创建和运行一个简单的 echo 服务。
|
|
自定义快速安装
如果您愿意,您可以在一定程度上影响和自定义快速安装。如果尝试在本地运行多个 Ziti 实例,这将非常有用。您可能选择自定义的最常见设置是使用的端口或网络名称。
配置文件位置
您可以通过在运行 expressInstall
之前设置 ZITI_NETWORK
环境变量来更改配置文件输出的位置。但是,如果执行此操作,您还需要设置其他环境变量。请注意,如果更改这些变量,则每个“主机名”变量都需要是可寻址的:
- ZITI_CTRL_EDGE_ADVERTISED_ADDRESS
- ZITI_CTRL_EDGE_ADVERTISED_PORT
- ZITI_ROUTER_ADVERTISED_ADDRESS
- ZITI_ROUTER_PORT
以下示例允许您将所有文件放入一个名为以下内容的文件夹中: ${HOME}/.ziti/quickstart/newfolder
,使用名为“localhost”的主机,并使用端口 8800 用于边缘控制器,将端口 9090 用于边缘路由器:
|
|
获取 Env 文件
如果您关闭了 shell,并希望将相同的环境变量恢复到 shell 中,则只需获取放置在指定位置的“env”文件即可。此文件通常位于: $HOME/.ziti/quickstart/$(hostname)/$(hostname).env
。您可以获取此文件以将环境变量放回 shell 中。
|
|
后续步骤
- 现在您已经有了自己的网络,您可能想尝试一下。前往 Your First Service 快速入门,开始学习如何使用 OpenZiti。
- 安装控制台 (Web UI)
- 添加第二个公共路由器:为了让多个路由器形成传输链路,它们需要防火墙例外来暴露“链路侦听器”端口。默认端口为
10080/tcp
。 - 帮助
本地 - Docker Compose
如果您不熟悉它,Docker Compose 是一个用于定义和运行多容器 Docker 应用程序的工具。它通过使用通过 yaml 定义的声明式格式来轻松部署多个容器。请注意,此页面使用“Compose V2”。这意味着显示的所有命令都将引用 docker compose
,而不是 docker-compose
。如果您使用的是较旧的撰写风格,请考虑升级到较新的 v2。
准备所需文件
首先,使用如下所示的 curl,从 ziti 存储库中获取 compose 文件。
|
|
接下来,获取默认环境文件,或者在此文件夹中创建一个如下所示的文件:
|
|
或者,如果您希望手动制作 .env 文件,请以某种方式创建文件,例如使用如下所示的命令:
|
|
CAUTION 谨慎
如果您运行的是 Void linux,则需要修改 docker-compose 文件,否则服务将无法正常启动。为此,请将以下两行添加到每个服务定义中。
1 2
security_opt: - seccomp:unconfined
有关详细信息,请参阅此讨论
运行网络
下载compose
和 .env
文件后,您将能够像使用任何其他compose文件一样启动此网络: docker compose up
NOTE 注意
Docker compose 将根据启动容器时所在的文件夹来命名容器。对我来说,我制作了一个名为
docker
的文件夹,所以我所有的容器都以docker_
.您可以通过向docker compose
向上/向下命令添加--project-name docker
(或您喜欢的任何名称)来影响其工作方式
1
docker compose --project-name docker up
停止网络
这个docker-compose文件将生成一个卷挂载以及两个docker网络。当您发出 --project-name docker down
时,卷映射不会被删除。如果您希望删除卷,则需要在 docker compose
命令中指定 -v
标志。如果您想停止容器而不丢失控制器数据库和PKI,请将 -v
从命令中删除
部署关系图
docker-compose 文件将代表您创建相当多的容器。以下是将要创建的网络的逻辑概述:
正如你所看到的,这里面有相当多的东西,让我们分解一下。首先要注意的是,整个镜像都在 Docker 网络的范围内。您将看到,在compose文件中,有三个跨 Docker 网络的覆盖层:控制器、边缘路由器和基于 websocket 的边缘路由器。
简化部署
上面下载的docker-compose.yml部署了许多组件,并且有些复杂。如果您更喜欢通过 Docker compose 进行简化部署,其中仅包含基本控制器和边缘路由器组合,则可以改为下载simplified-docker-compose.yml
多个网络
在此 Docker 网络中,你会看到有三个子网络:
- 蓝色 Docker 网络
- 红色 Docker 网络
- 紫色的“逻辑”网络
Docker 将确保只有给定网络中的部分才能在该网络内进行通信。这种网络拓扑旨在非常松散地近似于拥有公共部署的网络的样子。紫色网络近似于互联网本身,蓝色网络代表云提供商的私有网络(如 AWS),红色网络可能代表另一个云提供商网络(如 Azure)。这些细节并不重要,重要的是网络彼此之间是完全私有的。在下面的“测试”部分中查看有关此主题的更多信息。
紫色网络
compose 文件中没有名为“purple”的 Docker 网络,它完全是一个逻辑构造。它只是为了清楚起见而显示。紫色网络中的所有资产都在蓝色和红色的 docker 网络中(这就是为什么它被称为紫色)。紫色网络中的资产需要同时位于红色和蓝色网络中,因为位于蓝色和红色网络中的资产需要与公共边缘路由器通信,并且还需要与控制器通信。如果这令人困惑,请参阅下面的“测试”部分,希望能更清楚地说明这一点。
红色网络
红色网络目前仅用于演示。如您所见,红色网络内除了ziti-private-red
路由器和 ziti-fabric-router-br
外没有任何东西可以访问。这将是您放置自己的资产并使用 Ziti 进行探索的好地方!
蓝色网络
蓝色网络包含两个重要资产, ziti-private-blue
路由器和 web-test-blue
服务器。除了这些资产外,网络还包含 ziti-fabric-router-br
.虽然 web-test-blue
服务器默认导出一个端口(本地主机上的端口 80 将转换为 web-test-blue
服务器上的端口 8000),但您可以使用 Ziti 访问此服务器,而无需导出端口。
“Fabric”路由器
存在 ziti-fabric-router-br
是为了说明您可以创建不一定是完全公开的边缘路由器。这是唯一可以与所有其他路由器通信的路由器。如果算法指示它是最快的路径,Ziti 网状网络可能会选择使用此路由器。也许我们会在以后的文档中看到更多关于这方面的内容。
测试网络
在本地使用 Docker
一个快速的说明。如果你不熟悉 Docker,你可能会忘记在 Docker 中公开端口是一回事,但你还需要为你想要从Docker网络外部访问的容器设置一个主机条目。这个快速入门将期望你理解这一点,对于你添加的每一个路由器,你都要确保你添加了一个主机条目。在 docker compose
示例中,您需要/希望至少以下主机条目:
ziti-edge-controller
,ziti-edge-router
如果你想公开任何其他路由器 - 当然,你也需要/希望有这些路由器的条目。
测试
现在我们已经使用docker compose
部署了一个相对复杂的网络,我们可以开始测试它,以确保一切就绪并且看起来正确。让我们试试看。
为了测试,我们将使用 docker exec
进入正在运行的控制器。请注意,我们将指定容器,并且该项目应命名为“docker”。如果您没有使用 --project-name docker
启动compose ,请使用正确的 exec 命令:
|
|
一旦进入到控制器后, ziti
CLI 将为您添加到您的 PATH 中。还有 zitiLogin
别名,使您可以轻松地向 Ziti 控制器进行身份验证。立即运行 zitiLogin
并确保已通过身份验证。
|
|
测试 - 在线边缘路由器
通过身份验证后,让我们运行 ziti edge list edge-routers
命令查看所有路由器是否都在线:
|
|
我们可以看到所有的路由器都在线 - 非常好。
测试 - 边缘路由器身份
在compose文件中,我们使用了一个脚本,该脚本还为每个边缘路由器添加了一个身份。我们可以通过运行 ziti edge list identities
命令来查看:
|
|
请注意,每个路由器都有一个身份。
测试 - 网络连接成功
回想一下,控制器应该能够使用底层网络联系红色和蓝色边缘路由器。让我们使用 ping 并验证:
|
|
|
|
测试 - 底层网络连接失败
现在让我们退出 Ziti 控制器,并通过运行以下命令连接到蓝色专用路由器: docker exec -it docker-ziti-private-blue-1 bash
。连接到蓝色路由器后,我们将验证我们无法连接到专用红色路由器:
|
|
未知主机 - 专用蓝色路由器无法连接到红色路由器。
测试 - 底层网络 web-test-blue
当我们连接到蓝色路由器时 - 让我们确保我们可以连接到该 web-test-blue
服务器。
|
|
别忘了 - 您也可以从本地计算机上的导出端口 80 访问它!
|
|
后续步骤
-
现在你已经有了你的网络,你可能想尝试一下。前往 Your First Service 快速入门,开始学习如何使用 OpenZiti。
-
添加第二个公共路由器:为了使多个路由器形成传输链路,它们需要防火墙例外来公开“链路侦听器”端口。默认端口为
10080/tcp
。 -
帮助
帮助
更改密码
按照以下说明更改快速入门管理员密码。当您运行 expressInstall
时,会为您生成一个随机密码,并将其保存在 *.env文件中作为 ZITI_PWD
。更改密码后,还更改 ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env
中 ZITI_PWD
的值以匹配。此变量由 zitiLogin
函数使用。
使用 ziti
CLI
-
立即登录
ziti
CLI将帮助您从控制器的管理API获取API会话。系统将提示您信任任何新的服务器证书。您的登录令牌缓存和信任存储区由主目录中的CLI管理。1 2
# implies https://localhost:1280 ziti edge login -u admin -p admin
1 2
# implies https:// ziti edge login ctrl.ziti.example.com:8441 -u admin -p admin
-
如果用户身份的密码为
updb
,用下面的命令通过CLI修改1
ziti edge update authenticator updb -s
使用Ziti控制台
如果您在快速入门网络中安装了控制台(ZAC),那么您可以使用当前密码登录并更改它。
点击左下角的个人图标,然后选择“编辑个人资料”,如图所示更改您的密码。
快速入门细节
下面解释了执行expressInstall函数时自动发生的步骤。Local - No Docker、Local - With Docker、Local - Docker Compose和Host OpenZiti Anywhere快速入门都运行 expressInstall
函数。每个版本略有不同。本页将重点介绍Local - No Docker快速入门。
一般过程
- 获取OpenZiti二进制文件
- 创建PKI
- 创建控制器配置
- 初始化控制器
- 启动控制器
- 创建路由器配置
- 在网络上创建路由器实体(通过控制器)
- 注册上一步创建的路由器
- 添加默认边缘路由器和服务边缘路由器策略。
常规环境设置
- 获取OpenZiti二进制文件
expressInstall
函数将调用 getZiti
以获取Ziti二进制文件。 getZiti
函数检测您的操作系统类型和体系结构,以手工制作二进制文件的特定下载URL。下载二进制文件,并将其解压缩到网络目录中的一个目录。
NOTE 注意
快速入门脚本不限于
expressInstall
。您可以获取ziti-cli-function.sh
文件的源代码并运行许多有用的函数中的任何一个。例如,您可以运行getZiti
以快速轻松地下载最新版本的OpenZiti。
- 创建PKI
作为 expressInstall
的一部分,PKI会自动生成。PKI由一个根CA、四个中间CA组成;每个控制器的配置部分(控制、边缘/API、身份)和一个任意CA各一个。此外,在签名证书链上创建了一个额外的中间CA,以证明任意证书链长度都是可以接受的。
生成CA后,将为每个控制器的配置部分生成密钥、服务器证书和客户端证书。下图显示了整个PKI体系结构。
- 更新CA捆绑包
最新的隧道器需要完整的PKI,而不是任意的信任锚。因此,必须将根CA和中间CA添加到CA捆绑包中。此外,还会为Edge/API CA捆绑包复制该文件。
|
|
- 控制器创建和配置
使用OpenZiti CLI二进制文件生成控制器配置文件。在创建配置之后,初始化控制器。初始化的过程也会对数据库进行初始化。
然后启动控制器,并且快速启动在继续之前等待控制器完成启动,因为控制器是创建边缘路由器所必需的,这在接下来的步骤中发生。
- 默认策略
生成两个策略来简化网络入门过程。创建边缘路由器策略以允许所有身份连接到具有 #public
属性的路由器。在 expressInstall
期间创建的路由器将填充此属性。还创建了服务边缘路由器策略,允许所有服务使用具有 #public
属性的路由器。
- 路由器创建和配置
与控制器一样,会为路由器生成一个配置文件。路由器也需要通过控制器创建。这将生成在路由器注册期间使用的一次性令牌(OTT)。
然后,使用路由器配置按照路由器的OTT来注册路由器。
定制
快速入门提供了许多环境变量,用于自定义您的独特情况。这里列出了最常用的环境变量及其描述。
默认情况下,快速入门PKI设置为使用 127.0.0.1
作为默认IP。 *_IP_OVERRIDE
变量允许您添加PKI将有效的IP。
ZITI_CTRL_EDGE_IP_OVERRIDE
控制器的附加IP。此值将添加到控制器边缘PKI信任链的PKI SAN IP字段中。ZITI_ROUTER_IP_OVERRIDE
是路由器的自定义IP。
这里有一些更常见的变量。
ZITI_CTRL_EDGE_ADVERTISED_ADDRESS
是PKI中使用的控制器地址的有效名称。ZITI_ROUTER_ADVERTISED_ADDRESS
是路由器的通告地址。如果设置,则默认为EXTERNAL_DNS
中的值。否则,使用EXTERNAL_IP
中的值。ZITI_CTRL_ADVERTISED_PORT
是用于控制器控制平面地址的端口。ZITI_CTRL_EDGE_ADVERTISED_PORT
是用于控制器边缘/API平面地址的端口。ZITI_ROUTER_PORT
是用于路由器通告地址的端口。
以下是与PKI相关的自定义变量
PKI生成仅发生一次
- quickstart拥有设置PKI的相关信息是非常重要的。此生成仅执行一次,因此如果不正确,则需要重新生成整个PKI。
DNS通过IP连接
- 强烈建议使用DNS over IP,因为这是一次性设置,如果您的IP发生变化,那么您的PKI将变得无用。
|
|
重置快速入门
您可能希望使用不同的参数重新运行 expressInstall
,或者因为就绪检查失败。您可以在不更改当前安装的情况下使用新的 ZITI_HOME
再次运行它,或者删除目录,然后开始以下步骤:
-
删除快速安装目录。删除是永远的,所以请确保您删除的是正确的东西。
1
rm -rI "${ZITI_HOME}" # probably a sub-directory of ~/.ziti/quickstart/
-
如果当前的shell环境是通过快速安装配置的,您可以取消设置名为
ZITI_
的变量。这将准备好您当前的shell环境,以便设置和重新运行expressInstall
。1
unsetZitiEnv
-
返回到运行
expressinstall
之前的设置步骤,例如,为下一次运行设置必要的环境变量。
Console
Ziti管理控制台( Ziti Administration Console,ZAC)是由OpenZiti项目提供的Web UI,允许您配置和浏览网络。
概述
下面的步骤用来启用本章“快速开始”控制器的控制台。在用于Linux(WSL)、macOS或Linux的Windows子系统中使用shell(如 bash
)运行这些命令。
从GitHub下载
这些步骤适用于本地- 无Docker和Hosted Yourself部署。
-
在控制器主机上,从GitHub下载最新版本的控制台。您可以使用任何>= 3.0.0版本的控制台。
1
wget https://github.com/openziti/ziti-console/releases/latest/download/ziti-console.zip
-
确保
ZITI_HOME
设置为您的快速开始工作目录,并export到forked进程。您始终可以通过获取环境文件来恢复快速开始的环境变量。1 2
source ${HOME}/.ziti/quickstart/$(hostname)/$(hostname).env export ZITI_HOME
-
在控制器的工作目录中解压缩控制台。
1
unzip -d ${ZITI_HOME}/zac ./ziti-console.zip
-
在
${ZITI_HOME}/$(hostname -s).yaml
中,在包含edge-management
的列表中添加web API绑定zac
。1 2 3 4
- binding: zac options: location: ./zac indexFile: index.html
-
重新启动控制器服务以应用更改。
1
sudo systemctl restart ziti-controller.service
-
在Web浏览器中导航到控制台,例如,
https://ctrl.ziti.example.com:1280/zac/
使用Docker
从控制器复制PKI
在任何地方使用TLS都是一个好主意。为此,您需要向ZAC提供密钥和证书。如果你已经使用Local - With Docker快速入门来启动网络,你可以复制控制器启动时生成的证书。所示的示例从OpenZiti容器复制证书并将其与ZAC一起使用。我们将从名为volume myPersistentZitiFiles
的docker中复制文件,并将它们放入 $HOME/.ziti/zac-pki
的文件夹中。
|
|
启动ZAC
复制证书后,您将能够使用一个Docker命令启动ZAC。还请注意,该命令将向您的本地计算机公开ZAC http和https端口,以便您可以从Docker外部访问ZAC。如果您自定义了这些路径中的任何一个,则需要相应地替换指定的路径('-v’行)。
|
|
注意
请注意,如果你像上面所示的那样暴露端口,你需要确保
ziti-edge-controller
可以被你的机器寻址,以便以这种方式使用Docker。本指南不深入介绍如何做到这一点。一个简单而常见的机制是编辑操作系统的“主机”文件。一个快速的互联网搜索应该告诉你如何做到这一点。
Docker Compose
如果你已经遵循了Local - Docker Compose快速入门,那么ZAC已经在运行了。它现在包含在默认的docker-compose文件和 simplified-docker-compose文件中。两个编写文件都将启动并暴露1408/8443上的ZAC端口。
注意
请注意,如果你像上面所示的那样暴露端口,你需要确保
ziti-edge-controller
可以被你的机器寻址,以便以这种方式使用Docker。本指南不深入介绍如何做到这一点。一个简单而常见的机制是编辑操作系统的“主机”文件。一个快速的互联网搜索应该告诉你如何做到这一点。
Kubernetes
登录并使用ZAC
-
此时,您应该能够导航到:
https://${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}:8443
并看到ZAC登录屏幕。(The TLS警告你的浏览器会显示你是正常的-这是因为这些步骤使用自签名证书在安装过程中生成)注意
如果你使用docker-compose来启动你的网络,当你第一次访问ZAC时,你需要指定控制器的url。由于所有内容都在docker compose中运行,因此该url相对于compose文件中声明的内部docker compose网络。输入
https://ziti-edge-controller:1280
作为控制器的URL -
如图所示设置控制器(使用正确的URL):
-
使用“一切本地”快速入门的示例:
-
使用“docker-compose”快速入门的示例:
-
使用AWS“随处托管”的示例:
-
-
或者,更改管理员的密码
BrowZer
BrowZer是一组能够完全在浏览器中引导零信任连接的技术,而无需安装任何客户端软件!要在您的网络上启用BrowZer,需要部署 ziti-browzer-bootstrapper
。本节概述了将BrowZer部署到您自己的覆盖层所需的步骤。有关启用BrowZer的详细示例,请参阅启用BrowZer的示例子页面,其中显示了更详细的步骤。
先决条件
要在您的网络上部署和启用BrowZer,您需要:
- OpenZiti覆盖网络可用,并已配置了备用服务器证书
- OIDC提供商以及为提供商定义应用程序/客户端的能力
- 来自第三方可验证CA的SSL证书
OIDC
启用BrowZer将需要配置网络以将身份验证委托给OIDC提供商。每个OIDC提供商都是不同的,理解OIDC流程超出了本指南的范围。有许多优秀的文章可以找到和阅读关于OIDC的文章。您需要了解的OIDC概念包括:
- 如何创建/获取网络将使用的客户端ID
- 如何学习/查找/发现OIDC发现端点
- OIDC提供商将向承载令牌添加的内容
audience
- OIDC提供商将向承载令牌添加什么字段或
claim
,该字段或claim
将用于定位匹配身份
配置网络
有了OIDC信息,下一步是实际配置OpenZiti以允许授权身份验证。为此,您需要:
创建外部JWT签名者
要创建外部jwt签名者,您需要手边有OIDC发现端点和 audience
值。使用OIDC发现端点,从发现端点发现 issuer
和 jwks_uri
。使用 ziti
CLI创建外部jwt。下面是一个 bash
的例子。相应地替换这些值。捕获返回的身份,在创建外部jwt签名者之后,这将是必要的:
|
|
创建身份验证策略
身份验证策略配置网络以委托一个或多个OIDC提供商进行身份验证。要创建身份验证策略,您只需要外部jwt签名者的id(如上所述)。下面是一个 bash
示例。相应地替换这些值。捕获返回的身份,在创建外部jwt签名者之后,这将是必要的:
注意
下面显示的是创建新身份验证策略并允许将其用于主身份验证的示例。这意味着允许关联的外部jwt签名者(OIDC提供者)提供OpenZiti将验证的文档,并用于身份验证。您也可以选择修改默认策略(如果您决定这样做)。您不需要创建新策略。如果这是您第一次使用BrowZer,建议您使用新的身份验证策略,如图所示。一旦您了解了身份验证策略的工作原理以及BrowZer的工作原理,那么您就可以做出是否要修改默认身份验证策略的明智决定
|
|
将身份与身份验证策略关联
创建了一个身份验证策略并将其关联到外部jwt签名者之后,现在就可以创建或修改身份以使用这个新的身份验证策略了。要允许BrowZer启用给定的身份,您需要首先使用 externalId
更新(或创建)身份,并且需要将身份与身份验证策略相关联。
在该示例中,将创建新的身份,并且相关联的OIDC提供商将被期望提供承载令牌,该承载令牌具有值为 ziggy@openziti.io
的 email
声明并且将身份命名为 openziti_ziggy
:
|
|
设置环境变量
运行Ziti BrowZer Bootstrapper可以直接使用NodeJS或Docker等容器引擎完成。无论选择哪种方式运行它,都需要建立一些环境变量。如果你正在使用NodeJS,你会 export
他们。要使用Docker运行,您可以引用环境变量(如下所示)或使用 .env
文件。
NODE_ENV
:控制环境是production
还是development
ZITI_BROWZER_RUNTIME_LOGLEVEL
:Ziti BrowZer浏览器(ZBR)要使用的日志级别。trace|debug|info|warn|error
ZITI_BROWZER_RUNTIME_HOTKEY
:激活BrowZer设置对话框模式的热键。默认值:alt+F12ZITI_CONTROLLER_HOST
:OpenZiti控制器的“替代”地址。示例:ctrl.openziti.io
ZITI_CONTROLLER_PORT
:找到OpenZiti控制器的端口。示例:8441
ZITI_BROWZER_BOOTSTRAPPER_LOGLEVEL
:ziti-browzer-bootstrapper要登录的日志级别。trace|debug|info|warn|error
ZITI_BROWZER_BOOTSTRAPPER_HOST
:ziti-browzer-bootstrapper的可用地址。示例:browzer.openziti.io
ZITI_BROWZER_BOOTSTRAPPER_LISTEN_PORT
:ziti-browzer-bootstrapper可用的端口。示例:443
ZITI_BROWZER_BOOTSTRAPPER_SCHEME
:用于访问ziti-browzer-bootstrapper的方案。http|https
(默认为https)ZITI_BROWZER_BOOTSTRAPPER_CERTIFICATE_PATH
:ziti-browzer-bootstrapper提供给客户端的证书路径ZITI_BROWZER_BOOTSTRAPPER_KEY_PATH
:ZITI_BROWZER_BOOTSTRAPPER_CERTIFICATE_PATH的关联键ZITI_BROWZER_BOOTSTRAPPER_TARGETS
:一个json块,表示要启用BrowZer的服务。
|
|
相应地设置这些值。还显示了在这种情况下由LetsEncrypt提供的证书的重用。BrowZer要求提供与所使用的 ZITI_BROWZER_BOOTSTRAPPER_HOST
值一致的证书。例如,如果设置了 ZITI_BROWZER_BOOTSTRAPPER_HOST=my.custom.network
,则证书必须对 *.my.custom.network
有效
注意
如果您使用Certbot/LetsEncrypt,则创建的证书可能只能由root访问。您需要相应地修改文件夹/文件。
从GitHub克隆
设置环境变量后,要启动Ziti BrowZer引导程序,请执行以下操作:
-
克隆仓库并签出所需的标签/版本。
main
应该很好1
git clone https://github.com/openziti/ziti-browzer-bootstrapper.git $ZITI_HOME/ziti-browzer-bootstrapper
-
cd到克隆位置:
cd $ZITI_HOME/ziti-browzer-bootstrapper
-
确保安装了正确版本的节点和yarn并运行yarn安装:
yarn install
-
启动节点服务器:
1
NODE_EXTRA_CA_CERTS=node_modules/node_extra_ca_certs_mozilla_bundle/ca_bundle/ca_intermediate_root_bundle.pem node index.js
通过Docker运行
使用Docker运行Ziti BrowZer Bootstrapper类似于使用NodeJS运行。建立环境变量,然后使用如下所示的命令运行代理。请注意,这是在前台运行的。由您决定将其置于守护程序模式,使用 docker compose
等。
NOTE 注意
为了解决上面提到的LetsEncrypt问题(证书只对root可见),这个例子显式地将容器运行的–user设置为组ID 2171。没有显示在Docker中运行之前创建的这个组。在Docker主机操作系统中,使用以下命令添加了一个组:
sudo groupadd -g 2171 zitiweb
。然后,包含证书/密钥的LetsEncrypt文件夹被chown’ed:sudo chown -R root:zitiweb /etc/letsencrypt/
。这允许将运行引导程序的Docker容器访问文件理解为什么/如何工作的确切机制超出了本页的范围,与Linux/Docker系统管理更相关。
Docker命令示例
|
|
使用Systemd启用BrowZer
如果您希望BrowZer Bootstrap Agent在计算机启动时启动,或者如果进程由于某种原因失败,并且您的系统上有systemd,则可以启用BrowZer Bootstrap Agent在失败或重新启动时自动启动。
如果您使用了“clone from GitHub”方法,您已经获取了 ziti-cli-functions.sh
helper脚本,并从快速启动安装中设置了环境变量,则可以执行单个函数来创建systemd单元文件: createBrowZerSystemdFile
。现在执行它,你会看到类似这样的东西:
|
|
创建后,您可以使用systemd复制该文件和 enable
单元:
|
|
验证BrowZer是否已启动
|
|
输出示例:您应该看到类似于此的输出。请注意,“Active”状态是(运行),而不是失败/重新启动等:
|
|
Services
一旦你有了零信任覆盖网络,并且你想开始使用它,你就会想知道从哪里开始。你可以从几个不同的方向开始。根据你的经验和你想做的事情,你会有很多方向可以进行。
零信任应用程序访问
OpenZiti 实际上是将零信任直接嵌入到您的应用程序中。如果你是一名开发人员,你可能想从你最喜欢的语言开始,并以“零信任应用程序访问”开始你的OpenZiti之旅。这意味着您将采用 SDK 并将其嵌入到您编写的应用程序中!最好探索最适合你的语言的 SDK,并找到该 SDK 要使用的示例。首页包含所有可供选择的 SDK 的链接。
零信任主机访问
如果你不是开发人员,或者你有一个无法(或不想)更改的应用程序,你可以从“零信任主机访问”开始。为此,您将在“客户端”和“服务器”上安装 OpenZiti 隧道器,并使用这些可执行文件提供对服务的访问。如果这听起来像是一个好的起点,请按照你的第一个服务快速入门进行操作。
零信任主机访问
本文档将演示如何使用 OpenZiti 成功部署和保护现有的“棕色领域”(brown field)应用程序。您希望在无法控制源代码或不想(或不能)将 OpenZiti SDK 集成到应用程序中的应用程序中保护应用程序。这类服务通常是基于 Web 的,因此我们将在这里重点介绍公开 Web 服务器。重要的是要记住,OpenZiti 是一个整体的零信任网络解决方案。您绝对可以公开不基于 Web 的应用程序。现在,我们将从 Web 服务器开始,因为这是一个共同的需求。
解决方案概述
在我们开始使用 OpenZiti 之前,让我们花点时间回顾一下解决方案是什么样的,然后再应用任何零信任网络原则。我们将使用某种 http 客户端,通过网络连接它。确切的网络并不重要。OpenZiti适用于任何网络,无论是主机网络、本地网络、互联网、专用网络等。
**使用 Ziti 之前的 HTTP **
注意此图 HTTP 服务器是在底层网络上配置的,并且需要通过防火墙开一个洞才能允许客户端连接。
使用 Ziti 之后的 HTTP
在 OpenZiti 之后,我们可以看到不再有开放的防火墙允许访问 HTTP 服务器。相反,HTTP 客户端的网络请求将被 OpenZiti 隧道程序拦截。一旦被截获,数据包就会被传送到OpenZiti overlay fabric,该结构负责将截获的数据包传送到目标身份。在此示例中,一旦传送到目标身份,流量将卸载回底层网络,以发送到最终目的地:HTTP 服务器。
了解了我们希望在本指南中实现的目标后,让我们开始吧!
实现服务
先决条件 - OpenZiti
在完成本指南之前,您需要一个 OpenZiti 覆盖网络。如果尚未预配 OpenZiti 覆盖网络,请按照快速入门操作并启动并运行网络。
先决条件 - HTTP 服务器
您需要一个 HTTP 服务器,您计划将 HTTP 客户端连接到该服务器。有许多方法可以使 HTTP 服务器联机,但在本指南中,我选择使用 docker 并部署一个非常简单的 HTTP 应用程序。服务器在连接到时会简单地打印出“docker whale”。(本指南不会教你如何安装docker,也不会教你如何安装正在监听的HTTP服务器)如果您熟悉 docker 并希望使用与此处所示完全相同的示例,只需使用以下 docker run -d --rm --name web-test -p 80:8000 openziti/hello-world
命令运行容器: 。
如果已使用本地 - Docker Compose 快速入门来预配 OpenZiti 覆盖网络,则此 HTTP 服务器已可供立即使用。
先决条件 - HTTP 客户端隧道程序
您需要在代表 HTTP 客户端的机器上安装 OpenZiti 隧道器。稍后,我们将为此隧道程序创建一个标识,并使用该标识访问 HTTP 服务器。
先决条件 - HTTP 服务端隧道程序
您需要在表示 HTTP 服务器的机器上安装 OpenZiti 隧道器。稍后,我们将为此隧道程序创建一个标识,并使用该标识访问 HTTP 服务器。
NOTE 注意
如果使用了 docker-compose 快速入门,则“专用”边缘路由器将配置为服务端隧道器,不需要部署额外的隧道器和创建标识。
先决条件 - CLI
如果您计划使用 ziti
CLI 工具,则需要下载 ziti
可执行文件并添加到path
中。如果已按照本地 - 无 Docker 快速入门进行操作,则已完成此操作,并且可执行文件将位于 ~/.ziti/quickstart/$(hostname -s)/ziti-bin/
.此外,快速入门中的 .env 文件可用于将此文件夹添加到path
中,只需获取该文件即可。例如,如果按照本地 - 无 Docker 或 Host Ziti Anywhere 快速入门操作,则应该有一个可以获取的文件。以下是我个人在获取该文件时的“本地 - 无 Docker”结果示例:
|
|
如果您使用的是基于 docker 的示例,则可以到控制器中执行, 其中 ziti
CLI 工具将可用,并且还将为您获取添加到 ziti
路径的 env 文件。
下面是一个用于 docker
执行控制器容器的示例命令:
|
|
概述Overlay配置
我们的覆盖网络准备就绪,并部署了两个隧道应用程序并可供使用,我们可以开始配置我们的解决方案。
以下是我们将遵循的步骤的概述:
- 为 HTTP 客户端创建身份并分配属性“http-clients”。在授权客户端访问 HTTP 服务时,使用此属性
- 如果未使用启用了隧道选项的边缘路由器,请为 HTTP 服务器创建标识(见下文)。另请注意,如果使用的是 docker-compose 快速入门,或者只是计划使用启用了隧道的边缘路由器,也可以跳过此步骤。
- 创建 intercept.v1 配置。此配置用于指示客户端隧道程序如何正确拦截目标流量并将其放到叠加网络上。
- 创建 host.v1 配置。此配置用于指示服务器端隧道程序如何将流量从覆盖层卸载回底层。
- 创建一个服务,将之前创建的两个配置关联到一个服务中。
- 创建一个服务策略以授权“HTTP 客户端”“拨号”代表 HTTP 服务器的服务。
- 创建一个服务策略以授权“HTTP 服务器”“绑定”表示 HTTP 服务器的服务。
- 使用 HTTP 服务器标识启动服务器端隧道程序(除非使用 docker-compose 快速入门),从而提供对 HTTP 服务器的访问。
- 使用 HTTP 客户端标识启动客户端隧道程序。
- 通过 OpenZiti 零信任覆盖层安全地访问 HTTP 服务器
我们可以使用 OpenZiti CLI 工具完成所有这些步骤: ziti
.我们也可以使用 OpenZiti 管理控制台来实现这一点。我们现在将演示两种方式。
使用 Ziti CLI 配置Overlay
在这里,您可以找到配置叠加网络所需的步骤。您可以复制/粘贴并一次运行它们,也可以慢慢运行一次一个命令以查看每个命令的工作原理。这些命令都基于类似于 bash 的 shell。如果你没有使用 bash,你需要根据你的 shell 调整这些脚本。
HTTP服务器 IP/DNS
请注意,下面的步骤 4 要求您设置名为 http_server
的变量。此变量表示 HTTP 服务器相对于您正在使用的 OpenZiti 隧道器的位置。请看上图。您需要提供运行相对于隧道程序的 HTTP 服务器的服务器的 IP/FQDN。例如,如果要使用 docker-compose 快速入门,并且要引用它附带的预部署 HTTP 服务器,则 http_server
应设置为 web-test-blue
“因为这是运行 HTTP 服务器的容器的有效名称”。
HTTP 服务器标识
请注意,下面的步骤 7 要求您设置名为 http_server_id
的变量。所有快速入门都预配启用了隧道器选项 ( -t
) 的边缘路由器。这意味着边缘路由器被配置为充当隧道器。运行 ziti edge list identities
以查找与路由器关联的身份的名称。
|
|
使用Ziti管理控制台(ZAC)配置Overlay
或者,您可以安装 ZAC 以使用 UI 管理您的网络。
测试一切正常
一旦你设置好了一切,如上面的最后一步所示 - 此时你应该能够运行 curl 语句或使用浏览器访问“http.ziti”。
核心概念
客户端
一旦你有了一个网络-你将需要一个Ziti-aware客户端来访问网络。有两种类型的客户端,根据您的需求,您可以选择使用隧道器或使用SDK来安全地访问网络。
选择您将使用哪种类型的客户端连接到网络是一个简单的过程,归结为一个问题。如果你在已经开发和部署的应用程序前面安装Ziti,你需要使用隧道器。如果您正在从头开始开发新产品,并且希望利用完全零信任解决方案,则可能需要使用SDK。
隧道器
隧道器是一种专门构建的软件,旨在将不支持Zati的应用程序连接到网络。
SDK
如果你正在构建一个新的应用程序,你有一个独特的机会选择使用Ziti SDK之一,并从一开始就创建一个真正的零信任应用程序!Ziti Edge SDK使您的应用程序能够直接发现和提供或连接到Ziti服务,而无需代理或代理。SDK使用控制器提供的边缘客户端API来验证和发现路由器和服务。然后,SDK连接到响应最快的路由器,并开始托管或连接到Ziti服务。
初始化
步骤
- 初始化-加载config.json
- 创建TUN设备
- 创建100.64.0.0网络到TUN的路由
- 初始化DNS服务
- 加载身份
- 初始化日志记录
- 连接到控制器
- 下载网络配置
- 初始化到边缘路由器的通道
- 初始化服务
- 插入DNS名称
- 为IP创建到100.64.0.0块的路由
- 收集用于ER选择的延迟信息
- 使用服务名称完成DNS初始化
- 定期检查服务或其他网络配置的更新。轮询由应用程序控制,包括桌面边缘和隧道器,在 OpenZiti 发布的软件中为 10 或 15 秒。
- 根据需要更新服务、添加或删除边缘路由器等。
注册
- 对网络实例具有管理权限的人员将创建新标识。
- Ziti 控制器返回一个 JWT,用作注册新身份的一次性令牌。
- 管理员通过所需的任何方式将 JWT 传送到端点。这是信任模型的真正引导,应该很好地定义。
- 对 JWT 进行解析,并从令牌中解析身份名称和控制器地址等信息
- 从控制器检索服务器证书。
- JWT 的签名使用控制器的公共证书进行加密验证。
- 证书颁发机构公钥通过控制器的 .well-known 终结点检索。
- CA 将作为受信任的证书添加到客户端。这是用于对网络实例中的所有证书进行签名的证书的公钥,也用于在连接时验证其他节点。
- 终结点生成证书签名请求,并将其与注册请求一起转发给控制器。
- JWT 中的令牌值 (jti) 用作控制器验证端点的唯一标识符。该令牌在创建时也由控制器持有,然后在“使用”时删除,从而在注册后将 JWT 撕毁为无用。
- 控制器验证令牌值和 CSR 中包含的信息,对证书进行签名,并将其返回到端点。
- 终结点存储签名证书。终结点现在已注册到网络,并具有识别自身和参与所需的所有证书。
服务拨号
- 如果被拨号的服务是 DNS 命名的服务,而不仅仅是一个 IP,则系统将执行 DNS 查询以解析该名称。否则,请跳到步骤 3。
- Ziti DNS 解析器将使用 100.64.0.0 范围内的 IP 进行响应,以将流量引导到软件中。
- 然后,客户端将与 SDK 建立 TCP 连接。这可以通过多种方式完成,主机上的隧道客户端、LAN 中的网关隧道或边缘路由器,也可以跳过它,并使用其中一个 SDK 打开直接套接字。 假设此示例涉及 TCP,则会发生 TCP 握手。om4 中。SDK 将从其选择中选择最佳边缘路由器来启动 fabric 电路。主要选择标准是延迟。SDK 会不断轮询它感知的边缘路由器,并监视消息传递的延迟。将选择可用于此服务的延迟最少的路由器。
- SDK 将向控制器发出拨号请求。此消息将包括正在呼叫的服务、选定的初始边缘路由器和身份验证信息
- 身份验证后,控制器将开始确定整个结构中电路的当前最佳路径。实际路由路径是使用 Dijkstra 算法计算的,类似于 OSPF 和其他 IP 路由协议。就延迟而言,该过程以成本最低的路径结束。该路径开销将添加到与服务终止符关联的静态、动态和优先开销中。优先级是热备用冗余配置中的一个配置选项,静态成本通过配置映射,动态成本是以前设置成功和失败的结果。一旦所有终止器都计算了成本,最小成本值将确定最佳路径并返回。
- 计算出最佳路径后,控制器将向边缘路由器发送请求以创建实际路径。每个边缘路由器将完成必要的步骤并做出响应。如果终端边缘路由器是组合路由器/隧道器,并且终端服务需要 TCP 连接,则将在发送成功消息之前创建此连接,以确保连接。
- 来自路由器的响应消息一旦全部接收到,就表明电路已配置好,并准备好进行通信。
- 然后,对初始边缘路由器的拨号响应开始数据流。
有许多与服务拨号相关的错误代码。消息可能超时,终端服务器可能无法响应 TCP SYN 数据包或发送 RST,终止器可能处于不可用状态等。结构电路创建过程的错误代码可在电路拨号错误代码中找到
身份
Ziti 建立在零信任的基础上。该基础的坚实支柱要求支持Ziti的网络中的所有连接都经过身份验证。身份是 Ziti 身份验证的基础。连接到 Ziti 网络的所有设备都将具有一个身份,该身份在建立连接时由发起连接的设备和接收传入连接的设备提供。Ziti 实现双向 TLS以验证连接的两端。
从概念上讲,可以认为身份与用户帐户一致。身份是存储在控制器内部的逻辑实体,用于将 X509 证书映射到特定的命名身份。身份不仅用于验证连接,还用于在 Ziti 中授权身份。有关身份授权的详细信息,请参阅策略。
创建身份
创建身份的机制受 Ziti 网络设置方式的影响,特别是 PKI 的建立方式。身份与给定 Ziti 网络中配置的 PKI 集成链接,并直接影响身份的创建和登记方式。身份通常有三种登记方法:
- 使用配置的 PKI 的一次性令牌 (ott) 身份
- 使用第三方 CA 的一次性令牌 (ott) 身份
- 第三方自动登记身份
选择登记方法
选择您的身份将使用的登记类型取决于您是否使用第三方 CA。如果网络未配置第三方证书,则唯一的选择是使用一次性令牌 (OTT) 登记方法。
每种类型的登记都是安全的,只是取决于您的实际网络设置来选择哪种类型。如果您不知道 - 只需使用一次性令牌 (OTT) 方法。如有必要,始终可以在以后重新创建身份。
一次性代币(One Time Token,OTT)
一次性令牌方法适用于所有Ziti网络。一次性令牌登记身份将在创建身份时生成令牌。然后,作为登记过程的一部分,在将来的某个时间点提交此令牌。成功登记身份后,一次性令牌将不再有效,并且不能用于再次登记同一身份。
一次性令牌以 jwt 的形式从控制器传送,令牌在创建身份后 24 小时过期。该令牌可通过 Ziti 管理控制台下载。创建用户后,可以转到“身份”页面,然后单击看起来像证书的图标以下载 .jwt 文件。
还可以使用 ziti
cli 工具为一次性令牌登记创建身份。此命令将创建一个新身份,并将 jwt 输出到所选路径。然后,您可以通过运行 enroll
命令将 .jwt 文件传输到将安装永久身份 JSON 文件的设备。
|
|
选择身份类型
The three types of identities are: 三种类型的标识是:
- User 用户
- Device 装置
- Service 服务
它们在功能上是等效的,并且具有相同的属性。您可能希望在创建身份时通过选择一种或另一种类型来表达身份的预期用途。无法更改类型。
登记身份
与 Ziti 网络建立的所有连接都利用双向 TLS,这意味着每个客户端都需要一个有效的 X509 证书,它将在连接过程中提供给 Ziti 网络。获取密钥/证书对并将其安全地呈现给控制器的过程称为“登记”。
概述
所有身份都需要向控制器登记,以便控制器可以对传入连接进行身份验证。对于每种类型的身份,此过程略有不同,并且很复杂。登记身份的最简单方法是将 Ziti Desktop Edge/Ziti Mobile Edge 用于您的操作系统。或者,您可以使用 ziti
CLI 单独执行登记,CLI 可从 GitHub 发布页面下载
一次性令牌登记 - 内部 PKI
获取已登记身份的最简单途径可能是使用一次性令牌登记流。此流利用控制器中配置的 PKI。使用一次性令牌流 - ziti
CLI 将生成私钥和证书签名请求,供控制器的内置证书颁发机构执行。
按照以下步骤使用一次性令牌登记身份:
- 创建身份
- 下载或复制 JWT - 此文件包含单机版令牌
- 运行
ziti
CLI:
用法示例
|
|
CAUTION 谨慎
ziti
CLI 的输出是永久身份配置文件,必须安全存储。此文件包含支持控制器颁发的证书的私钥。不应传输或共享此文件,也不应从计算机中移动此文件,除非您确信自己了解这样做所涉及的风险。
ziti-edge-tunnel
CLI 的示例用法**
|
|
服务
主要策略假设Ziti的一个功能是提供对“服务”的访问。服务封装了客户端在传统网络上可以访问的任何资源的定义。
服务由以下组件定义:
- Name - 服务的名称
- Termination - Ziti 仅提供对网络服务的访问,它不提供服务本身。该服务必须能够将网络流量传输到实际提供服务的任何应用程序或应用程序集群,无论该提供商是否嵌入了 Ziti,或者不知道 Ziti
- Configuration - Ziti 允许为服务存储特定于应用程序的配置。请参阅配置存储
- Authorization - 有关控制服务访问的详细信息,请参阅策略。
服务名称
Ziti 服务必须具有其 Ziti 安装的唯一名称。服务名称是客户端对服务进行寻址以使用服务的方式。由嵌入了 Ziti 的应用程序提供的服务也使用服务名称来指示正在提供的服务。
在网络上定义的服务具有几乎无限的“命名空间”,可用于识别服务。Ziti 服务将由一个名称定义,并且该名称已向控制器注册。声明后,可以直接从Ziti感知客户端按名称对服务进行寻址。这意味着实际上有无限数量的名称可用,而无需全局 DNS 注册。分配的名称对于网络是唯一的,应用程序开发人员可以完全控制服务名称。
服务终端
在 Ziti 中,服务终端是指通过 Ziti 的网络流量如何到达实际提供服务的应用程序(或应用程序集群)。在应用程序上有几种基本终端服务方法。
对于每种类型的终端,都需要考虑一些权衡。
- 您是否需要端到端零信任?如果是,则要求客户端和服务器都具有 Ziti 身份,并且可以安全地使用预设的证书进行连接。
- 您希望Ziti提供端到端加密吗?开发人员始终可以在 Ziti 提供的连接性之上提供自己的端到端加密,但并非所有服务终止模式都允许 Ziti 为您端到端加密流量。
- 您希望您的服务器应用程序对非零信任客户端的可访问性如何?通过正确的配置,应用程序可以完全处于“黑暗”状态,这意味着它们不会侦听连接。
SDK 嵌入式应用程序
服务器应用程序可以嵌入Ziti Edge SDK。应用程序将具有已注册的标识和预设的证书。这有几个优点:
- 应用程序和 Ziti 之间的连接将使用证书进行保护。这在基于 SDK 的客户端和基于 SDK 的服务器之间实现了真正的零信任和端到端加密连接。
- 有了身份,服务器应用程序就可以参与 Ziti 安全模型。这意味着您可以控制应用程序可以提供哪些服务,并根据需要撤销访问权限。您还可以控制应用程序可以连接到哪些边缘路由器。
- 应用程序将是“黑暗”的。该应用程序不会监听传入的网络连接,而是将与一个或多个 Ziti 边缘路由器建立传出的安全连接。然后,它将通过这些安全连接接收网络请求。
这种方法的缺点,特别是对于现有应用程序,是必须重构应用程序才能使用 Ziti Edge SDK。根据所使用的语言和框架,所需的工作量可能从更新几行代码到从头开始为尚不受支持的语言编写新的 SDK。
代理应用程序
对于嵌入 SDK 没有意义的应用程序,基于 Ziti SDK 的代理可以提供对应用程序的访问。通常,代理可能采用 sidecar 的形式,并与应用程序位于同一位置。这样可以最大程度地减少攻击面。关于这种方法,有几点需要注意。
- 该应用程序不会完全黑暗。它必须接受来自代理所在的任何位置的连接。代理可能与应用程序位于同一位置,因此攻击面可能很小。然而,微小仍然大于零。
- 同样,客户端和代理之间的流量可以加密,但代理和应用程序之间的流量不会被 Ziti 端到端加密所涵盖。如果客户端和服务器根据客户端和服务器实现者的判断建立自己的加密,则它仍可能被加密。
- 通过代理,应用程序仍然由身份表示,因此参与策略。
使用代理进行服务器端终端的服务可能需要额外的配置,以便代理应用程序知道如何连接到服务器应用程序。下面将详细讨论服务配置。
Ziti 路由器终端服务
路由器还具有连接到提供服务的应用程序的能力。这种方法有其自身的优点和缺点。
- 与代理方法一样,应用程序不能完全是黑暗的。该应用程序必须可从 Ziti 路由器访问。
- Ziti 目前只提供两个 SDK 应用程序之间的端到端加密。在路由器上终止的会话不能被Ziti进行端到端加密。数据仍可能由客户端和服务器进行端到端加密,但这取决于客户端和服务器实现者。
总结
Termination Type | End-to-end Zero Trust | Managed by Policies | Ziti Provided End-to-end encryption Ziti | Dark Server Application |
---|---|---|---|---|
SDK Embedded | Yes | Yes | Yes | Yes |
SDK Based Proxy | No, only to proxy | Yes (via Proxy) | Only to proxy. If desired, full end-to-end must be done externally | No. Can be relatively locked down, though |
router | No | No | No. If desired, end-to-end must be done externally | No. Can be relatively locked down, though. |
终端
终止端表示一种连接到特定服务的特定服务器应用程序的方法。
对于基于 SDK 的服务器(无论是嵌入式服务器还是代理服务器),这些服务器会在应用程序连接时自动创建,并在应用程序断开连接时删除。
对于路由器终端服务,必须手动创建。手动创建终结器时,必须指定以下内容。
- 将连接到服务器应用程序的路由器
- 绑定。这表明路由器上的哪个Xgress组件将处理建立连接。对于基于tcp的应用程序,这通常是 transport ,对于基于UDP的应用程序,这通常是 udp
- 有关Xgress框架的更多信息,请参阅ziti-fabric文档
- 要连接到的地址。这通常采用以下形式:
<protocol>:<host or ip>:<port>
- 示例:
tcp:localhost:5432
- 示例:
可用性和扩展
服务可以使其具有高可用性和/或水平可扩展性。服务器应用程序需要关注两种类型的可用性。
路由器 HA/扩展
第一种是允许多个路由器连接到单个应用程序。
Multiple Routers 多个路由器
这可确保即使路由器出现故障或路由器和服务器应用程序之间存在网络分区,应用程序仍能够为请求提供服务。它还将有助于确保路由器层不会成为瓶颈,因为可以根据需要添加更多路由器以扩展连接。最后,它为应用程序提供了多个网络路径。这使得智能路由可以在网络条件发生变化时选择最佳路由。
应用程序 HA/扩展
第二个是应用程序的可用性和/或可扩展性。通常会有多个服务应用程序实例在运行,用于故障转移或负载均衡部署。
Failover Deployment 故障转移部署
水平规模部署
Xt
所有类型的可用性和可伸缩性都涉及多个终端器。HA 故障切换设置与负载均衡水平规模设置的区别在于如何将新会话分配给终端器。对于故障转移,我们希望会话始终转到同一服务实例。对于水平扩展,我们希望在可用实例之间对会话进行负载均衡。
fabric包含一个名为可扩展终端器 (eXtensible Terminators,Xt)的框架,该框架允许定义终端器策略,并定义终端器策略和外部组件如何与智能路由集成。终端器选择的一般流程如下:
- 客户端请求新的会话
- 智能路由会查找会话的所有活动终端器(活动意味着终端器的路由器已连接)
- 智能路由会计算每个终端者的成本,然后将终端者策略提供一份终端者列表,并按照从低到高的顺序排列其成本
- 该策略返回应使用的终端符
- 使用该路径创建新会话。
策略通常通过调整终端成本来发挥作用。然后,选择算法仅返回智能路由提供的最低成本选项。
成本
有许多元素可以为智能路由成本算法提供信息。
路线成本
从发起路由到终结器路由器的路由成本将包含在终结器成本中。此成本可能会受到链接延迟和用户确定的链接成本等因素的影响。
静态成本
每个终端器都有一个静态成本,可以在创建终端器时设置或更新该成本。SDK 应用程序可以在调用 Listen 操作时设置终端器成本。
优先级
每个终端都有一个优先级。有三个优先级: required
、 和 default
failed
。
智能路由将始终将优先级较高的终端排名高于具有较低优先级杠杆的终端。因此,必需的终端将始终是第一个,默认的第二个和失败的第三个。优先级可用于实施 HA。主要设备将标记为必需,辅助设备将标记为默认设备。当通过某些内部或外部启发式方法确定主会话已关闭时,它将被标记为失败,新的会话将转到辅助会话。当主服务器恢复时,它可以恢复到 Required。
动态成本
每个终端还有一个动态成本,该成本将相对于其优先级上下移动终端。这种成本可能由策略驱动,也可能由外部组件驱动。策略可能会使用打开的会话的活动数量或拨号成功和失败来驱动动态成本。
有效成本
每个终端都有关联的优先级和动态成本。这可以减少到单一成本。成本算法可确保不同优先级的终端不会重叠。因此,标记为失败且动态成本为 0 的终端的计算成本始终高于默认优先级和动态成本最大值的终端的计算成本。
策略
fabric目前提供四种策略实现。
smartrouting
这是默认策略。它始终使用成本最低的终端。它按以下方式驱动成本:
- 费用与打开的会话数成正比
- 拨号失败会增加成本
- 拨号成功降低了成本,但与以前因失败而推高的成本一样多
weighted
此策略以与 smartrouting
策略相同的方式驱动成本。但是,它不是总是选择成本最低的终端,而是对优先级最高的所有终端进行加权随机选择。如果一个终端的成本是另一个终端的两倍,那么它被选中的频率应该大约是原来的一半。
random
此策略不会更改终端权重。它对所有优先级最高的终端进行简单的随机选择。
服务配置存储
Ziti服务配置(以下简称“配置”)可以与服务相关联,为该服务正在交付的应用程序提供元数据。
配置通过 edge-management API 创建和更新,并由 edge SDK 通过 edge-client API 使用。Configs 和 Config Types 是 Ziti 实体。每个 Config 都是 Config Type 的一个实例。
概述
配置存储有几个组件:
- 配置类型
- 配置类型定义了一种配置类型,包括配置数据必须符合的可选JSON模式。
- 配置类型具有以下属性:
- 配置类型名称
- 一个可选的 JSON 架构,用于验证该类型的配置
- 标准边缘实体属性:id、tags、createdAt、updatedAt
- Configs
- 配置具有以下属性:
- 配置名称
- 配置数据,它是任意JSON数据,只要它符合类型模式(如果指定)
- 标准边缘实体属性:id、tags、createdAt、updatedAt
- 配置具有以下属性:
- 服务
- 每个服务可以链接到多个Configs。对于每个配置类型,服务可以有一个链接的配置。
- 身份
- An identity may have a Config specified for a given service and Config. This will override the service’s linked Configs.
此配置模型具有以下属性:
- 不同的应用程序可以对同一服务有自己的配置
- 应用程序可以为自己提供多个配置类型,
- 有用于拦截(客户端)端和托管(服务器)端的隧道器配置类型
- 由于一个应用程序可以支持多个配置类型,因此应用程序可以根据需要更改其配置类型
隧道器配置类型
Ziti隧道器本身就是SDK应用程序,因此它们可以作为如何使用配置数据的示例。
- 隧道器需要知道他们在拦截(客户端)端拦截的服务的IP/DNS和端口
- 隧道需要知道在主机(服务器)端转发到目标服务器的位置
Ziti提供了一些隧道器配置类型。
最相关的配置类型:
intercept.v1
: 隧道服务器将自身配置为特定服务的代理host.v1
: 描述隧道器托管的Ziti服务的目标服务器
其他配置类型:
host.v2
:一组host.v1
配置ziti-tunneler-client.v1
:intercept.v1
的前身ziti-tunneler-server.v1
:host.v1
的前身
隧道器配置类型的模式在GitHub中维护
Tunneler 配置类型 host.v1
Config Type host.v1
的 Config 配置托管 Ziti 隧道器,以将连接转发到特定 Ziti 服务的目标服务器。
例子
此配置将 Ziti 服务流量转发到称为 tcp:localhost:54321
的服务器。从运行 Ziti 隧道器的设备的网络角度来看,服务器必须在该目的地可访问。
|
|
此 Config 不是静态目标端口,而是将 Ziti 服务流量转发到发起客户端连接到的同一TCP 端口,只要该端口在允许的端口范围内即可。
|
|
此配置不是静态目标地址,而是将 Ziti 服务流量转发到发起客户端连接到的同一地址,只要该地址位于允许的地址列表中即可。
|
|
架构参考
此隧道器配置类型的 JSON 架构在 GitHub 中维护
Tunneler 配置类型 intercept.v1
Config Type intercept.v1
的 Config 将拦截 Ziti 隧道器配置为特定 Ziti 服务的代理。
例子
此配置指示隧道器拦截任何带有目的地 tcp:acme.example.ziti:5000
的传出流量。拦截隧道器提供了一个DNS名称服务器,用于解析授权的Ziti服务的域名。
|
|
此 Config 不仅具有被拦截流量的 Ziti 域名目的地 acme.ziti
,而且还具有通配符域和 IP 子网。此外,还有一系列目标端口,如果目标地址也匹配,则所有数据包都将被拦截。
|
|
架构参考
此隧道器配置类型的 JSON 架构在 GitHub 中维护
使用配置数据
配置数据可以直接获取,但通常由应用程序通过 SDK 使用。当 SDK 进行身份验证时,它将指示它可以处理哪些配置类型。然后,在列出服务时,SDK 将在线接收配置数据。这也可以从 CLI 完成。
如果我们已按如下方式设置服务 ssh
:
|
|
SDK 将以特定于语言的方式呈现此配置。通过在列出服务时指定配置类型,您可以从 SDK 中查看 SDK 正在处理的数据。
NOTES 笔记
- 您可以指定
all
查看所有配置数据。 - 除了包含嵌入配置数据的
config
模块外,还有一个configs
部分按 ID 列出了所有关联的配置。无论请求哪种配置类型,所有关联的配置都将始终在此处列出。
|
|
管理
管理配置
下面是一个 JSON 架构,以隧道器客户端配置为模型。
|
|
将架构放在名为 example-config-type.json
的文件中,您可以使用它创建名为 my-app 的配置类型。
|
|
现在,您可以创建此类型的配置
|
|
最后,您可以在创建服务时引用此内容。
|
|
如果特定站点希望在不同的端口上使用 SSH,您可以创建不同的配置
|
|
然后,可以将与该站点上的隧道操作员对应的身份配置为使用该配置。
|
|
如果不再需要替代,也可以删除它们。
|
|
零信任模型
所有 OpenZiti 部署架构都可以按三种类型的零信任边缘访问安全模型进行分类。其中许多最初将与其中至少 2 个重叠,尤其是brownfield棕地部署。这为客户提供了很大的部署选项灵活性,具体取决于他们最终达到 ZiTi 应用程序访问安全模型(即最安全)的旅程中的位置。
应用程序访问 (ZTAA)
零信任在应用程序之间维护,在应用程序的终端中加密
下面介绍应用程序访问的各种边缘部署。在所有情况下,都将部署控制器和至少 2 个公共边缘路由器以实现冗余。Ziti Fabric连接是在所有边缘路由器之间建立的,但不是客户端/SDK之间建立的。公共边缘路由器将在专用边缘路由器和/或客户端/SDK之间提供连接。
NOTE 注意
- 公共边缘路由器的推荐配置部署是仅启用 Ziti Edge,而私有边缘路由器的配置部署是启用 Ziti Edge,如果零信任域在私有边缘路由器结束,则需要 Tunnel 选项。
- Acronyms used in this article:
本文中使用的首字母缩略词:
- ZDE - Ziti Desktop Edge ZDE - Ziti桌面边缘
- ZME - Ziti Mobile Edge ZME - Ziti移动边缘
- ZET - Ziti Edge Tunnel ZET - Ziti边缘隧道
-
Application to Application A Deployment 应用程序到应用程序 A 部署
详情
- 客户端已集成 SDK。
- 应用程序已集成 SDK。
优势
- 应用程序到应用程序加密
- 无需额外路由
- 无需额外的 DNS 条目
决定时要考虑的事项
- SDK 和应用程序源代码可用性
-
Application to Application B Deployment 应用程序到应用程序 B 部署
详情
- 客户端已集成 SDK
- 应用程序集成了 SDK
优势
- 应用程序到应用程序加密
- 无需额外路由
- 无需额外的 DNS 条目
决定时要考虑的事项
- SDK 和应用程序源代码可用性
-
Application to Application C Deployment 应用程序到应用程序 C 部署
详情
- 客户端已集成 SDK
- 应用程序已集成 SDK
优势
- 无需部署专用边缘路由器
- 应用程序到应用程序加密
- 无需额外路由
- 无需额外的 DNS 条目
决定时要考虑的事项
- Fabric未扩展到应用程序网络
- SDK 和应用程序源代码可用性
-
应用程序到主机 B 部署
详情
- 客户端已集成 SDK
- 应用程序已部署客户端软件 (ZET)
优势
- 应用程序到主机加密
- 无需额外路由
- 无需额外的 DNS 条目
决定时要考虑的事项
- 软件必须部署到应用程序服务器
- SDK 和应用程序源代码可用性
-
应用程序到主机 B 部署
详情
- 客户端已集成 SDK
- 应用程序已部署客户端软件 (ZET)
ADVANTAGES 优势
- 应用程序到主机加密
- 无需额外路由
- 无需额外的 DNS 条目
决定时要考虑的事项
- 软件必须部署到应用程序服务器
- SDK 和应用程序源代码可用性
-
应用程序到主机 C 部署
详情
- 客户端已集成 SDK
- 应用程序已部署客户端软件 (ZET)
优势
- 无需部署专用边缘路由器
- 主机加密的应用程序
- 无需额外路由
- 无需额外的 DNS 条目
决定时要考虑的事项
- Fabric未扩展到应用程序网络
- SDK 和应用程序源代码可用性
-
应用程序到路由器 A 部署
详情
- 客户端已集成 SDK
- 应用程序位于专用路由器后面
优势
- 无需将任何软件部署到应用程序服务器
- 无需额外路由
- 无需额外的 DNS 条目
决定时要考虑的事项
- 安全性较低,从专用路由器到应用程序的连接不受保护
- SDK 和应用程序源代码可用性
-
Application to Router B Deployment 应用程序到路由器 B 部署
详情
- 客户端已集成 SDK。
- 应用程序位于专用路由器后面
优势
- 无需将任何软件部署到应用程序服务器
- 无需额外路由
- 无需额外的 DNS 条目
决定时要考虑的事项
- 安全性较低,从专用路由器到应用程序的连接不受保护
- SDK 和应用程序源代码可用性
主机访问 (ZTHA)
零信任在应用程序主机之间维护,在应用程序主机的终端中加密
网络接入 (ZTNA)
零信任仅在Ziti私有边缘路由器之间维护,在Ziti私有边缘路由器的终端中加密
数据流解释器
本解释器介绍了如何在 OpenZiti 网络中建立数据流。
基线
此图显示了示例网络的组件。
它包含以下组件:
-
一个OpenZiti 控制器
两个可通过公共互联网使用的 OpenZiti 路由器
-
两个专用网络,每个网络包含一个路由器和一个应用服务器
- 应用程序服务器正在提供相同的应用程序。有多个服务器,因此负载可以在它们之间分散。它们位于不同的区域中,以确保即使数据中心不可用,也可以访问应用程序。
-
一个 SDK 应用程序,它想要访问由应用程序服务器托管的应用程序
控制通道
当路由器启动时,它将尝试与其配置文件中的控制器建立连接。这样就建立了控制平面,允许控制器根据需要更新路由器状态,并允许路由器向控制器报告更改、指标和事件。
数据链接
一旦路由器连接到控制器,控制器将通知其他路由器的路由器,以及有关这些路由器是否以及如何侦听数据链路连接的信息。然后,路由器将尝试与其他路由器建立数据链路,以便它可以参与数据网格。
终结器/最后一跳
数据链路建立路由器间连接,但仍需要一种方法来建立与应用服务器的连接。服务定义本身并未指定应如何连接到应用程序服务器。与应用程序服务器的连接由终结器处理。
有三种常见的方法可以完成此操作。
Static Terminators
静态终结器可以由 OpenZiti 管理员创建。终结器将指定要拨打的地址。静态创建的终结器将一直存在,直到它们被删除或其相关服务或路由器被删除。
SDK Hosted
当 SDK 应用程序托管(或绑定,用 OpenZiti 术语来说)服务时,它将首先连接到一个或多个边缘路由器。然后,它可以请求这些边缘路由器代表其创建终结器。当 SDK 应用与边缘路由器断开连接时,终结器将自动清理。
SDK 应用程序可以自行处理传入连接,或者,如果它充当反向代理,它可能会桥接到另一个应用程序服务器的连接。OpenZiti 隧道器应用程序可以做到这一点, host.v1
并将使用 or host.v2
配置来定义连接转发的方式和位置,以及要运行的健康检查类型。
Edge Router Hosted
在隧道器模式 (ER/T) 下运行的边缘路由器也可以通过充当反向代理来托管服务。他们还将使用 host.v1
and host.v2
配置,与基于 SDK 的隧道程序相同。ER/T 将在创建、更新或删除服务、配置和策略时创建和删除终结器。
客户端连接
当 SDK 想要连接到 OpenZiti 托管服务时,它将启动以下事件序列:
- 向控制器进行身份验证
- 为所需服务创建会话
- 连接到一个或多个边缘路由器
- 向选定的边缘路由器发送拨号请求
- 边缘路由器将向控制器发送创建电路请求
- 控制器将找到成本最低的路径
- 控制器将向路径的非终端元素发送路由更新
- 控制器将指示终端路由器拨打服务
- 一旦电路建立起来,数据就可以开始流动了
认证
作为第一步,必须向控制器验证 SDK。成功身份验证的结果是 API 会话。SDK 将使用 API 会话向控制器发出其他请求,并向边缘路由器进行身份验证。为了使边缘路由器能够验证连接 SDK 的 API 会话,控制器必须在创建每个新的 API 会话时通知路由器。
API 会话可以扩展,因此通常可以在应用程序的生命周期内使用单个 API 会话。如果应用程序在很长一段时间内无法访问控制器,则可能需要新的 API 会话。
创建会话
SDK 现在必须创建一个会话。创建 Session 时,控制器将验证 SDK 使用的身份是否具有访问服务的权限。控制器还将查看哪些边缘路由器可用于访问会话。边缘路由器集将与会话令牌一起返回。
连接到边缘路由器
返回的 Session 包含可用于此服务的边缘路由器,以及每个路由器侦听 SDK 连接的一个或多个地址。SDK 将连接到边缘路由器,并使用连接速度最快的路由器。边缘路由器连接不是针对每个服务,而是由所有服务共享。如果已建立连接,则 SDK 将优先选择延迟较低的连接。
连接是通过相互 TLS 建立的。SDK 还将向边缘路由器提供 API 会话令牌,允许它们验证连接。当 API 会话无效时,将通知边缘路由器,并且与该 API 会话关联的连接将终止。
拨打服务
SDK 将选择一个边缘路由器,并向其发送所需服务的拨号请求以及会话令牌。所选的边缘路由器称为启动路由器。边缘路由器会将其转换为对控制器的“创建电路”请求。控制器将选择一条路径,并向路径中的路由器发送消息,以便它们可以更新其路由表和/或根据需要连接到应用程序服务器。
将根据该服务上可用的终结器的成本,加上从发起路由器到终结器路由器的链路的成本来选择路径。路径中的最后一个路由器称为终端路由器。
- 路由器成本可以通过管理 API 进行设置。此外,还有一个可配置的最低路由器成本。最低成本将防止路径添加不必要的跃点或在两个相似路径之间跳动。
- 链路成本目前基于链路的往返延迟
- 终结器具有静态成本,可以通过管理 API 来管理静态终结器,或者通过 SDK 来管理动态终结器。
- 终结器也具有动态成本。终结器上的电路越多,成本就越高。随着电路被拆除,成本也会回落。拨号失败也会暂时提高动态终结器成本。
已建立的电路
一旦建立了到应用程序服务器的路由和连接,就建立了电路。控制器通知启动路由器,数据现在可以在 SDK 和应用服务器之间流动。