Kubernetes-16：一文詳解ServiceAccount及RBAC權限控制

時間  2020-09-11
標籤 kubernetes 一文 詳解 serviceaccount rbac 權限 控制 欄目 軟件設計 简体版
原文   原文鏈接

1、ServiceAccount

1.ServiceAccount 介紹

首先Kubernetes中帳戶區分爲：User Accounts（用戶帳戶） 和 Service Accounts（服務帳戶） 兩種，它們的設計及用途以下：html

  • UserAccount是給kubernetes集羣外部用戶使用的，例如運維或者集羣管理人員，使用kubectl命令時用的就是UserAccount帳戶；UserAccount是全局性。在集羣全部namespaces中，名稱具備惟一性，默認狀況下用戶爲admin；node

    用戶名稱能夠在kubeconfig中查看linux

    [root@Centos8 ~]# cd ~/.kube/
[root@Centos8 .kube]# ls
cache  config  http-cache
[root@Centos8 .kube]# cat config
    users:
    - name: kubernetes-admin
  • ServiceAccount是給運行在Pod的程序使用的身份認證，Pod容器的進程須要訪問API Server時用的就是ServiceAccount帳戶；ServiceAccount僅侷限它所在的namespace，每一個namespace都會自動建立一個default service account；建立Pod時，若是沒有指定Service Account，Pod則會使用default Service Account。

 

2.Secret 與 SA 的關係

Kubernetes設計了一種Secret資源，分爲兩類，一種是用於 ServiceAccount 的 kubernetes.io/ service-account-token，就是上邊說的 SA，另外一種就是用戶自定義的保密信息Opaque。nginx

 

3.默認的Service Account

ServiceAccount僅侷限它所在的namespace，因此在建立namespace時會自動建立一個默認的 SA，而 SA 建立時，也會建立對應的 Secret，下面操做驗證下：web

建立名稱空間算法

[root@Centos8 .kube]# kubectl create ns vfan
namespace/vfan created

查看SAdocker

[root@Centos8 .kube]# kubectl get sa -n vfan
NAME      SECRETS   AGE
default   1         67s

查看 SA 的 Secretjson

[root@Centos8 .kube]# kubectl describe sa default -n vfan
Name:                default
Namespace:           vfan
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   default-token-wwbc8
Tokens:              default-token-wwbc8
Events:              <none>

[root@Centos8 ~]# kubectl get secret -n vfan
NAME                  TYPE                                  DATA   AGE
default-token-wwbc8   kubernetes.io/service-account-token   3      3m15s

能夠看到，建立ns時默認建立了SA，SA默認建立了一個 kubernetes.io/service-account-token類型的secretvim

 

建立一個Podapi

vim pods.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-sa
  namespace: vfan
spec:
  containers:
  - name: test-sa
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
[root@Centos8 rbac]# kubectl create -f pods.yaml 
pod/test-sa created

[root@Centos8 rbac]# kubectl get pod -n vfan
NAME      READY   STATUS    RESTARTS   AGE
test-sa   1/1     Running   0          12s

[root@Centos8 rbac]# kubectl describe pod test-sa -n vfan
...
Containers:
  test-sa:
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-wwbc8 (ro)
Volumes:
  default-token-wwbc8:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-wwbc8
    Optional:    false
...

在不指定SA的狀況下，當前 ns下面的 Pod 會默認使用 「default」 這個 SA，對應的 Secret 會自動掛載到 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 目錄中，咱們能夠在 Pod 裏面獲取到用於身份認證的信息。

 

進入Pod Container內，查看 SA

[root@Centos8 rbac]# kubectl exec -it test-sa -n vfan -- /bin/bash
root@test-sa:/# cd /var/run/secrets/kubernetes.io/serviceaccount/
root@test-sa:/var/run/secrets/kubernetes.io/serviceaccount# ls
ca.crt    namespace  token

### 能夠看到有三個文件，做用分別爲
    ca.crt：根證書，用於Client端驗證API Server發送的證書
    namespace：標識這個service-account-token的做用域空間
    token：使用API Server私鑰簽名的JWT，用於訪問API Server時，Server端的驗證

 

4.使用自定義SA

建立一個 SA

[root@Centos8 rbac]# kubectl create sa vfansa -n vfan
serviceaccount/vfansa created

[root@Centos8 rbac]# kubectl get sa -n vfan
NAME      SECRETS   AGE
default   1         19m
vfansa    1         7s

[root@Centos8 rbac]# kubectl describe sa vfansa -n vfan
Name:                vfansa
Namespace:           vfan
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   vfansa-token-9s8f7
Tokens:              vfansa-token-9s8f7
Events:              <none>

