html
如果你对自托管产生了热情，你可能会问的一个问题是：我如何为我的自托管应用启用安全的远程访问？如果你还没有想到这个问题，现在是时候开始考虑了，因为你的家庭网络很容易被攻击，而你希望获得尽可能多的安全性。这与基础设施无关：无论你使用的是Kubernetes、Docker，还是运行更传统程序的服务器，加密远程访问（最好有身份验证）的问题始终存在。
你可能会问的一个问题是：我如何为我的自托管应用启用安全的远程访问？
这是在你网络外部的情况，但在你的网络内部，客户端或节点之间的连接呢？当一个客户端在你的边界保护后被攻陷时，你该如何处理呢？因为没有人会在每对潜在客户端之间设置防火墙。你不会这样做，但如果从零信任的角度出发，比如使用Cloudflare Access（包括隧道），或者Firewalla如何设置Wi-Fi网状网络，你可以获得一种安全的方式来访问单个服务，而不需要一个全面的VPN。
我最近在研究一个完全自托管的解决方案，它的理念与谷歌的BeyondCorp相似，所有对服务的访问都是基于用户及其设备的上下文线索进行身份验证、授权和加密，而不是基于IP地址或设备位置。它叫做Octelium，是开源的、自托管的，充满潜力，但略显技术性。
什么是Octelium，我为什么要使用它？
这个多功能访问平台非常强大
远程访问服务一直是一个问题，需要在安全性、可用性、速度以及各种设备和协议之间找到平衡。大多数解决方案都是建立在信任基础上的——授权用户或设备登录网络，获得他们可以查看的资源的访问权限。但如果这个用户被攻陷了，会发生什么呢？整个网络都处于风险之中，这就是零信任架构发挥作用的地方。
Octelium的零信任设计通过身份感知代理（IAP）来管理对任何资源的私有和公共访问
Octelium的零信任设计不是盲目信任已登录的用户，而是通过身份感知代理（IAP）来管理对任何资源的私有和公共访问。它建立在Kubernetes之上，以实现可扩展性和可用性，但如果需要，可以迁移到任何编排/容器化平台。它支持无密钥访问，无需暴露API密钥、访问令牌、密钥或其他长期秘密，并具备基于上下文和身份的应用层访问控制。
一些用例包括：
- 统一的零信任网络访问： 可以看作是 Cloudflare Zero Trust、Google BeyondCorp、Fortinet 等的替代方案
- 现代远程访问 VPN： L7 识别的解决方案，结合上下文感知的访问策略，提供无客户端、无密钥的访问，使用 WireGuard/QUIC 隧道
- 安全隧道： 可编程的反向代理和安全隧道实现，类似于 ngrok 或 Cloudflare Tunnel
- API 网关： 安全的 API 网关，负责微服务的路由、访问、部署和扩展
- 自托管 PaaS： 为容器化应用提供安全或匿名的公共托管
- AI 网关： 安全访问任何 LLM，具有基于身份的访问控制和路由
- MCP 网关： 用于创建程序到程序的链接，以便您的 AI 模型可以链接到 MCP 或 Agent2Agent 架构
- Kubernetes 入口： 高级 K8s 入口和负载均衡器，从任何地方路由到任何可远程访问的内部资源（即：不仅限于同一集群）
- 家庭实验室： 安全地远程访问每个自托管的家庭实验室服务，无论是否在 NAT 后面，并提供微服务、网站、API、数据库或本地 LLM 的安全部署平台
我正在将其用于零信任隧道
但它可以做得更多，更多
我必须承认，前几个小时阅读文档和设置第一个集群有些令我感到压力。我对 Kubernetes 相对较新，虽然 Octelium 将其作为可扩展性的基础架构，但编排层和网络层是不同的。请注意，如果您像我一样在 VPS 上托管它，您需要自己的域名才能使用它，但如果您只是本地使用，可以将 localhost 作为域名。
我花了一些时间才启动起来，因为我漏掉了域名的 www 部分的 A DNS 记录，这在 Cloudflare 中需要设置，但文档中没有提到。我也相对慢，因为我需要熟悉命令，并且几乎每个设置阶段都需要阅读额外的文档页面，因为这对我来说（大多数情况下）是新的。安装 certbot 来获取 Let's Encrypt TLS 证书其实挺简单的，然后就进入身份验证和用户管理。
添加 GitHub OAuth 只是创建一个 OAuth 应用程序在我的 GitHub 账户中，然后添加密钥：
octeliumctl create secret github-client-secret
稍微写一点 YAML 后，我就可以通过我的域名用 GitHub 凭据登录 Octelium。我喜欢使用现有的 OAuth 或 OpenID 身份提供者，因为这样我就不需要存储更多的密钥。
要将服务暴露给我的认证用户需要更多的设置，但一种方法是使用 BeyondCorp：
kind: Service
metadata:
名称：
规格：
模式：
是否公开：
配置：
上游：
URL： http://k8s-dashboard.svc.local:8080
我现在可以使用 https://k8s-dashboard.mydomain 来访问那些受保护的服务，前提是我的用户账户有权限查看这些服务。
而且有件很酷的事。我现在可以在 VPS 上利用 Octelium 的 Kubernetes（确切来说是 K3s）基础设施来部署任何容器化服务，就像我在运行没有身份管理层的 Kubernetes 一样。这只是多了一些 YAML，任何习惯用 Docker 的人都能轻松上手。
以下是示例代码：
kind: Service
metadata:
name: nginx
spec:
mode: HTTP
配置:
上游:
容器:
端口: 80
镜像: nginx:latest
哦，还有一个很实用的小技巧。假设我在 NAS 上运行服务，但我不想把它们开放到互联网。你可以用 你的用户名 将本地可访问的 URL 添加到不同的 services.yaml 文件中来共享这些服务。你甚至可以用多个用户来提供相同的服务，Octelium 会为你自动进行负载均衡。这是一种全新的自托管服务共享方式，虽然看起来复杂，但其实设置起来非常简单。
无密码访问很酷
我一直不喜欢在 SSH 窗口里输入密码，或者把 API 密钥作为请求头的一部分传递，或者使用其他不安全的明文认证方式。Octelium 使用一种叫 Vigil 的身份感知代理 (IaP)，它会拦截用户请求，把请求传递给 Octovigil（由它来判断用户是否可信），然后动态地将应用层凭据注入请求中。这会把你的长期访问令牌、API 密钥、密码和其他秘密安全地锁在 Octelium 的秘密保险库里。
只要我的用户拥有正确的权限，这些加密的凭据就能让我登录到我试图访问的服务，无需SSO或输入密码。不再担心密码泄露或重用，不再需要密码管理器，这一切都由IaP层处理，我真是太喜欢了。
Octelium改变了我连接家庭实验室的方式
我可以深入探讨更多内容，从使用与电子邮件、协议或服务匹配的内联访问控制策略以代码形式，到统一云服务和本地服务，但我仍在这里探索高级功能。Octelium并不是Cloudflare Tunnel的替代方案，而是Cloudflare Zero Trust平台的替代方案，但它也在实现WireGuard/QUIC连接以及方便地从相同软件架构部署容器化服务。我觉得，最好的部分是它要么是简单的CLI命令，要么是YAML配置文件，我不需要去学其他编程语言。
热门跟贴