【容器云 UK8S】最佳實踐：權限管理之了解RBAC和權限管理實踐

Tecode 發布于2022-06-28 19:00 / 2337人閱讀

摘要：本文介紹了模型中四個最主要的對象，即，大致了解了的工作原理和使用方法，如果要更加深入地了解和掌握，可以查看官方文檔。只是這個不能復用到其他，一般只有在做精細化權限管理的時候，我們才會創建對象，比如一個只能查看名稱為的。

了解RBAC

簡介

RBAC是一種基于角色來管理對計算機或網絡資源訪問策略的方法。

我們知道，對K8S內所有API對象的操作都是通過訪問kube-apiserver來完成的，因此kube-apiserver需要校驗訪問者是否具備操作這些API對象的權限。而K8S中負責授權和權限校驗(Authorization&Authentication)的這套機制，則是RBAC：基于角色的訪問控制（Role-based Access Control ）

在Kubernetes的RBAC模型里面，有三個基本的概念：

Role：角色，其實是一組權限規則的集合，定義了一組對Kubernetes API 對象的操作權限。
Subject：主體，即被授予角色的"人"或"物"，即可以是Kubernetes里面的Service Account，也可以是外部User，為了簡單起見，本文主要以Service Account來做演示。
RoleBinding：定義了Role與Subject的綁定關系。

而至于ClusterRole、ClusterRoleBinding，在概念上與Role、RoleBinding非常相似，只是作用域不同而已。

Role & ClusterRole

1、Role---namespace維度的權限集合

首先我們來介紹下Role，Role本身也是Kubernetes中的一個 API 對象，其定義如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get" "watch" "list"]

首先，我們注意到這個名為"pod-reader"的Role，通過namespace: default指定了他能產生作用的Namespace。

Namespace是Kubernetes中的一個邏輯管理單位，Kubernetes中大部分業務類API對象（如Pod、Service）都是Namespace級別的，在操作時需要顯式指明Namespace，如：kubectl edit role/pod-reader -n namespace2.

然后是rules字段，一個Role對象所擁有的權限，其實就是通過rules字段來定義了。

apiGroups：apiGroup代表API對象所屬的組，可以通過kubectl api-resources來查看API對象屬于哪個組，上文示例""代表Core API group。
resources：用于聲明該角色可訪問的API對象。
verbs：用于聲明該角色可對API對象進行的操作，在Kubernetes中，verbs的全集為"get" "list" "watch" "create" "update" "patch" "delete"，如果我們要賦予某個role對某個API對象的所有權限，指定verbs的全部集合即可。
resourceName：resourceName表示具體的K8S資源，需要注意的是，當聲明了resourceName時，則verbs中不能再賦予list操作，該字段較少使用，一般用于較細粒度的權限管理。

了解了Role每個字段的含義后，上文Role示例的意義其實就很清楚了：一組可對default命名空間下所有的Pod，進行GET、WATCH、LIST操作的權限集合，名稱為pod-reader。

2、ClusterRole---Cluster維度的權限集合

ClusterRole的API定義與Role基本相同，你可以給一個ClusterRole賦予與Role一樣的權限。但由于其cluster-wide的特性，ClusterRole可以被賦予一些不同的權限：

集群級別的API對象訪問權限，如nodes、namespace、pv；
非資源類型endpoints的訪問權限，如"/healthz";
所有Namespace下資源的訪問權限，如kubectl get pods --all-namespaces；

下文是一個ClusterRole的示例，與Role最大的區別就在于不需要聲明namespace。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get" "watch" "list"]

值得注意的是，Kubernetes內置了很多為系統保留的ClusterRole，你可以通過kubectl get clusterrole查看到他們。一般來說，這些ClusterRole，是綁定給系統組件對應的service account使用的。比如，其中一個名為system:controller:cronjob-controller的ClusterRole，定義的權限規則是Cronjob這個控制器運行所必要的權限。你可以通過如下示例查看查看其權限規則。

bash-4.4# kubectl describe clusterrole system:controller:cronjob-controller
Name:         system:controller:cronjob-controller
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources                  Non-Resource URLs  Resource Names  Verbs
  ---------                  -----------------  --------------  -----
  jobs.batch                 []                 []              [create delete get list patch update watch]
  events                     []                 []              [create patch update]
  pods                       []                 []              [delete list]
  cronjobs.batch             []                 []              [get list update watch]
  cronjobs.batch/finalizers  []                 []              [update]
  cronjobs.batch/status      []                 []              [update]