[root@Centos8 rbac]# kubectl get secret -n vfan
NAME                  TYPE                                  DATA   AGE
default-token-wwbc8   kubernetes.io/service-account-token   3      19m
vfansa-token-9s8f7    kubernetes.io/service-account-token   3      49s

一樣，建立SA後，自動建立了對應的Secret

 

更新Pod，使用新建立的SA

vim pods.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-sa
  namespace: vfan
spec:
  containers:
  - name: test-sa
    image: nginx:1.2.1
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
  serviceAccountName: vfansa
[root@Centos8 rbac]# kubectl create -f pods.yaml 
pod/test-sa created

[root@Centos8 rbac]# kubectl describe pod test-sa -n vfan
...
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from vfansa-token-9s8f7 (ro)
Volumes:
  vfansa-token-9s8f7:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  vfansa-token-9s8f7
    Optional:    false
...

 

5.ServiceAccount中添加Image pull secrets

在筆者以前的博客中：Secret介紹及演示( http://www.javashuo.com/article/p-sonksbxt-mx.html )中說起到，可使用Secret來保存鏡像倉庫的登陸信息，來達到免登陸獲取image的效果，一樣，能夠將建立好的Secret直接與SA進行綁定，綁定完成後，只要使用此 SA 的 Pod，均可達到免登陸獲取image的效果

建立 docker-registry 的 Secret

[root@Centos8 rbac]# kubectl create secret docker-registry myregistrykey --docker-server=hub.vfancloud.com --docker-username=admin --docker-password=admin@123 --docker-email=vfan8991@163.com -n vfan
secret/myregistrykey created

[root@Centos8 rbac]# kubectl get secret -n vfan
NAME                  TYPE                                  DATA   AGE
default-token-wwbc8   kubernetes.io/service-account-token   3      62m
myregistrykey         kubernetes.io/dockerconfigjson        1      7s
vfansa-token-9s8f7    kubernetes.io/service-account-token   3      43m

 

將 docker-registry 的 Secret 添加到SA

kubectl edit sa vfansa -n vfan

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2020-08-30T03:38:47Z"
  name: vfansa
  namespace: vfan
  resourceVersion: "471829"
  selfLink: /api/v1/namespaces/vfan/serviceaccounts/vfansa
  uid: 8a44df93-b2d6-4e61-ad2e-25bc5852f66e
secrets:
- name: vfansa-token-9s8f7
imagePullSecrets:
- name: myregistrykey

 

查看 SA 的 Image pull secrets

[root@Centos8 rbac]# kubectl describe sa vfansa -n vfan 
Name:                vfansa
Namespace:           vfan
Labels:              <none> Annotations: <none> Image pull secrets: myregistrykey Mountable secrets: vfansa-token-9s8f7 Tokens: vfansa-token-9s8f7 Events: <none>

這個時候，只要是使用此 SA 的Pod，均可以在docker-registry拉取鏡像了，一樣，能夠把此 Secret 添加到default 的 SA 中，達到相同的效果

 

2、RBAC權限控制

1.RBAC介紹

在Kubernetes中，全部資源對象都是經過API對象進行操做，他們保存在etcd裏。而對etcd的操做咱們須要經過訪問 kube-apiserver 來實現，上面的Service Account其實就是APIServer的認證過程，而受權的機制是經過RBAC：基於角色的訪問控制實現。

 

2.Role and ClusterRole

在RBAC API中，Role表示一組規則權限，權限只會增長(累加權限)，不存在一個資源開始就有不少權限而經過RBAC對其進行減小的操做：Role 是定義在一個 namespace 中，而 ClusterRole 是集羣級別的。

下面咱們定義一個Role：

vim roles.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-role
  namespace: vfan
rules:
- apiGroups: [""]  # 爲空表示爲默認的core api group
  resources: ["pods"] # 數據源類型
  verbs: ["get","watch","list"]    #賦予的權限
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get","list","create","update","patch","delete","watch"]

以上Role策略表示在名字爲 vfan ns中，對Pods有get,watch,list的權限，對Deployment有......權限

 

ClusterRole 具備與 Role 相同權限角色控制能力，不一樣的就是 Cluster Role是集羣級別，它能夠用於：

  • 集羣級別的資源控制（例如 node 訪問權限）
  • 非資源型 endpoints（例如對某個目錄或文件的訪問：/healthz）
  • 全部命名空間資源控制（Pod、Deployment等）

 

vim clusterroles.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: test-clusterrole
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get","create","list"]

以上Cluster role策略表示，有get，create，list整個集羣service的權限

 

下面開始建立

## role
[root@Centos8 rbac]# kubectl create -f roles.yaml 
role.rbac.authorization.k8s.io/test-rbac created

[root@Centos8 rbac]# kubectl get role -n vfan 
NAME        AGE
test-rbac   27s

## cluster role
[root@Centos8 rbac]# kubectl get clusterrole -n vfan
NAME                                                                   AGE
admin                                                                  141d
cluster-admin                                                          141d
edit                                                                   141d
flannel                                                                141d
ingress-nginx                                                          90d
ingress-nginx-admission                                                90d
system:aggregate-to-admin                                              141d
system:aggregate-to-edit                                               141d
system:aggregate-to-view                                               141d

能夠看到，role和cluster role都已經建立成功，可是clusterrole除了此次建立的還有許多，其中以system開頭的所有是系統所用的，其餘的都是在裝一些插件時自動添加的，也要注意，咱們本身建立cluster role時不要以system開通，以避免分不清楚

 

3.RoleBinding and ClusterRoleBinding

RoleBinding能夠將角色中定義的權限授予用戶或用戶組，RoleBinding包含一組權限列表(Subjects)，權限列表中包含有不一樣形式的待授予權限資源類型(users,groups, or Service Account)：Rolebinding 一樣包含對被 Bind 的 Role 引用；RoleBinding 適用於某個命名空間內受權，ClusterRoleBinding適用於集羣範圍內的受權。

建立RoleBinding

vim rolebindings.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-rolebinding
  namespace: vfan
subjects:
- kind: User    # 權限資源類型
  name: vfan    # 名稱
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role    #要綁定的Role的類型(能夠是Role或ClusterRole)
  name: test-role    # Role的名稱
  apiGroup: rbac.authorization.k8s.io

此策略表示，將名稱爲test-role的Role的權限資源賦予名爲vfan的用戶，僅做用於vfan namespace。

 

RoleBinding一樣能夠引用ClusterRole來對當前 namespace 內用戶、用戶組或SA來進行受權，這種操做容許管理員在整個集羣中定義一些通用的ClusterRole，而後在不一樣的namespace中使用RoleBinding綁定。

vim rolebindings2.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-rolebinding2
  namespace: vfan
subjects:
- kind: User
  name: vfan
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: test-clusterrole
  apiGroup: rbac.authorization.k8s.io

以上策略表示，將名稱爲test-clusterrole的ClusterRole的資源權限賦予給了名稱爲vfan的用戶，雖然賦予的是ClusterRole，可是因爲Role僅做用於單個namespace，因此此資源策略僅僅對vfan namespace有效

 

vim clusterrolebindings.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: test-clusterrolebinding
subjects:
- kind: Group
  name: vfan
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: test-clusterrole
  apiGroup: rbac.authorization.k8s.io

以上策略表示，將name爲test-clusterrole的ClusterRole的資源權限賦予給groupname爲vfan的用戶組，此用戶組下全部用戶擁有對整個集羣的 test-clusterrole內的資源權限

 

實踐：建立一個用戶只能管理名爲 vfan 的NameSpace

1.建立系統用戶

[root@Centos8 rbac]# useradd vfan
[root@Centos8 rbac]# su - vfan 

## 進入vfan用戶測試訪問k8s集羣
[vfan@Centos8 ~]$ kubectl get pod 
The connection to the server localhost:8080 was refused - did you specify the right host or port?

默認確定是訪問不到的，若是想要訪問，必需要建立vfan用戶的訪問證書

 

2.爲 vfan 用戶建立訪問證書

## 下載證書生成工具 cfssl
[root@Centos8 bin]# wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
[root@Centos8 bin]# wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
[root@Centos8 bin]# wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64

## 更名，給執行權限
[root@Centos8 bin]# mv cfssl_linux-amd64 cfssl
[root@Centos8 bin]# mv cfssljson_linux-amd64 cfssljson
[root@Centos8 bin]# mv cfssl-certinfo_linux-amd64 cfssl-certinfo
[root@Centos8 bin]# chmod +x *
[root@Centos8 bin]# ll -h 
總用量 19M
-rwxr-xr-x 1 root root 9.9M 3月  30 2016 cfssl
-rwxr-xr-x 1 root root 6.3M 3月  30 2016 cfssl-certinfo
-rwxr-xr-x 1 root root 2.2M 3月  30 2016 cfssljson
[root@Centos8 bin]# mkdir /usr/local/vfancert
[root@Centos8 bin]# cd /usr/local/vfancert/

 

建立CA證書籤名請求JSON文件

vim vfan-csr.json

{
  "CN": "vfan",        # 用戶名稱
  "hosts": [],        # 主機地址，不填表示全部主機均可使用
  "key": {
    "algo": "rsa",    # 加密算法
    "size": 2048
},
  "names": [
    {
       "C": "CN",
       "L": "BeiJing",
       "O": "Ctyun",
       "ST": "BeiJing",            
       "OU": "System"
    }
  ]
}

 

開始建立訪問證書

[root@Centos8 vfancert]# cd /etc/kubernetes/pki/
[root@Centos8 pki]# cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /usr/local/vfancert/vfan-csr.json | cfssljson -bare vfanuser
2020/09/02 22:08:51 [INFO] generate received request
2020/09/02 22:08:51 [INFO] received CSR
2020/09/02 22:08:51 [INFO] generating key: rsa-2048
2020/09/02 22:08:51 [INFO] encoded CSR
2020/09/02 22:08:51 [INFO] signed certificate with serial number 191102646650271030964539871811792985454770130197
2020/09/02 22:08:51 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

## 建立成功，pki目錄下多出vfanuser-key.pem、vfanuser.pem和vfanuser.csr文件
[root@Centos8 pki]# ls
vfanuser.csr
vfanuser-key.pem
vfanuser.pem

 

3.爲 vfan 用戶生成集羣配置文件

## 設置api server的環境變量
[root@Centos8 vfancert]# export KUBE_APISERVER="https://192.168.152.53:6443"

## 建立kubeconfig文件，如下詳細參數信息可經過kubectl config set-cluster --help查看
[root@Centos8 vfancert]# kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --server=${KUBE_APISERVER} --kubeconfig=vfan.kubeconfig
Cluster "kubernetes" set.

## 配置文件生成
[root@Centos8 vfancert]# ls
vfan-csr.json  vfan.kubeconfig

## 設置客戶端參數，綁定用戶信息至kubeconfig中
[root@Centos8 vfancert]# kubectl config set-credentials vfanuser \
> --client-certificate=/etc/kubernetes/pki/vfanuser.pem \
> --client-key=/etc/kubernetes/pki/vfanuser-key.pem \
> --embed-certs=true \
> --kubeconfig=vfan.kubeconfig
User "vfanuser" set.

## 設置上下文參數
[root@Centos8 vfancert]# kubectl config set-context kubernetes \
> --cluster=kubernetes \
> --user=vfan \
> --namespace=vfan \
> --kubeconfig=vfan.kubeconfig
Context "kubenetes" created.

 

4.進行RoleBinding 驗證權限生效

vim vfanrolebind.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-rolebinding
  namespace: vfan
subjects:
- kind: User
  name: vfan
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: test-rbac    # 綁定上文中建立的名稱爲 test-rbac 的Role，具體權限，往上翻下哈
  apiGroup: rbac.authorization.k8s.io

 

把kubeconfig文件複製到 vfan 用戶的家目錄的.kube下

[root@Centos8 vfancert]# mkdir -p /home/vfan/.kube
[root@Centos8 vfancert]# cp vfan.kubeconfig /home/vfan/.kube/config
[root@Centos8 vfancert]# cd /home/vfan/.kube/
[root@Centos8 .kube]# ls
config

## 修改文件全部者
[root@Centos8 vfan]# chown -R vfan:vfan .kube/

 

切換上下文，使kubectl讀取到config的信息

[vfan@Centos8 .kube]$ kubectl config use-context kubernetes --kubeconfig=config 
Switched to context "kubernetes".

 

開始測試權限

[vfan@Centos8 .kube]$ kubectl get pod 
No resources found.

[vfan@Centos8 .kube]$ kubectl get svc 
Error from server (Forbidden): services is forbidden: User "vfan" cannot list resource "services" in API group "" in the namespace "vfan"

能夠get pod，可是不能夠get service，由於以前的Role中明確的表示了本身的權限

 

在vfan名稱空間下建立測試Deployment

## root用戶下建立
[root@Centos8 k8sYaml]# kubectl run deployment test-vfan --replicas=3 --image=nginx:1.2.1 --namespace=vfan

[root@Centos8 k8sYaml]# kubectl get pod -n vfan 
NAME                         READY   STATUS    RESTARTS   AGE
deployment-7b89b946d-5dtvp   1/1     Running   0          17s
deployment-7b89b946d-jpr5v   1/1     Running   0          17s
deployment-7b89b946d-r8k4l   1/1     Running   0          17s

## 前往vfan用戶查看
[vfan@Centos8 .kube]$ kubectl get pod 
NAME                         READY   STATUS    RESTARTS   AGE
deployment-7b89b946d-5dtvp   1/1     Running   0          67s
deployment-7b89b946d-jpr5v   1/1     Running   0          67s
deployment-7b89b946d-r8k4l   1/1     Running   0          67s

能夠看到，vfan用戶也能夠查看到相對應的Pod，由於vfan用戶在get pod時並無指定名稱空間，因此能夠證實vfan的默認名稱空間便是vfan

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