共计 9282 个字符，预计需要花费 24 分钟才能阅读完成。
背景：
服务器的治理停留在 xshell 登陆治理的时代，主机设施数量少，单人操作的时候还能满足应用。当初的主机数量不多不少也有大几十台。而后就面临的多人的登陆与治理。过来都是间接给账户明码。但这样就会面临操作审计的问题。尽管给的机器都是测试环境的，然而追溯操作人，审计也还是大问题。另外就是数据库的近程操作。小伙伴都应用 navicat 操作。也会面临很多的问题：首位还是操作审计，其次就是近程 IP 的信赖，增加平安组这中操作就很烦人。迫切的须要一个两头操作的设施，就是堡垒机。jumpserser 是一款优良的堡垒机。很早之前就尝试应用过。比方过后疫情开始的时候近程办公。因为一些公司窃密起因，只容许近程操作公司电脑进行工作，不容许用户上传下载，过后就应用了 jumpserver 治理（windows 环境）。最近又看了一眼 jumpserver 的文档，发现反对了 kubernetes and mysql 的治理。正好体验一下呢！
jumpserver 的简略装置
前提筹备：
参照官网文档：https://docs.jumpserver.org/zh/v3/
腾讯云 cvm rocky9 操作系统为例：
对于操作系统 rocky9 腾讯云服务器:
数据库的创立 and 受权:
早些时候创立的 TDSQL- C 数据库, 创立了数据库 and 用户，并受权，如下：
创立用户设置明码并受权：
创立 redis 数据库 and 设置明码：
在线装置:
自定义主机名：
首先先自定义一下主机名，集体习惯。也能够疏忽
hostnamectl set-hostname jumpserver
执行一键装置脚本
主线版本当初是 v2 v3。这里间接装置了 V3.10 版本（latest，以后最新吧）. 当然了能够自定义初始化先把 mysql, redis 设置为咱们后面开明的。这里偷懒了。先一键装置，前面再去批改！
https://docs.jumpserver.org/zh/v3/installation/setup_linux_standalone/online_install/
curl -sSL https://resource.fit2cloud.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash
期待装置配置 docker. 下载 docker 镜像，初始化数据库并启动容器：
期待容器 running:
| docker ps | |
| jmsctl status |
这个时候曾经默认能够 web 登陆了（当然了 dns 默认解析到了此 CVM，域名形式拜访）。不先进入零碎，先做一下自定义配置再进入零碎 ……..
自定义配置：
mysql and redis 应用内部配置：
自定义批改 config.txt 中 mysql redis 配置：
vim /opt/jumpserver/config/config.txt
重启所有服务：
jmsctl 命令拿来用了：
jmsctl restart
jmsctl status
有强迫症不想看到 jms_mysql jms_redis 服务？
| jmsctl status | |
| docker stop jms_mysql jms_redis |
web 拜访并批改默认明码：
浏览器拜访自定义域名，默认用户名明码应该是 admin admin？
批改自定义明码：
从新登陆控制台：
登陆页面显示不平安 ……. 持续强迫症 https！
https 证书配置：
参照：https://kb.fit2cloud.com/?p=152
先上传证书到 /opt/jumpserver/config/nginx/cert/ 目录下：
批改 /opt/jumpserver3/config/config.txt 开启 https 拜访：
| jmsctl restart | |
| jmsctl status |
https 形式拜访 web 地址：
控制台根本是如下这样（图后截的疏忽）：
jumpserver 的简略应用：
比较关心罕用的资产治理：
尝试一下 主机 and 数据库 and 云服务（kubernetes）的治理!
主机为例：
创立资产
创立 - 抉择平台 Linux（资产 IP 为 10.0.4.18）:
输出 名称 IP/ 主机 节点抉择默认的 /Default
增加账号，明码形式抉择了ssh 密钥：
资产受权：
点击权限治理 - 资产受权，对 10.0.4.18 资源进行受权
点击提交：
切换到工作台验证：
左侧边栏，点击工作台切换：
web 终端登陆验证：
持续增加一个 node
开始认为 一个账户能够用于多个资产尝试 了一下失败了 ….. 创立资产的时候还看到了模板，就想创立一个模板尝试一下：
首先创立一个账号模板：
创立 10.0.4.68 的资产抉择账号模板：
web cli 登陆验证：
普通用户权限疏忽了就先
数据库的增加治理：
创立数据库资产与用户
资产治理 - 资产列表 - 数据库：
创立数据库资产，mysql 为例（资源 IP10.0.4.39）：
增加资源，增加用户，提交：
测试数据库连贯
点击更多 - 测试。能够看到 jumpserver 与数据库失常连贯：
资产受权这里你也可能会有跟我一样的纳闷：
特意尝试了一下不增加资产 but 选定 defult 节点：
然而其实也是能够拜访的，左侧边栏 - 工作台 -web 终端：
web-cli or navicat 操作数据库：
通过 web-cli 操作数据库：
mysql 的后盾针对的是 web-cli 还是。当然了 navicat 能够生成一个 5 分钟的长期用户！
轻易用 navicat 登陆长期账户，操作几条命令看看：
当然了始终连着还好，断开超时后，就无奈登陆了！
会话审计
控制台左侧边栏 - 审计台
会话审计 - 会话记录 and 命令记录：
命令能够追溯：
当然了 如果能有 web 版的 navicat 这样的页面就更好了！能追溯到命令与操作人不必去每次给用户开平安组增加信赖 IP，这样我曾经很知足了 ……. 惟一不满的是命令记录 不能依照资产进行分类！
云服务的增加治理:
参照：https://baijiahao.baidu.com/s?id=1752070936393562982&wfr=spider&for=pc
确定集群连贯 url
依据集群 config 文件 获取连贯 url:
K8S 集群管理权限的 SA，并且绑定 cluster-admin 角色
参照: https://www.i7ti.cn/1410.html
cat 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 |
kubectl apply -f jumpserver-admin.yaml
获取 token 令牌:
| kubectl get secret -n kube-system |grep "jumpserver-admin" | |
| kubectl describe secret jumpserver-admin-token-zb8vm -n kube-system |
注：以上操作在 kubernetes 控制台节点操作！
创立云服务资产
jumpserver 控制台操作
资产治理 - 资产列表 - 云服务 - 新建 - 抉择平台 -kubernetes
输出自定义名称 URL 节点等配置
增加账号, 输出上一步获取的 token，提交：
这里是没有测试的提交资源后：
资产受权：
输出相干配置，提交：
web cli 终端测试连贯：
切换控制台到工作台：
web 终端：
连贯名为 develop 的 kubernetes 集群：
轻易抉择一个 clusternet-system namespace 下 pod 连贯一下：
普通用户的测试：
注：以 kubernetes 云服务为例！
创立普通用户
下面的步骤都是超级用户 admin 操作的，当初创立一个普通用户：
控制台 - 用户治理 - 用户列表 - 创立用户：
普通用户 -zhangpeng 创立 - 提交
创立用户组 develop，将 zhangpeng 用户退出用户组:
留神：将 zhangpeng 用户在 default 用户组中剔除（后面好多受权针对的是用户组，创立新的组不便辨别）
kubernetes 相干资源创立：
网上所有的文章根本都是错的，对于普通用户的，比方：JumpServer：晋升 Kubernetes 集群治理平安。然而普通用户的形式是不残缺的。上面操作一下，请参照：k8s 联合 jumpserver 做 kubectl 权限管制 用户在多个 namespaces 的拜访权限 rbac 权限管制！
-
创立 serviceaccount
kubectl create sa develop-zhangpeng -n develop-xxx kubectl get sa -n develop-xxxx kubectl describe secrets/develop-zhangpeng-token-cddqx -n develop-xxxx - 创立集群级别资源权限并绑定 serviceaccount
网上很多的文章都是只绑定了 namespace 级别的资源，but jumpserver 不能间接到 namespace 级别。故须要绑定一下集群级别的资源权限：
cat jumpserver-admin-get-auth.yaml
| 其实这里就是设置对 k8s 集群的一些权限的 | |
| apiVersion: rbac.authorization.k8s.io/v1 # api | |
| kind: ClusterRole # 资源类型 | |
| metadata: # 元数据 ClusterRole 不受 ns 的限度，所以不必写 ns | |
| name: jumpserver-admin-get-auth # ClusterRole 的名称，能辨别就行 | |
| rules: | |
| - apiGroups: # apiGroups 就是 api 资源组，你 kubectl get apiservice 就能够看到集群所有的 api 组 | |
| - "" # 我这里代表为空，就是 api 组外面有一个 v1. 这样的 | |
| resources: # 就是 k8s 资源的名称。kubectl api-resources 这个命令能够查看到，第一列是资源名称，就是能够写在这里的。# 第二列是简写，kubectl get 前面的能够简写。# 第三列是 APIGROUP 组 | |
| # 第四列是是否属于 NAMESPACED 资源，就是你能够在 ns 上面看到的资源 | |
| # 第五列是 kind 的时候写的名称 | |
| # 资源还分子资源，前期会写一篇专门的文章介绍 | |
| - namespaces/status # 这个是 ns 状态 | |
| - namespaces # 这个是 ns | |
| - persistentvolumes # pv | |
| verbs: # verbs 是定义动作的 | |
| - get # 就是能够查看 ns 的权限 | |
| - list | |
| - watch | |
| - apiGroups: | |
| - "" | |
| resources: # 这里定义的是能够查看 node 的权限，更新 node 的权限。- nodes | |
| - nodes/status | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - patch | |
| - update | |
| - apiGroups: | |
| - "storage.k8s.io" | |
| resources: # 这里定义的是能够查看 sc 的权限，因为咱们有后端的存储集群，他们能够对 sc 的所有权限 | |
| - storageclasses | |
| - storageclasses/status | |
| resourceNames: # 因为 sc 属于集群资源，不同的业务方须要对本人的 sc 才有 全副权限。- axersc # 所有这里能够指定对哪一个 sc 有全副权限 | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - get | |
| - list | |
| - patch | |
| - update | |
| - watch |
创立 clusterrole apply yaml 文件：
kubectl apply -f jumpserver-admin-get-auth.yaml
把下面定义的集群权限 ClusterRole 绑定给 sa develop-zhangpeng：
cat jumpserver-admin-get-auth-clusterrolebinding.yaml
| apiVersion: rbac.authorization.k8s.io/v1 | |
| kind: ClusterRoleBinding # ClusterRoleBinding 用于绑定集群权限的 | |
| metadata: | |
| name: jumpserver-admin-get-auth # 名称 ClusterRoleBinding 不受 ns 的限度，所以没有 ns | |
| roleRef: | |
| apiGroup: rbac.authorization.k8s.io | |
| kind: ClusterRole # 下面定义的 ClusterRole 名称 | |
| name: jumpserver-admin-get-auth | |
| subjects: | |
| - kind: ServiceAccount # 下面定义的 sa 名称 | |
| name: develop-zhangpeng | |
| namespace: develop-xxxx |
kubectl apply -f jumpserver-admin-get-auth-clusterrolebinding.yaml
- namespace 资源的绑定
cat jumpserver-admin-auth.yaml
| apiVersion: rbac.authorization.k8s.io/v1 | |
| kind: ClusterRole | |
| metadata: | |
| name: jumpserver-admin-auth | |
| rules: | |
| - apiGroups: | |
| - "" | |
| resources: # 对 pod 的一些权限。- pods/attach | |
| - pods/exec # exec pod | |
| - pods/portforward # 设置 pod 的转发 | |
| - pods/proxy | |
| - secrets # secrets 的权限 | |
| - services/proxy | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - "" | |
| resources: | |
| - serviceaccounts # sa 的权限 | |
| verbs: | |
| - impersonate | |
| - apiGroups: | |
| - "" | |
| resources: | |
| - pods | |
| - pods/attach | |
| - pods/exec | |
| - pods/portforward | |
| - pods/proxy | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - patch | |
| - update | |
| - apiGroups: | |
| - "" | |
| resources: | |
| - configmaps | |
| - endpoints | |
| - persistentvolumeclaims | |
| - replicationcontrollers | |
| - replicationcontrollers/scale | |
| - secrets | |
| - serviceaccounts | |
| - services | |
| - services/proxy | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - patch | |
| - update | |
| - apiGroups: | |
| - apps | |
| resources: | |
| - daemonsets | |
| - deployments | |
| - deployments/rollback | |
| - deployments/scale | |
| - replicasets | |
| - replicasets/scale | |
| - statefulsets | |
| - statefulsets/scale | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - patch | |
| - update | |
| - apiGroups: | |
| - autoscaling | |
| resources: | |
| - horizontalpodautoscalers | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - patch | |
| - update | |
| - apiGroups: | |
| - batch | |
| resources: | |
| - cronjobs | |
| - jobs | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - patch | |
| - update | |
| - apiGroups: | |
| - extensions | |
| resources: | |
| - daemonsets | |
| - deployments | |
| - deployments/rollback | |
| - deployments/scale | |
| - ingresses | |
| - networkpolicies | |
| - replicasets | |
| - replicasets/scale | |
| - replicationcontrollers/scale | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - patch | |
| - update | |
| - apiGroups: | |
| - policy | |
| resources: | |
| - poddisruptionbudgets | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - patch | |
| - update | |
| - apiGroups: | |
| - networking.k8s.io | |
| resources: | |
| - ingresses | |
| - networkpolicies | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - patch | |
| - update | |
| - apiGroups: | |
| - metrics.k8s.io | |
| resources: | |
| - pods | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - "" | |
| resources: | |
| - configmaps | |
| - endpoints | |
| - persistentvolumeclaims | |
| - pods | |
| - replicationcontrollers | |
| - replicationcontrollers/scale | |
| - serviceaccounts | |
| - services | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - "" | |
| resources: | |
| - bindings | |
| - events | |
| - limitranges | |
| - pods/log | |
| - pods/status | |
| - replicationcontrollers/status | |
| - resourcequotas | |
| - resourcequotas/status | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - apps | |
| resources: | |
| - controllerrevisions | |
| - daemonsets | |
| - deployments | |
| - deployments/scale | |
| - replicasets | |
| - replicasets/scale | |
| - statefulsets | |
| - statefulsets/scale | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - autoscaling | |
| resources: | |
| - horizontalpodautoscalers | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - batch | |
| resources: | |
| - cronjobs | |
| - jobs | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - extensions | |
| resources: | |
| - daemonsets | |
| - deployments | |
| - deployments/scale | |
| - ingresses | |
| - networkpolicies | |
| - replicasets | |
| - replicasets/scale | |
| - replicationcontrollers/scale | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - policy | |
| resources: | |
| - poddisruptionbudgets | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - networking.k8s.io | |
| resources: | |
| - ingresses | |
| - networkpolicies | |
| verbs: | |
| - get | |
| - list | |
| - watch | |
| - apiGroups: | |
| - authorization.k8s.io | |
| resources: | |
| - localsubjectaccessreviews | |
| verbs: | |
| - create | |
| - apiGroups: | |
| - rbac.authorization.k8s.io | |
| resources: | |
| - rolebindings | |
| - roles | |
| verbs: | |
| - create | |
| - delete | |
| - deletecollection | |
| - get | |
| - list | |
| - patch | |
| - update | |
| - watch |
kubectl apply -f jumpserver-admin-auth.yaml
rolebingding 绑定 sa:
cat jumpserver-admin-auth-rolebinding.yaml
| apiVersion: rbac.authorization.k8s.io/v1 | |
| kind: RoleBinding | |
| metadata: | |
| name: jumpserver-admin-auth | |
| namespace: develop-xxxx | |
| roleRef: | |
| apiGroup: rbac.authorization.k8s.io | |
| kind: ClusterRole | |
| name: jumpserver-admin-auth | |
| subjects: | |
| - kind: ServiceAccount | |
| name: develop-zhangpeng | |
| namespace: develop-xxxxx |
kubectl apply -f jumpserver-admin-auth-rolebinding.yaml
创立一般账号
账户治理 - 账号列表 - 增加账号develop-zhangpeng。明码形式令牌形式，复制 kubernetes 集群中刚创立的 develop-zhangpeng 的 token!
资产受权：
权限治理 - 资产受权 - 创立资产受权规定：
留神受权这里的用户组！
登陆普通用户测试：
开了一个火狐浏览器登陆了普通用户 zhangpeng(看设置的明码策略，可能第一次要批改明码！这里就间接疏忽了)
切换到工作台：
点击 web 终端：
呈现资源列表 default 资源树：
能够点击一下其余资产，默认是没有账户，无权限的：
点击 develop kubernetes 资源，点击连贯：
进入集群验证一下权限：
点击 clusternet-system namespace or 其余命名空间默认应该都是无权限的！只能关上 develop-xxxx 空间下的 pod 的 shell：
这里和一般的 namespace 的受权是不一样的。个别的创立了用户权限绑定 namespace 就好了。然而在 jumpserver 这里肯定要记得集群的权限！
强调的：
- 用户 用户组的创立辨别
- 账户模板的应用
- kubernetes 普通用户的受权
- 资产前面进行更具体的划分
- 其余的：ldap 集成，存储应用对象存储。至于邮件的批改就疏忽了。近程利用都是企业版的性能也疏忽了
- kubernetes 的纳管有点意犹未尽：是纳管了，可是用户还须要实时看日志阿？我感觉我还是不会用 jumpserver 纳管 kubernetes……
