云原生开发工具微服务网络【免费下载链接】telepresenceLocal development against a remote Kubernetes or OpenShift cluster项目地址https://gitcode.com/gh_mirrors/te/telepresence点击查看免费下载本文是 Telepresence 官方 How-to 文档《Minimize the clients cluster permissions》的深度实战解读。Telepresence 客户端telepresenceCLI在本地开发远程 Kubernetes/OpenShift 集群时并不需要任何提权但它历史上被授予了一组机械性权限解析 traffic-manager 到 Pod、列出命名空间用于名称补全、读取 Pod 日志用于telepresence gather-logs。本文将带你沿一条清晰的四步阶梯把这些权限一级一级地削减——从默认的发现 诊断 端口转发授予最终收敛到纯策略化的telepresence.io授权甚至一步到位实现零 Kubernetes API 访问Direct Connect。读完你不仅能写出最小权限的 Helm values 文件还能理解 traffic-manager 的认证与授权模型为何允许这样激进地收敛。为什么客户端权限可以拨盘式收敛Telepresence 的架构决定了客户端权限收敛是可行的。traffic-manager 会对每一个调用者做真实 Kubernetes 身份认证并根据该身份执行授权详见 Authentication and authorization连接、附件attachment、日志访问都经由TokenReview与SubjectAccessReview完成。因此 traffic-manager 完全可以充当客户端的代理——由它自己来提供命名空间发现、日志收集等服务并基于调用者已验证的身份执行策略而不再依赖客户端物理上能碰到什么。于是客户端的 RBAC 足迹变成了一只拨盘下面的每一步都移除一类授予同时说明它要求什么、以及如果有的话会付出什么代价。各步骤之间相互独立除特别说明外页面末尾有一张完整的阶梯总览表。Step 1关闭发现与诊断授予clientRbac.legacyAccess: false第一步用一行 Helm values 完成clientRbac: legacyAccess: falsetraffic-manager 以单副本 StatefulSet 运行因此它的 Pod 名称无需查询即可得知traffic-manager-0。设置legacyAccess: false后chart 不再渲染两类授予发现规则manager 命名空间下的servicesget、podsget/list逐命名空间的诊断授予podsget/list、pods/logget。connect Role 只剩一条规则pods/portforwardcreate并通过resourceNames限定到traffic-manager-0这一个 Pod。命名空间发现与 gather-logs 不受影响命名空间发现和telepresence gather-logs依然正常工作——两者都由 traffic-manager 代为提供且日志访问按命名空间由logs.telepresence.io授予控制详见下文 Step 3 的授予表。这可以从 chart 源码中得到印证connect.yaml 的注释明确指出legacyAccess: false时仅渲染scoped to pod traffic-manager-0的单条规则而 namespace-scope.yaml 中traffic-manager-logsRolepods/logget只在legacyAccess: true且 manager 不管理自身命名空间时才渲染——因为现代客户端改走StreamLogsRPC 从 manager 流式获取日志相关限额见 values.yaml 中的logStreaming配置chunkSize默认64Ki、podConcurrency默认4、podByteLimit默认10Mi、deadline默认5m。前提条件与边界该模式要求客户端运行在引入已知名称连接known-name connection的版本或更高版本且使用默认的apiPort默认8081。旧版客户端必须自行把traffic-managerService 解析为 Pod——这正是 legacy 授予所允许的。values.yaml注释进一步明确只有2.33 之前的客户端或者覆盖了apiPort默认值的安装才需要 legacy 授予。该开关默认值true向后兼容计划在 2.32 之后两个 minor 版本翻转为false并在四个 minor 之后随相关规则与迁移钩子一并移除。另一个细节针对 v2.32 或更高版本的 traffic-manager显式指定--mapped-namespaces列表时同样不再需要pods授予——客户端信任 manager 自身的附件审查而不是在每个列出的命名空间里探测get pods。两种形态下渲染出的完整角色清单可查阅 RBAC 参考文档也可用下文附录的helm template命令自行渲染验证。Step 2强制认证security.authentication.mode: enforcingsecurity: authentication: mode: enforcingStep 3 与 Step 4 会把执行点从 API server 移到 traffic-manager而这只有在 manager 拒绝它无法认证的调用者时才有意义。默认的permissive模式下未认证的调用者依然会被放行只是记录日志因此后续步骤要求的授予将无处着力。security.authentication.mode共有三个取值见 values.yaml 与 authentication.md模式行为disabled完全不校验 token。permissive默认校验 token 并用于授权检查与会话绑定但任何调用都不会因缺少或认证失败而被拒绝决策记录在案供审计。enforcing缺少有效 bearer token 的调用被拒绝Unauthenticated未授权的附件被拒绝PermissionDenied。强制模式最关键的前提是每个客户端的 kubeconfig 都能产生一个 bearer token或一个可验证的客户端证书。后者对应security.authentication.x509默认enabled: true仅在enforcing模式下生效manager 会打开一个专用的仅认证 TLS 监听器默认端口8083让纯客户端证书的 kubeconfig 也能通过一次 TLS 握手换取短期 bearer token。此外enforcing模式还要求 agent 运行在当前版本或更高版本因为它们需要用受众绑定的投射 ServiceAccount token 完成认证。Step 3改用 Telepresence 自有授权security.authorization.requiredGrant: telepresencesecurity: authorization: requiredGrant: telepresence默认情况下manager 授权一次连接或附件的方式是询问调用者是否在相关命名空间持有pods/portforward——这是客户端历来为触达 manager 或 agent 而实际行使的权限被顺带用作策略。requiredGrant: telepresence用纯策略性的授予替换了这一代理这些授予位于telepresence.ioAPI 组授予授权内容connectionscreatemanager 命名空间建立会话。attachmentscreate / get目标命名空间附件attachment到工作负载create 覆盖 intercept、replace 与 wiretapget 覆盖 ingest。logs与logs/yamlget目标命名空间收集该命名空间的 Pod 日志logs以及在结果中包含 Pod manifestlogs/yaml。二者独立审查仅授予logs的调用者能得到日志manifest 会被直接省略。这些授予的语义是策略不是 Kubernetes 能力关键点在于telepresence.io资源永远不会被真正打到 Kubernetes API server 上——manager 是通过SubjectAccessReview来评估它们的因此授予它们不会在 Telepresence 之外赋予任何能力。除此以外它们与普通 RBAC 完全一致可以按命名空间用 Role 绑定也可以用 ClusterRoleattachments还能用resourceNames精确收敛到单个工作负载。chart 会为被要求的授予渲染配套的客户端 Role由clientRbac.subjects决定绑定的主体。渲染逻辑见 _helpers.tpl 中的telepresence.clientRbacInterceptRules定义requiredGrant取security.authorization.requiredGrant的值默认anylogs/logs/yaml诊断授予与所需授予无关、始终渲染而attachments规则只在requiredGrant ! portforward时渲染。代价目标命名空间的直接端口转发消失把telepresence设为所需授予后客户端 Role 中的逐命名空间pods/portforward授予随之消失其机械用途也随之而去客户端对该命名空间内 traffic-agent 的第一次直接端口转发拨号将被拒绝且没有 manager 中继可以回退。此时该命名空间内的附件必须依赖 QUIC 传输——QUIC 通道的选择在首次拨号 agent 时独立于本授予决定没有 QUICintercept、replace 或 ingest 会立即失败并给出明确错误。中间的any设置默认值在迁移期间接受两种授予中的任意一种。这一步之后的客户端权限长什么样以一个在shop命名空间中连接并附件到两个具名工作负载的开发者为例剩下的 Kubernetes 授予只有一个到 traffic-manager Pod 的端口转发客户端仍以此触达 manager其余全部是telepresence.io组内的纯策略kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: traffic-manager-connect namespace: ambassador rules: # 唯一保留下来的 Kubernetes 授予触达 manager 的 Pod。 - apiGroups: [] resources: [pods/portforward] resourceNames: [traffic-manager-0] verbs: [create] # 策略该身份是否允许建立会话 - apiGroups: [telepresence.io] resources: [connections] verbs: [create] --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: telepresence-shop namespace: shop rules: # 策略该身份是否允许附件到这些工作负载create 覆盖 # intercept、replace 和 wiretapget 覆盖 ingest。 - apiGroups: [telepresence.io] resources: [attachments] resourceNames: [cart, checkout] verbs: [create, get] # 策略该身份是否允许收集该命名空间的 Pod 日志 - apiGroups: [telepresence.io] resources: [logs, logs/yaml] verbs: [get]用普通的 RoleBinding 把这两个 Role 绑定给开发者即可。这里没有任何一条规则允许该身份通过 Kubernetes API 读取或修改 Pod、Service 或命名空间。需要说明的是若未设置clientRbac.namespacesnamespace-scope 的 Role 会按 manager 管理的命名空间逐一渲染集群级安装则渲染为 ClusterRole见 cluster-scope.yaml而clientRbac.subjects为空时 chart 会直接渲染失败并报错提示必须提供有效的 RBAC subject 列表见 namespace-scope.yaml。Step 4Direct Connect——完全不触碰 Kubernetes APIexternalEndpoint: enabled: true tls: secretName: traffic-manager-tls # 一个已存在的 kubernetes.io/tls Secret最后一步移除最后一个授予——连带移除客户端接触 Kubernetes API server 的全部需要。traffic-manager 会发布一个属于自己的 TLS 端点客户端配置cluster.managerAddress后直接拨号该端点不再通过 API server 做端口转发其两个守护进程root daemon 与 user daemon都不会再发出任何 Kubernetes API 请求。客户端依然用 kubeconfig 凭据完成认证读取 kubeconfig 与运行其 exec 插件都是本地操作。附件流量需要同时发布的 QUIC 端点quicTunnel.enabledDirect Connect 下不存在 Kubernetes 端口转发可供回退没有 QUIC 通道的客户端虽然可以连接、浏览与收集日志但创建 intercept 或 ingest 会因缺少投递通道而提前失败。前提条件security.authentication.mode: enforcing是强制的。chart 拒绝在外部端口配合其他模式渲染manager 也会拒绝启动见 External control endpoint没有 API server 为触达端口的人背书时未认证的调用者绝不能被放行。服务端信任必须能在 manager 重启后存活。监听器用一个持久化证书终结 TLS要么是已存在的kubernetes.io/tlsSecretexternalEndpoint.tls.secretName要么是 cert-manager 签发的 CertificateexternalEndpoint.tls.certManager。内存中的 QUIC CA 是临时的这里不使用。该模式与requiredGrant: telepresence、clientRbac.create: false天然配对即使某身份因其他原因持有pods/portforward也无法借此建立会话。发布端点还会从 chart 仍渲染的客户端 Role 中扣掉机械性的pods/portforward授予这些客户端永不端口转发只留下telepresence.io策略授予——除非所需授予是portforward此时持有pods/portforward本身就是连接策略具名授予会保留。需要注意cluster-admin之类的通配身份能通过一切审查无法用这种方式约束。这一步之后的客户端权限长什么样还是 Step 3 那位开发者改用 Direct Connect 后他不需要任何 Kubernetes 授予。connect Role 失去了pods/portforward规则两个 Role 里剩下的全部是由 traffic-manager 评估、Kubernetes API server 永远看不到的策略kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: traffic-manager-connect namespace: ambassador rules: - apiGroups: [telepresence.io] resources: [connections] verbs: [create] --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: telepresence-shop namespace: shop rules: - apiGroups: [telepresence.io] resources: [attachments] resourceNames: [cart, checkout] verbs: [create, get] - apiGroups: [telepresence.io] resources: [logs, logs/yaml] verbs: [get]Kubernetes API server 不会授予该身份任何东西——telepresence.io资源根本不存在于 API server 上。开发者能否连接、附件或读取日志完全由 traffic-manager 依据其认证时验证过的身份来决定。这正是 Direct Connect 的意义客户端的集群足迹就是你写下的那条策略仅此而已。阶梯总览客户端的 Kubernetes 权限Helm values要求发现、诊断与端口转发授予默认值—manager 命名空间中一个具名pods/portforward每个附件命名空间一个pods/portforwardclientRbac.legacyAccess: false当前版本客户端默认apiPort纯策略的telepresence.io授予security.authorization.requiredGrant: telepresencesecurity.authentication.mode: enforcing附件需要 QUIC 隧道无externalEndpoint、clientRbac.create: falseenforcing 模式、持久化 TLS 证书、Direct Connect 附件需要 QUICtelepresence setup一次交互走完整条阶梯telepresence setup会就上述每一步向你提问——是否强制认证、要求哪种授予、是否启用 Direct Connect、旧版客户端是否需要访问——并把结果写入 values 文件详见 Guided cluster setup。走最小客户端权限流程时回答Enforce caller authentication?为 yes、Enable Direct Connect?为 yes、挑选一个已有的 TLS Secret或 cert-manager、接受默认的telepresence所需授予一次运行即可得到如下配置security: authentication: mode: enforcing authorization: requiredGrant: telepresence externalEndpoint: enabled: true tls: secretName: traffic-manager-external-tls clientRbac: legacyAccess: false最后一级台阶的clientRbac.create: false不是 setup 替你决定的——当你不希望任何客户端持有 Kubernetes 授予时把它手动加进 values 文件即可。安装后的验证会打印cluster.managerAddress按此配置客户端即可在零 Kubernetes API 请求的情况下完成连接。附录用helm template验证你的授权配置RBAC 参考文档建议直接以 chart 为准来核对配置的实际渲染结果——不同requiredGrant、legacyAccess与externalEndpoint组合会渲染出截然不同的 Role/ClusterRole。渲染单个模板$ helm template traffic-manager datawire/telepresence-oss -n ambassador \ -f values.yaml -s templates/trafficManagerRbac/cluster-scope.yaml把-s换成templates/clientRbac/connect.yaml、templates/clientRbac/namespace-scope.yaml或templates/clientRbac/cluster-scope.yaml即可分别核对 connect Role、命名空间级 Role/ClusterRole 的最终形态确保每一步收敛都如你所愿。赞分享云原生开发工具微服务网络【免费下载链接】telepresenceLocal development against a remote Kubernetes or OpenShift cluster项目地址https://gitcode.com/gh_mirrors/te/telepresence点击查看免费下载相关推荐Velero RBAC 权限实战从默认 cluster-admin 到最小化受限权限配置Velero RBAC 权限实战从默认 cluster admin 到最小化受限权限配置 Velero 默认以 cluster admin ClusterRo云原生灾备存储后端Open X-Embodiment与RT-X模型机器人学习领域的革命性突破Open X Embodiment与RT X模型机器人学习领域的革命性突破 Open X Embodiment项目致力于将所有开源机器人数据统一格式为下游应eawsy/aws-lambda-go进阶上下文Context使用技巧与并发控制eawsy/aws lambda go进阶上下文Context使用技巧与并发控制 在使用Go语言开发AWS Lambda函数时eawsy/aws lam上一篇如何快速掌握B站视频下载神器BiliDownloader完整使用指南下一篇PhxQueue Lock分布式锁实现原理如何避免重复消费问题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