除此以外，還有幾個預先的定義的CluterRole值得留意下，后面給其他集群用戶配置權限的時候，我們可能會用到：

view
edit
admin
cluster-admin

其所擁有的權限，通過其名稱我們也能猜到大概，具體的權限規則可以通過kubectl describe clusterrole clusterrole-name來查看。

了解了Role和ClusterRole后，我們知道如何在Kubernetes集群內聲明一組權限集合，那怎么把權限賦予某個具體的"人"或"物"呢？答案就是RoleBinding和ClusterRoleBinding啦。

RoleBinding&ClusterRoleBinding

1、Rolebinding---在Namespace范圍內授予權限

Rolebinding可將角色中定義的權限授予用戶或用戶組，它包含subject（user、group或Service Account），以及所引用的角色。RoleBinding可以在同一命名空間中引用Role（意味著Role和Rolebinding必須位于同一Namespace）。

以下RoleBinding的示例，將“pod-reader”角色授予“default”命名空間中的“jane”。這允許“jane”讀取“默認”命名空間中的pod。

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: jane # must create a ServiceAccount jane in default namespace
  namespace: default
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

值得注意的是，一個RoleBinding也可以引用ClusterRole，這樣ClusterRole中所定義的Namespace級別的權限將會被賦予Subject，當然只在rolebinding所在的Namespace有效。這樣做的好處是，集群管理員可以預先創建一些通用的ClusterRole，然后在不同的Namespace中使用他們，比如在上個章節提到的view、admin.

如下文所示，雖然"view-only"這個RoleBinding引用了ClusterRole，但"ucloud"這個ServiceAccount只擁有查看"development"這個命名空間下所有資源的權限，而不能查看所有命名空間下的資源。

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
metadata:
  name: view-only
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: ServiceAccount
  name: ucloud # Create a ServiceAccount in your cluster before test
  namespace: production # The namespace of subject can be different with Rolebinding
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

2、ClusterRoleBinding---在Cluster范圍內授予權限

下面我們來了解下ClusterRoleBinding，前面我們提到過，Role和RoleBinding都是Namespace級別的資源，也就是說他們所聲明的權限規則都只在Namespace范圍內有效。
那如果我們

想讓某個Subject（用戶）擁有所有Namespace的查看權限；
或者想讓某個Pod擁有查看Node的權限；

應該怎么辦呢？這就需要用到ClusterRole和ClusterRoleBinding這對組合了，和ClusterRole一樣，ClusterRoleBinding與RoleBinding的最大不同其實就是不需要聲明"namespace"這個字段了。

首先我們來看一個示例，我們想讓techleader擁有所有Namespace的查看權限，注意roleRef，對于ClusterRoleBinding，只能引用ClusterRole，而不能是Role。

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows a service account named "techleader" to view resource in any namespace.
kind: ClusterRoleBinding
metadata:
  name: techleader-read-global
subjects:
- kind: ServiceAccount
  name: techleader   
  namespace: default
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

其次，我們還希望為techleader賦予查看nodes的權限，所以我們需要在創建一個ClusterRole和ClusterRoleBinding。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get" "watch" "list"]

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows a service account named "techleader" to view resource in any namespace.
kind: ClusterRoleBinding
metadata:
  name: techleader-read-node
subjects:
- kind: ServiceAccount
  name: techleader   
  namespace: default
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

本文介紹了Kubernetes RBAC 模型中四個最主要的API對象，即Role、ClusterRole、RoleBinding、ClusterRoleBinding，大致了解了RBAC的工作原理和使用方法，如果要更加深入地了解和掌握RBAC，可以查看官方文檔。

權限管理實踐

背景

本文主要通過一個例子來介紹如何基于K8S的RBAC實現授權決策，允許集群管理員通過Kubernetes API動態配置策略，讓非集群管理員具有某個namespace下的所有權限，并可通過Dashboard或者kubectl來管理該ns下的資源。

一、創建NS

kubectl create ns pre

