论远程零信任访问的搭建(2)Sidecar容器的使用

1286 字
6 分钟
论远程零信任访问的搭建(2)Sidecar容器的使用

前言#

我们终于搭建好了Headscale控制平面和UI,并解决了统一登陆,现在零信任网络已经完全可以使用了

我们需要完成最后一步:把服务添加进来

在这里就是我的AquaDX Sidecar容器

SideCar的使用#

如果你不需要自己搭建控制节点的话直接搭Sidecar就好

TailScale官方提供了Operator的方式自动化去代理容器流量 自动设置之类的

但我觉得不是很有必要,因为我们暂时有且只有一个要代理

而且我们也不是很确定Operator是否支持自定义控制节点,等下白折腾不是炸刚了

后续去看了下,确实是不支持Headscale的,因为他需要Oauth密钥,Headscale并未支持

Github上有Headscale的Operator,但那个已经三年没更新,作者已经弃坑了

我自己下下来Make都过不了

QQ_T4kcDZvX5b.png
QQ_T4kcDZvX5b.png

第一次见啥都没动Make都能空指针

反正不管怎么说,手动搭一个sidecar就好

Tailscale作为Sidecar启动的配置#

由于Tailscale需要权限创建Secret去持久化自己的状态数据,因此Sidecar关键的在于以下几个点

  • 绑定TailscalePod更改同命名空间Secret权限的ServiceAccount,他需要Secret去持久化自己的状态数据
  • 增加NET ADMIN的capabilitiy
  • Sidecar环境变量应为TS_USERSPACE=false,否则工作在USERSPACE下不是标准的sidecar做法 后面踩坑就是因为这个
  • 为了Aqua能通过自检,要把容器的DNS给MagicDNS解析

为了统一和方便,以下Tailscale的Sidecar容器简称为Sidecar

首先实现第一点,给予他ServiceAccount

Role设置如下:

