k8s結合jumpserver作kubectl權限控制 用戶在多個namespaces的訪問權限 rbac權限控制

時間  2021-07-24
標籤 html node git 後端 api 安全 bash app spa ssr 欄目 軟件設計 简体版
原文   原文鏈接

圈子過小，作人留一面，往後好相見。html

 

其實這個文章就是用戶用jumpserver登陸到k8s master節點node

而後執行kubectl的時候只有本身namespaces的全部權限。git

 

背景

1，k8s 有一天忽然kubectl 執行任何命令都報權限不對。後端

2，最後查明是由於有一個開發不當心把admin的ClusterRoleBinding給刪除了。api

3，jumpserver給全部開發的權限都是同一個普通用戶。安全

4，由於咱們是一個k8s集羣，而後用不一樣的namespaces區分不一樣的業務小組。每一個小組有固定的node機器。bash

5，kubectl 的配置文件都是用的同一個，權限也是admin的。app

 

要求

1，領導要求業務小組只有本身namespaces的權限。spa

2，業務小組不能有一個集羣的大的權限，好比刪除node，不能更新master node的一些信息。ssr

 

整體思路

1，在jumpserver上面新建各業務方系統用戶。

2，把系統用戶綁定給各業務方用戶組。（關於Jumpserver  系統用戶和管理用戶介紹，後期出一篇單獨的文章。）

3，在k8s  master1節點上面的各個業務方系統用戶家目錄下面 新建不一樣的.kube/config文件。

 

1、.kube/config 文件生成

1，這裏我就用我這邊的需求寫了，有關於k8s rbac的分享，我在後期會寫一篇單獨的文章。https://www.cnblogs.com/fanfanfanlichun/p/15005427.html

2，業務方有：axer，paas。這是我公司這邊的兩個業務方。

3，其實k8s的rbac確實很是的複雜，難理解，實現權限劃分的方式

 

1.1 權限劃分思路

1，首先是各類資源的權限，k8s資源又分兩種，一種是集羣的資源，一種是ns資源。

2，而後是將權限和誰綁定起來。 大概就是兩步：權限和綁定權限。

 

3，我這裏是用了兩個ClusterRole，一個是集羣的資源的權限，一個是ns資源的權限

4，我選擇的是sa來作受權的對象。而後用這個sa的token去作kubectl的權限驗證

5，多個RoleBinding，每個RoleBinding把ns的資源權限固定在一個ns裏面。你想要這個sa有哪些ns的權限，就寫幾個RoleBinding。

6，一個ClusterRoleBinding，用於綁定sa對集羣資源的權限。

 

1.2 建立ClusterRole

 

1.2.1 集羣資源權限

也就是說整個k8s集羣的一些權限。好比：get ns，get node，get node status，git ns status......

# 其實這裏就是設置對k8s集羣的一些權限的

apiVersion: rbac.authorization.k8s.io/v1    # api
kind: ClusterRole                           # 資源類型
metadata:                                   # 元數據 ClusterRole 不受ns的限制，因此不用寫ns
  name: business-axer-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

 

1.2.2 ns資源權限

就是定義業務方對本身ns的全部權限，本身的ns裏面的全部資源都要有權限。

點擊查看代碼

點擊查看代碼

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: business-axer-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

 

這樣兩個權限的ClusterRole就建立好了。其實就是定義權限。有哪些權限。

 

1.3 建立sa ServiceAccount

我選擇的是sa作角色，固然也能夠選擇user，或者usergroup。就是K8s實現權限劃分有不少方式。看你們的選擇需求了。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: business-axer-serviceaccount    # sa的名稱。隨便取，固然你要能認識區分
  namespace: business-auth              # sa的ns。我這裏單獨的建了一個ns，就是爲了作權限劃分的ns。

 

1.4 建立ClusterRoleBinding

ClusterRoleBinding是用來綁定集羣權限的。

也就是說把我上面定義的集羣權限ClusterRole綁定給sa。這樣這個sa就有操做集羣的一些字眼的權限了。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding                   # ClusterRoleBinding 用於綁定集羣權限的
metadata:
  name: business-axer:get                  # 名稱  ClusterRoleBinding 不受ns的限制，因此沒有ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole                        # 上面定義的ClusterRole名稱
  name: business-axer-get-auth
subjects:
- kind: ServiceAccount                     # 上面定義的sa名稱
  name: business-axer-serviceaccount
  namespace: business-auth

 

1.5 建立RoleBinding

這個RoleBinding就是綁定ns裏面的資源的權限的。

也就是說我把上面定義的ClusterRole權限綁定給sa。而後這個權限只能在這個RoleBinding所在的ns裏面纔有權限。