上面的示例創建了一個名為"pre"的命名空間，用于部署預發布的服務。

二、創建Service Account

kubectl create sa mingpianwang -n pre

在pre的命名空間下創建一個名為"mingpianwang"的Service account，給到某個特定的用戶使用。這里要說明下，K8S里面有兩類用戶，一個是Service Account，另一個是普通用戶(user)。但K8S本身不并管理user，而是交由外部獨立服務管理，因此我們不能通過K8S API來創建user，考慮到我們只是通過kubectl和Dashboard來管理集群，Service account已經足夠滿足要求，而且可以在Kubernetes中直接管理。因此這里不介紹如何使用user這個對象來管理集群。

三、賦予權限

由于我們已經預先說明，需要給mingpianwang這個用戶賦予pre 這個命名空間下的所有權限，即admin權限。

重點來了，RoleBinding對象是可以引用一個ClusterRole對象的，然后這個ClusterRole所擁有的權限只會在這個NS下面有效。這一點允許管理員在整個集群范圍內首先定義一組通用的角色，然后再在不同的名字空間中復用這些角色。

我們先看下集群內默認的ClusterRole有哪些，執行get clusterrole命名可以看到，有admin、cluster-admin、edit等角色，那我們可以直接使用admin這個clusterrole角色，通過rolebinding的方式賦予”mingpianwang“這個用戶。

[root@10-9-149-7 ~]# kubectl get clusterrole
NAME AGE
admin 4h53m
cluster-admin 4h53m
edit 4h53m

示例的yaml如下，我們只要執行下kubectl apply -f rolebinding.yaml 即可。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-dashboard-minimal
  namespace: pre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- kind: ServiceAccount
  name: mingpianwang
  namespace: pre