apiVersion: v1
kind: ServiceAccount
metadata:
name: tailscale
namespace: aqua-dx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tailscale-role
namespace: aqua-dx
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["events"]
verbs: ["get", "create", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tailscale-rolebinding
namespace: aqua-dx
subjects:
- kind: ServiceAccount
name: tailscale
namespace: aqua-dx
roleRef:
kind: Role
name: tailscale-role
apiGroup: rbac.authorization.k8s.io

然后记得增加serviceAccount的绑定

spec:
template:
spec:
serviceAccountName: tailscale

然后给予他Capabilities

chrome_HzVtfeomW6.png
chrome_HzVtfeomW6.png

然后设置DNS

chrome_DfVXJcPrRz.png
chrome_DfVXJcPrRz.png

整个容器组优先使用MagicDNS,然后才是coreDNS

coreDNS一般是固定的,照着填写就好

然后就翻车了

chrome_N1lzzymyfl.png
chrome_N1lzzymyfl.png

思考一下,因为我们的Aqua需要解析集群内的地址去访问数据库的Service 同时需要解析MagicDNS去进行80端口的自检

然后Sidecar需要解析集群内地址去更新自己状态的Secret

但如果让Sidecar更改dns,Aqua就翻车了

我们需要自己维护一份DNS给他们用

妈的早知道用Operator了

我在尝试了各种方法之后,我发现

我的Tailscale一直是在Usernamespace下跑的

我是大傻逼(

简而言之,既然需要用Sidecar接管整个容器的网络流量,不仅要给NET_ADMIN权限

但是不要给他hostNetwork的权限 让这两个容器处于独立的网络空间

还要让Sidecar的TS_USERSPACE=false

只有这样Tailscale才会修改两个容器的TUN,只有这样两个容器才真正同属于一个网络空间

之前Aqua一直通不过自检就是因为这个

关键配置如下:

chrome_XKFbLyh9Ly.png
chrome_XKFbLyh9Ly.png

chrome_SrMVdw6AqX.png
chrome_SrMVdw6AqX.png

选择ClusterFirst之后不需要添加CoreDNS的IP,等于说我们只需要默认DNS加一个Tailscale的MagicDNS即可

我们让Tailscale的—accept-dns为false,避免他修改Pod的DNS导致Aqua无法解析数据库的Service域名

因为我们用MagicDNS,所以Aqua的配置我们可以写虚拟局域网的内部域名

比如aqua.tailscale.lan 在控制平面可以随便改

chrome_kWEIEwvfVZ.png
chrome_kWEIEwvfVZ.png

能通过80端口的自检就是没问题了,这意味着Aqua能用MagicDNS解析到自己

当然在游戏上也要写相同的域名,否则会ALLS Authentication BAD()

后记#

这个AquaDX的迁移是我拖了最久的一件事

主要也是懒

在这过程中还是学到了点东西 也算对Sidecar有了一个较为深入的理解

其实我可以少走很多弯路,我们可以看一下Tailscale的example

make proxy之后会输出一个yaml 我这里贴上来

apiVersion: v1
kind: Pod
metadata:
name: proxy
spec:
serviceAccountName: "tailscale"
initContainers:
# In order to run as a proxy we need to enable IP Forwarding inside
# the container. The `net.ipv4.ip_forward` sysctl is not allowlisted
# in Kubelet by default.
- name: sysctler
image: "ghcr.io/tailscale/tailscale:latest"
securityContext:
privileged: true
command: ["/bin/sh"]
args:
- -c
- sysctl -w net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
resources:
requests:
cpu: 1m
memory: 1Mi
containers:
- name: tailscale
imagePullPolicy: Always
image: "ghcr.io/tailscale/tailscale:latest"
env:
# Store the state in a k8s secret
- name: TS_KUBE_SECRET
value: "tailscale"
- name: TS_USERSPACE
value: "false"
- name: TS_DEBUG_FIREWALL_MODE
value: auto
- name: TS_AUTHKEY
valueFrom:
secretKeyRef:
name: tailscale-auth
key: TS_AUTHKEY
optional: true
- name: TS_DEST_IP
value: ""
- name: TS_AUTH_ONCE
value: "true"
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_UID
valueFrom:
fieldRef:
fieldPath: metadata.uid
securityContext:
privileged: true

基本上的话就是privileged: true 要给他root权限 我是把userid设为0了 别的差不多了

也算是填了一个不大不小的坑

完事 睡觉

不过看起来MuNet准备替换Aqua了 看看后续发展怎么样 实在不行我打算自己维护一个服务器了

之前Artemis迁移折腾我半天 Artemis更新又严格遵循N-1 自己维护得了

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

论远程零信任访问的搭建(2)Sidecar容器的使用
https://cainongw.github.io/posts/remote-access2/
作者
Cainong
发布于
2025-11-01
许可协议
CC BY-NC-SA 4.0
相关文章 智能推荐
1
论远程零信任访问的搭建(1)Headscale的搭建
HomeLab 前言 在迁移AquaDX到K8s集群中的时候,我需要给别人远程访问的权限 我的服务器是不公开的 我并不打算公开出去给所有人用 之前用的ZeroTier因为几个原因我决定废弃了: 他把路由选项从控制面板中删除了,改为要付费的 他要修改宿主机的tun配置来实现二层上的网络代理,这在K8s中是不允许的 打洞策略太迷 即使能UPnP直连或者IPv6直连有时候他还是中
2
开源WAF 雷池在K8s上的搭建
HomeLab 前言 换了条宽带,现在我拥有动态的公网IPV4地址了 我打算暴露一些服务出去以便我使用 例如Openlist RDP Gitlab 但是 我并不打算公开 我只打算自己使用 前面我们搭建了Authentik作为SSO单点登录,刚好雷池WAF支持通过单点登录鉴权来允许访问 这样我就可以实现把ESXi挂到公网 但是不登录都过不了防火墙
3
记一次filebrowser的搭建
Kubernetes 起因 我以为这个就是写个Deployment然后挂载NFS就得了 本来都不打算写blog的 结果后面发现折腾了我几个小时才好 还是有一点坑的 所以就写一下
4
记一次Kubernetes完整集群的搭建
HomeLab 写在前面 太好了孩子们 这次基本全都是命令行操作 我不用截图了 以下几乎全是命令 几乎一张图片没有 如果你想做为参考的话请仔细阅读每一行 前言 昨天我在折腾Authentik认证服务的时候 一直在思考用什么反代服务 常见的可以用Nginx Proxy Manager,Caddy,Traefik 这里面我觉得比较好用的是Traefik,但是即使是Traefik
5
记一次基于OpenWRT+Nginx反代的局域网服务小改造
HomeLab 前言 随着服务器上面跑的东西越来越多,docker跑的服务也越来越多了 我常访问所以我可以记住每个虚拟机的ip或者docker的端口 但是每次在浏览器输入都得输入192然后手动补全,有时候甚至得冒号加端口号才可以 太特么麻烦了
随机文章 随机推荐
Profile Image of the Author
Cainong
Caiw there 👋
公告
欢迎来到我的博客!这是一则示例公告。
音乐
封面

音乐

暂未播放

0:00 0:00
暂无歌词
分类
站点统计
文章
38
分类
16
标签
48
总字数
57,650
运行时长
0
最后活动
0 天前

文章目录