想要受權給業務放哪一個ns的權限 就要在哪一個ns裏面建立一個RoleBinding。

假如說一個業務放有10個ns的權限，那麼久須要建立10個RoleBinding。

 

# 我這下面是給這個sa了兩個ns的全部權限
# ai-platform-deploy和ai-platform-test命名空間的全部權限
# 若是須要別的ns的權限那就定義多個RoleBinding。
# 固然這個RoleBinding必需要在ns裏面。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: business-axer:ai-platform-deploy
  namespace: ai-platform-deploy
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: business-axer-admin-auth
subjects:
- kind: ServiceAccount
  name: business-axer-serviceaccount
  namespace: business-auth

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: business-axer:ai-platform-test
  namespace: ai-platform-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: business-axer-admin-auth
subjects:
- kind: ServiceAccount
  name: business-axer-serviceaccount
  namespace: business-auth

 

權限和綁定都作完了，剩下的就是生成config文件了

1.6 生成config文件

 

我這裏選擇的是token的驗證方式。

我是寫了一個簡單的腳本。

#!/bin/bash
sa_name="business-axer-serviceaccount"    # 這個是sa的名稱

user="business-axer"                      # 這個是user，對於我使用token的驗證方式，這裏的user沒啥用，隨便寫
context_name="business-axer-ct"           # 對於我使用token的驗證方式，這個也是能夠隨便寫，

cp ./demo.config ./guest.config           # 拷貝一份demo.config

# 這裏是獲取sa的secret名稱，每個sa都會有。
secret_name=`kubectl get sa -n business-auth $sa_name -o go-template='{{range .secrets}}{{.name}}{{end}}'`
# 這裏是獲取secret的token
TOKEN=`kubectl -n business-auth get secret $secret_name -o go-template='{{.data.token}}'`

# 這下面是設置一些上下文
kubectl config set-credentials $user --token=`echo ${TOKEN} | base64 -d` --kubeconfig=./guest.config
kubectl config set-context $context_name --cluster=kubernetes --user=$user --kubeconfig=./guest.config
kubectl config use-context $context_name --kubeconfig=./guest.config

 

demo.config文件

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUCg==   這個是固定的，你查看一下線上的,其實就是https安全驗證，ca證書
    server: https://10.19.250.206:8443         # k8s集羣apiservice的端口
  name: kubernetes    # 集羣的名稱
kind: Config

 

最終的guest.config文件，個人下面的除了token和ca我刪了，其餘的都是正確的。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LShRTl0tLS0tCg==
    server: https://10.19.250.206:8443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: business-axer
  name: business-axer-ct
current-context: business-axer-ct
kind: Config
preferences: {}
users:
- name: business-axer
  user:
    token: eyJhbGciOiJSUzI1NiIsImtpZC-iyX0M6m5nEXqC6w

 

解讀以下：

clusters記錄了 clusters（一個或多個 K8S 集羣）信息：

        name是這個 cluster（K8S 集羣）的名稱代號

        server是這個 cluster（K8S 集羣）的訪問方式，通常爲 IP+PORT

        certificate-authority-data是證書數據，只有當 cluster（K8S 集羣）的鏈接方式是 https 時，爲了安全起見須要證書數據

users記錄了訪問 cluster（K8S 集羣）的帳號信息：

        name是用戶帳號的名稱代號

        user/token是用戶的 token 認證方式，token 不是用戶認證的惟一方式，其餘還有帳號+密碼等。

contexts是上下文信息，包括了 cluster（K8S 集羣）和訪問 cluster（K8S 集羣）的用戶帳號等信息：

        name是這個上下文的名稱代號

        cluster是 cluster（K8S 集羣）的名稱代號

        user是訪問 cluster（K8S 集羣）的用戶帳號代號

current-context記錄當前 kubectl 默認使用的上下文信息

kind和apiVersion都是固定值，用戶不須要關心

preferences則是配置文件的其餘設置信息，我沒有使用過，暫時不提。

1.7 config文件放入業務方用戶的家目錄下面的.kube/config。權限要644的。

 

多個業務放就按照上面的步驟建立就行，能夠把業務放理解成sa。

 

2、配置jumpserver

其實就是在jumpserver上面建立系統用戶，而後把這個系統用戶綁定到用戶組。

那麼用戶組裏面的用戶登陸k8s master1機器的時候就是他們本身的系統用戶了。

而後這個用戶執行kubectl 的時候 默認會去家目錄下面的.kube找config文件。

config文件又是咱們生成的。

這樣就能夠把用戶限制在ns裏面了。

 

 

歡迎大佬留言評論，有什麼不足的望各位大佬指出。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程