关于jumpserver:jumpserver的简单安装使用

40次阅读

共计 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 权限管制！

  1. 创立 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

  2. 创立集群级别资源权限并绑定 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
  1. 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 这里肯定要记得集群的权限！

强调的：

  1. 用户 用户组的创立辨别
  2. 账户模板的应用
  3. kubernetes 普通用户的受权
  4. 资产前面进行更具体的划分
  5. 其余的：ldap 集成，存储应用对象存储。至于邮件的批改就疏忽了。近程利用都是企业版的性能也疏忽了
  6. kubernetes 的纳管有点意犹未尽：是纳管了，可是用户还须要实时看日志阿？我感觉我还是不会用 jumpserver 纳管 kubernetes……

正文完
jumpserver
发表至： jumpserver
2023-03-22
 0
关于jumpserver:Jumpserver与Freeipa集成以及其他配置
关于jumpserver:jumpserver的简单安装使用