當然，我們也可以創建一個Namespace級別的role，并將這個角色綁定到ServiceAccount。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: pre
  name: admin
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["*"]
  verbs: ["*"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-dashboard-minimal
  namespace: pre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin
subjects:
- kind: ServiceAccount
  name: mingpianwang
  namespace: pre

只是這個role不能復用到其他Namespace，一般只有在做精細化權限管理的時候，我們才會創建Role對象，比如一個只能查看pod 名稱為test-pod的Role。其他場景下，我們推薦集群管理員使用ClusterRole。

四、訪問Dashboard

這里我們使用token方式來登錄Dashboard，那我們就要獲取到”mingpianwang“的token，其實就是secret了。這個secret在我們創建的時候，K8S就幫我們自動生成了。通過下面的方式來獲取，最后的token復制下來就可以了。

bash-4.4# kubectl describe sa/mingpianwang -n pre
Name:                mingpianwang
Namespace:           pre
Labels:              
Annotations:         
Image pull secrets:  
Mountable secrets:   mingpianwang-token-4l8xj
Tokens:              mingpianwang-token-4l8xj
Events:              
bash-4.4# kubectl describe secret/mingpianwang-token-4l8xj -n pre
Name:         mingpianwang-token-4l8xj
Namespace:    pre
Labels:       
Annotations:  kubernetes.io/service-account.name: mingpianwang
              kubernetes.io/service-account.uid: d7bb847d-7621-11e9-9679-5254007e7ba9

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1359 bytes
namespace:  5 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9/....

復制到登錄框，我們發現可以登錄到Dashboard首頁，不過需要注意的是，由于這個賬號只有pre這個命名空間的權限，而Dashboard默認是default，所以進去之后會報一堆錯咯，沒關系，只要將左側的NS改為pre即可。

五、通過kubectl管理集群

由于我們還需要支持kubectl命令行管理NS，因此還需要為mingpianwang生成kubecofnig，一個用戶還好，多個用戶就很麻煩了，因此這里我們使用一個自動生成kubeconfig的腳本，代碼如下：

#!/bin/bash -e
# Usage ./k8s-service-account-kubeconfig.sh ( namespace ) ( service account name )
TEMPDIR=$( mktemp -d )
trap "{ rm -rf $TEMPDIR ; exit 255; }" EXIT
SA_SECRET=$( kubectl get sa -n $1 $2 -o jsonpath={.secrets[0].name} )
# Pull the bearer token and cluster CA from the service account secret.
BEARER_TOKEN=$( kubectl get secrets -n $1 $SA_SECRET -o jsonpath={.data.token} | base64 -d )
kubectl get secrets -n $1 $SA_SECRET -o jsonpath={.data.ca.crt} | base64 -d > $TEMPDIR/ca.crt
CLUSTER_URL=$( kubectl config view -o jsonpath={.clusters[0].cluster.server} )
KUBECONFIG=kubeconfig

kubectl config --kubeconfig=$KUBECONFIG 
    set-cluster 
    $CLUSTER_URL 
    --server=$CLUSTER_URL 
    --certificate-authority=$TEMPDIR/ca.crt 
    --embed-certs=true

kubectl config --kubeconfig=$KUBECONFIG 
    set-credentials $2 --token=$BEARER_TOKEN

kubectl config --kubeconfig=$KUBECONFIG 
    set-context registry 
    --cluster=$CLUSTER_URL 
    --user=$2 
    --namespace=$1

kubectl config --kubeconfig=$KUBECONFIG 
    use-context registry

echo "kubeconfig written to file "$KUBECONFIG""

直接在master節點執行sh kubeconfig.sh pre mingpianwang，即可自動生成一個kubeconfig文件，將這個kubeconfig文件分發給使用者，讓其復制到~/.kube/config下即可，而且默認NS就是pre，get nodes等操作都是不被允許的。

自動生成kubeconfig的源代碼在這里，generator kubeconfig，我們只是加了一個默認NS，這樣不需要在執行kubectl命令的時候追加-n pre。

實時文檔歡迎訪問https://docs.ucloud.cn/uk8s/bestpractice/authorization/rbac

云服務器 GPU云服務器云管理最佳實踐最佳實踐從云計算基礎架構到最佳實踐 webrtc最佳實踐

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/126292.html

【容器云UK8S】新手指導

摘要：詳細請見產品價格產品概念使用須知名詞解釋漏洞修復記錄集群節點配置推薦模式選擇產品價格操作指南集群創建需要注意的幾點分別是使用必讀講解使用需要賦予的權限模式切換的切換等。UK8S概覽UK8S是一項基于Kubernetes的容器管理服務，你可以在UK8S上部署、管理、擴展你的容器化應用，而無需關心Kubernetes集群自身的搭建及維護等運維類工作。了解使用UK8S為了讓您更快上手使用，享受UK...

Tecode 2022-06-28 19:00 評論0 收藏0
每個人都必須遵循的九項Kubernetes安全最佳實踐

摘要：的元數據隱藏功能會更改集群部署機制以避免此暴露，我們建議使用它直到有永久解決方案。授權失敗可能意味著攻擊者試圖濫用被盜的憑據。年中國論壇提案征集現已開放論壇讓用戶開發人員從業人員匯聚一堂，面對面進行交流合作。作者：StackRox產品經理Connor Gilbert 上個月，Kubernetes（世界上最受歡迎的容器編排器）生態系統因發現Kubernetes的第一個主要安全漏洞而動搖...

jzman 2019-07-01 17:36 評論0 收藏0
每個人都必須遵循的九項Kubernetes安全最佳實踐

摘要：的元數據隱藏功能會更改集群部署機制以避免此暴露，我們建議使用它直到有永久解決方案。授權失敗可能意味著攻擊者試圖濫用被盜的憑據。年中國論壇提案征集現已開放論壇讓用戶開發人員從業人員匯聚一堂，面對面進行交流合作。作者：StackRox產品經理Connor Gilbert 上個月，Kubernetes（世界上最受歡迎的容器編排器）生態系統因發現Kubernetes的第一個主要安全漏洞而動搖...

endless_road 2019-06-21 16:51 評論0 收藏0
每個人都必須遵循的九項Kubernetes安全最佳實踐

摘要：的元數據隱藏功能會更改集群部署機制以避免此暴露，我們建議使用它直到有永久解決方案。授權失敗可能意味著攻擊者試圖濫用被盜的憑據。年中國論壇提案征集現已開放論壇讓用戶開發人員從業人員匯聚一堂，面對面進行交流合作。作者：StackRox產品經理Connor Gilbert 上個月，Kubernetes（世界上最受歡迎的容器編排器）生態系統因發現Kubernetes的第一個主要安全漏洞而動搖...

Travis 2019-07-01 17:01 評論0 收藏0
【容器云 UK8S】最佳實踐：基于Jenkins的CI/CD實踐

摘要：擴展性好當集群的資源嚴重不足而導致排隊等待時，可以很容易的添加一個到集群中，從而實現擴展。用法，選擇盡可能使用這個節點鏡像，填寫，這個容器鏡像是我們的運行環境。更新文件，這里我們只是將中的鏡像更換成最新構建出的鏡像。基于Jenkins的CI/CD實踐[TOC]一、概要提到K8S環境下的CI/CD，可以使用的工具有很多，比如Jenkins、Gitlab CI、新興的drone等，考慮到大多公司...

Tecode 2022-06-28 19:00 評論0 收藏0

發表評論

登陸后可評論

0條評論

Tecode

男|高級講師

我要關注我要私信

TA的文章

tensorflow指定cpu

閱讀 3528·2023-04-25 20:09
香港云服務器這幾天網絡有沒有丟包嚴重

閱讀 3733·2022-06-28 19:00
EPC單機掛載UHOST-RSSD高速磁盤

閱讀 3053·2022-06-28 19:00
GPU活動使用TIPS

閱讀 3071·2022-06-28 19:00
為科研量身定制，UCloud推出“云極”高性能計算EPC

閱讀 3160·2022-06-28 19:00
UCloud 2021年終特惠已開啟，快杰O型ARM服務器上海節點重磅上線！

閱讀 2870·2022-06-28 19:00
“懂運維、精運營、重服務” UCloud發布混合云多云管理平臺UCMP

閱讀 3031·2022-06-28 19:00
軟件定義存儲，UCloudStor存儲?體機強勢登場

閱讀 2628·2022-06-28 19:00

国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

【容器云 UK8S】最佳實踐：權限管理之了解RBAC和權限管理實踐

了解RBAC

簡介

Role & ClusterRole

1、Role---namespace維度的權限集合

2、ClusterRole---Cluster維度的權限集合

RoleBinding&ClusterRoleBinding

1、Rolebinding---在Namespace范圍內授予權限

2、ClusterRoleBinding---在Cluster范圍內授予權限

權限管理實踐

背景

一、創建NS

二、創建Service Account

三、賦予權限

四、訪問Dashboard

五、通過kubectl管理集群

相關文章

**【容器云UK8S】新手指導**

每個人都必須遵循的九項Kubernetes安全最佳實踐

每個人都必須遵循的九項Kubernetes安全最佳實踐

每個人都必須遵循的九項Kubernetes安全最佳實踐

**【容器云 UK8S】最佳實踐：基于Jenkins的CI/CD實踐**

發表評論

0條評論

Tecode

男|高級講師

TA的文章

tensorflow指定cpu

香港云服務器這幾天網絡有沒有丟包嚴重

EPC單機掛載UHOST-RSSD高速磁盤

GPU活動使用TIPS

為科研量身定制，UCloud推出“云極”高性能計算EPC

UCloud 2021年終特惠已開啟，快杰O型ARM服務器上海節點重磅上線！

“懂運維、精運營、重服務” UCloud發布混合云多云管理平臺UCMP

軟件定義存儲，UCloudStor存儲?體機強勢登場

最新活動

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

【容器云 UK8S】最佳實踐：權限管理之了解RBAC和權限管理實踐

了解RBAC

簡介

Role & ClusterRole

1、Role---namespace維度的權限集合

2、ClusterRole---Cluster維度的權限集合

RoleBinding&ClusterRoleBinding

1、Rolebinding---在Namespace范圍內授予權限

2、ClusterRoleBinding---在Cluster范圍內授予權限

權限管理實踐

背景

一、創建NS

二、創建Service Account

三、賦予權限

四、訪問Dashboard

五、通過kubectl管理集群

相關文章

發表評論

0條評論

男|高級講師

TA的文章

最新活動

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

1、Role---namespace維度的權限集合

2、ClusterRole---Cluster維度的權限集合

1、Rolebinding---在Namespace范圍內授予權限

2、ClusterRoleBinding---在Cluster范圍內授予權限

一、創建NS

二、創建Service Account

四、訪問Dashboard