如何進行k8s的認證和授權(quán)

如何進行k8s的認證和授權(quán),很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細講解,有這方面需求的人可以來學(xué)習(xí)下,希望你能有所收獲。

發(fā)展壯大離不開廣大客戶長期以來的信賴與支持,我們將始終秉承“誠信為本、服務(wù)至上”的服務(wù)理念,堅持“二合一”的優(yōu)良服務(wù)模式,真誠服務(wù)每家企業(yè),認真做好每個細節(jié),不斷完善自我,成就企業(yè),實現(xiàn)共贏。行業(yè)涉及成都宣傳片制作等,在成都網(wǎng)站建設(shè)成都營銷網(wǎng)站建設(shè)、WAP手機網(wǎng)站、VI設(shè)計、軟件開發(fā)等項目上具有豐富的設(shè)計經(jīng)驗。

一、概述

Kubernetes只負責(zé)管理Service賬戶,不管理普通用戶的賬戶。Kubernetes沒有代表普通用戶帳戶的對象。 普通用戶信息無法通過API添加到集群。普通用戶由外部獨立服務(wù)管理。K8s通過authentication插件來實現(xiàn)用戶認證。K8s本身不管理用戶,也不會提供token。

二、k8s支持的認證類型

K8s支持X509 Client證書、token、basic auth認證等。

X509 Client證書:
     
啟動API Server時通過--client-ca-file=SOMEFILE選項提供給API Server。
靜態(tài)token文件:
     
1)啟動API Server時通過--token-auth-file=SOMEFILE選項提供給API Server。
      token文件是csv文件,包含如下內(nèi)容:
          token,user,uid,"group1,group2,group3"
     2)通過在http header中提供token信息以完成認證
        Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
            31ada4fd-adec-460c-809a-9e56ceb75269為具體的token值。
Bootstrap Token
   
相比于靜態(tài)token而言,此類token可動態(tài)管理。
basic auth:
     1)需要將包含password、username、uid、group等信息的csv文件通過--basic-auth-file=SOMEFILE選項提供給API Server,在API Server啟動時加載。
     2) 需要在http的header中填寫Authorization頭,其中包含“USER:PASSWORD”的Base64編碼后的字符串。
OpenID Connect Token:
   
采用OAuth3令牌響應(yīng)的id_token(而不是access_token)作為承載令牌。
    需要首先向身份提供商進行身份驗證。然后采用身份提供商給你的id_token訪問K8s。在Header中添加:Authorization: Bearer XXXXXXX
    要使用該認證方式,需要配置API Server:
          --oidc-issuer-url  身份提供商的URL,如:https://accounts.google.com,必選
          --oidc-client-id  客戶端標識,如:kubernetes  ,必選
          其他可選參數(shù)參見:https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens

   身份提供商需要支持OpenID Connect規(guī)范。如何進行k8s的認證和授權(quán)
  webhook Token認證: 
     
集群中需要配置如下兩個參數(shù):
      --authentication-token-webhook-config-file   用于配置remote service(負責(zé)認證)的文件
      --authentication-token-webhook-cache-ttl   用于配置身份認證結(jié)果的緩存時間,默認2分鐘
     webhook采用kubeconfig文件格式進行配置,文件中clusters是指remote service,而users是指API服務(wù)器webhook,如下示例:

# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # CA for verifying the remote service.
      server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
      client-key: /path/to/key.pem          # key matching the cert

# kubeconfig files require a context. Provide one for the API server.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authn-service
    user: name-of-api-sever
  name: webhook

       當客戶端需要認證攜帶的token時,authentication webhook向remote service POSTs一個 JSON格式的authentication.k8s.io/v1beta1 TokenReview對象,如下示例:

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "spec": {
    "token": "(BEARERTOKEN)"
  }
}

  remote service需要解析上述json,并對token進行校驗,然后通過response填寫校驗結(jié)果,成功的response如下示例,且http code必須是2XX:

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      "username": "janedoe@example.com",
      "uid": "42",
      "groups": [
        "developers",
        "qa"
      ],
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
    }
  }
}

 失敗的response如下示例:

 {

  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
    "authenticated": false
  }
}

Authenticating Proxy:
   
API服務(wù)器可以根據(jù)header values配置來識別users ,如X-Remote-User。
    在API Service啟動時進行相關(guān)配置,指明http的header中哪些key代表用戶名、哪些代表用戶的group等,如下示例:
     --requestheader-username-headers=X-Remote-User
     --requestheader-group-headers=X-Remote-Group
     --requestheader-extra-headers-prefix=X-Remote-Extra-
   如果發(fā)送請求如下:
GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile
    將產(chǎn)生如下用戶信息:
name: fido
groups:
- dogs
- dachshunds
extra:
  acme.com/project:
  - some-project
  scopes:
  - openid
  - profile

   為了防止header欺騙,Authenticating Proxy需要在檢查請求header之前,向API服務(wù)器提交有效的客戶端證書,以針對指定的CA進行驗證。
    
   
