Jumpserver实战：三步打通Kubernetes集群统一纳管

1. 为什么需要统一纳管Kubernetes集群？

在日常运维工作中，我经常遇到这样的场景：开发团队有3个测试环境Kubernetes集群，2个预发布环境集群，还有1个生产集群。每个集群都需要单独管理账号权限，新同事入职要挨个配置kubectl访问权限，老同事离职又要逐个清理。这种分散管理方式不仅效率低下，还存在安全隐患。

Jumpserver作为开源的堡垒机系统，恰好能解决这个痛点。它就像是一个"万能钥匙管家"，把各个Kubernetes集群的访问权限集中管理起来。我去年在金融行业的一个项目中，就用Jumpserver统一纳管了客户分布在三个数据中心的8个Kubernetes集群，运维效率提升了60%以上。

统一纳管的核心价值在于：

• 单点登录：用户只需记住Jumpserver账号，无需维护多套kubeconfig
• 权限集中：所有集群的RBAC权限在Jumpserver界面统一配置
• 操作审计：所有kubectl操作都会被完整记录，满足合规要求
• 安全加固：通过ServiceAccount代替个人证书，避免私钥泄露风险

2. 环境准备与基础配置

2.1 创建高权限ServiceAccount

在Kubernetes集群中，我们需要先创建一个具备足够权限的ServiceAccount。这里有个实际踩过的坑：早期项目中使用的是个人kubeconfig证书，后来发现证书过期后会导致整个系统不可用。改用ServiceAccount后稳定性大幅提升。

以下是经过生产验证的yaml配置：

yaml复制# jumpserver-admin.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jumpserver-admin
  namespace: kube-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: jumpserver-admin
subjects:
- kind: ServiceAccount
  name: jumpserver-admin
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

应用这个配置时要注意：

1. 建议使用kube-system命名空间，避免被误删
2. 生产环境可以细化ClusterRole权限，不要直接给cluster-admin
3. 保存yaml文件到版本控制系统，方便后续审计

执行命令部署：

bash复制kubectl apply -f jumpserver-admin.yaml

2.2 获取认证Token

获取Token的过程就像是在银行开通API访问权限。首先需要找到密钥保险箱（Secret），然后取出里面的Token：

bash复制# 查找Secret名称
kubectl get sa jumpserver-admin -n kube-system -o yaml

# 假设输出中secret名称为jumpserver-admin-token-abc12
# 获取并解码Token
kubectl get secret jumpserver-admin-token-abc12 -n kube-system -o jsonpath={".data.token"} | base64 -d

这里有个实用技巧：把解码后的Token保存到临时文件，因为后续在Jumpserver界面配置时需要粘贴这个长字符串。我习惯用pbpaste | pbcopy这样的工具在终端和浏览器之间快速传递内容。

3. Jumpserver端配置详解

3.1 创建Kubernetes应用

登录Jumpserver后，进入【应用管理】→【Kubernetes】。点击创建按钮时，有几个关键参数需要注意：

• 集群地址：填写任意Master节点的6443端口地址。如果是高可用集群，建议使用负载均衡器的VIP地址
• 集群名称：建议采用环境-区域-用途的命名规范，比如"prod-us-east1-payment"
• 证书验证：生产环境务必开启，测试环境可以暂时关闭

我在配置时遇到过证书验证失败的问题，后来发现是集群使用了自签名证书。解决方法有两个：要么在Jumpserver服务器上添加CA证书信任，要么暂时关闭证书验证（仅限测试环境）。

3.2 配置系统用户

在【资产管理】→【系统用户】创建K8S类型的用户时，认证令牌处需要粘贴之前获取的Token。这里分享一个排查技巧：如果后续连接测试失败，可以先用这个Token直接通过kubectl测试：

bash复制kubectl --token=<粘贴Token> --server=<API地址> get nodes

曾经有个客户环境因为网络策略限制导致连接失败，用这个方法快速定位到了是防火墙问题。

4. 权限管理与最佳实践

4.1 应用授权配置

在【权限管理】→【应用授权】中创建授权规则时，建议遵循最小权限原则。比如：

• 开发人员：只授权特定命名空间的只读权限
• 测试人员：授权测试环境的读写权限
• 运维人员：根据职责范围授权部分生产环境权限

我设计的一个典型授权方案是这样的：

1. 在Kubernetes集群创建不同权限等级的Role
2. 为每个角色创建对应的ServiceAccount
3. 在Jumpserver中为每个ServiceAccount创建系统用户
4. 将Jumpserver用户与Kubernetes权限进行映射

4.2 生产环境加固建议

经过多个项目实践，我总结了这些安全经验：

1. 定期轮换Token：设置定时任务每90天更新一次ServiceAccount的Token
2. 网络隔离：限制Jumpserver服务器到K8s API Server的网络访问
3. 审计日志：开启Jumpserver的详细操作日志，并接入SIEM系统
4. 多因素认证：为敏感操作配置二次验证

有个金融客户曾经要求实现这样的安全策略：所有生产环境的kubectl操作必须经过双人审批。我们在Jumpserver上通过组合"授权申请+工单审批"的功能实现了这个需求。

5. 常见问题排查指南

5.1 连接测试失败

如果测试连接时报错，可以按照这个检查清单排查：

1. 检查网络连通性：从Jumpserver服务器telnet K8s API的6443端口
2. 验证Token有效性：用curl直接测试API
3. 检查证书有效期：特别是使用自签名证书的情况
4. 查看K8s审计日志：确认API Server是否收到请求

上周刚解决一个案例：客户升级K8s集群后连接失败，最后发现是新版本默认开启了TokenReview的webhook认证。

5.2 权限不足问题

当用户反映某些操作被禁止时，可以：

1. 在Jumpserver检查授权规则是否包含对应权限
2. 用kubectl auth can-i命令测试具体操作权限
3. 检查K8s的RBAC配置是否有变更

记得有次半夜被叫起来处理问题，最后发现是有人直接修改了K8s的ClusterRole导致权限异常。现在我都会在Jumpserver上开启配置变更告警。

6. 高级功能扩展

6.1 多集群统一管理

对于拥有多个集群的环境，可以在Jumpserver中为每个集群创建独立的Kubernetes应用。然后通过标签功能对集群进行分类，比如：

• 按环境：dev/test/staging/prod
• 按区域：us/eu/apac
• 按业务线：payment/order/inventory

我们为某跨国企业实施的方案中，通过Jumpserver统一管理了分布在5个国家的12个集群，每个集群都有独立的权限体系。

6.2 与CI/CD系统集成

Jumpserver的API可以方便地与Jenkins、GitLab CI等工具集成。典型场景包括：

1. 流水线自动获取临时凭证
2. 部署时自动申请权限
3. 审计跟踪所有自动化操作

实现方式是通过Jumpserver的API获取短期有效的Token，然后在CI脚本中使用。记得设置合理的Token有效期，通常不超过1小时。