–requestheader-client-ca-file  必選, PEM-encoded的證書包。在為用戶名檢查請求header之前,必須根據(jù)指定文件中的證書頒發(fā)機構(gòu)呈現(xiàn)和驗證有效的客戶端證書。

 –requestheader-allowed-names 可選,(common names)通用名稱(cn)List。如果設(shè)置,則在檢查請求header用戶名之前,必須提交List中指定(common names)通用名中有效的客戶端證書。

 CA證書生成腳本:  

#!/bin/bash

mkdir -p ssl

cat << EOF > ssl/req.cnf
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = dex.example.com
EOF

openssl genrsa -out ssl/ca-key.pem 2048
openssl req -x509 -new -nodes -key ssl/ca-key.pem -days 10 -out ssl/ca.pem -subj "/CN=kube-ca"

openssl genrsa -out ssl/key.pem 2048
openssl req -new -key ssl/key.pem -out ssl/csr.pem -subj "/CN=kube-ca" -config ssl/req.cnf
openssl x509 -req -in ssl/csr.pem -CA ssl/ca.pem -CAkey ssl/ca-key.pem -CAcreateserial -out ssl/cert.pem -days 10 -extensions v3_req -extfile ssl/req.cnf

三、K8s雙向認證

k8s雙向認證時,客戶端證書的O={group},CN={username}
webhook方式下,k8s收到客戶端證書解析group和username,與webhook插件進行交互對用戶及權(quán)限進行認證
客戶端kubeconfig只需要在users下配置客戶端證書和私鑰文件:
    client-certificate
    client-key
    embed-certs=true

注:接入CISM時填寫group和username、選擇CA根證書文件,VNFM服務(wù)端自動生成客戶端證書和秘鑰文件,動態(tài)修改kubeconfig配置文件
或直接選擇客戶端證書,這種場景下需要事先確定VNFM使用的用戶名和對應(yīng)的group,先制作客戶端證書,建議采用這種方式。界面上不需要用戶填寫group和username

webhook token認證:
    從webhook的組件獲取token
    在header中帶給k8s
    k8s和webhook通訊對token進行認證
    webhook返回認證結(jié)果(用戶名、組、額外信息)
    
   
服務(wù)端開啟--authentication-token-webhook-config-file和--authentication-token-webhook-cache-ttl
# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # CA for verifying the remote service.
      server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
      client-key: /path/to/key.pem          # key matching the cert

# kubeconfig files require a context. Provide one for the API server.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authn-service
    user: name-of-api-sever
  name: webhook

webhook授權(quán):
   
服務(wù)端開啟--authorization-webhook-config-file
# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
  - name: name-of-remote-authz-service
    cluster:
      # CA for verifying the remote service.
      certificate-authority: /path/to/ca.pem
      # URL of remote service to query. Must use 'https'. May not include parameters.
      server: https://authz.example.com/authorize

# users refers to the API Server's webhook configuration.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
      client-key: /path/to/key.pem          # key matching the cert

# kubeconfig files require a context. Provide one for the API Server.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authz-service
    user: name-of-api-server
  name: webhook


雙向認證和token可以并存,如下:

user 定義用于向 kubernetes 集群進行身份驗證的客戶端憑據(jù)。

可用憑證有 client-certificate、client-key、token 和 username/password以及embed-certs。
username/password 和 token 是二者只能選擇一個,但 client-certificate 和 client-key 可以分別與它們組合。

可以使用 kubectl config set-credentials 添加或者修改 user 條目。

--embed-certs=true:將 ca.pem 和 admin.pem 證書內(nèi)容嵌入到生成的 kubectl.kubeconfig 文件中(不加時,寫入的是證書文件路徑);

helm方式訪問k8s時,如果要支持token,需要在kubeconfig中設(shè)置token,如果token動態(tài)獲取,則需要定時修改kubeconfig文件。


kubeconfig例子:
apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: scratch
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: scratch
    namespace: default
    user: experimenter
  name: exp-scratch
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    password: some-password
    username: exp

其中certificate-authority、client-certificate、client-key是證書和秘鑰文件的路徑,如果使用BASE64加密后的數(shù)據(jù),則需要采用下面的代替:
certificate-authority-data, client-certificate-data, client-key-data

看完上述內(nèi)容是否對您有幫助呢?如果還想對相關(guān)知識有進一步的了解或閱讀更多相關(guān)文章,請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,感謝您對創(chuàng)新互聯(lián)的支持。

文章標題:如何進行k8s的認證和授權(quán)
當前地址:http://bm7419.com/article26/geigcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)頁設(shè)計公司、網(wǎng)站維護品牌網(wǎng)站制作、關(guān)鍵詞優(yōu)化網(wǎng)站內(nèi)鏈、靜態(tài)網(wǎng)站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

綿陽服務(wù)器托管