005.OpenShift訪問控制-許可權-角色

一 Kubetcl namespace

1.1 namespace描述

Kubernetes namespace提供了將一組相關資源組合在一起的機制。在Red Hat OpenShift容器平臺中，project是一個帶有附加註釋的Kubernetes namespace。 namespace提供以下特性:

命名資源，以避免基本的命名衝突；
將管理許可權授予受信任的使用者；
限制使用者資源消耗的能力；
使用者和使用者組隔離。

1.2 project

project提供了一種機制，通過這種機制可以管理普通使用者對資源的訪問。project允許一組使用者獨立於其他組組織和管理其內容，必須允許使用者訪問專案。如果允許建立專案，使用者將自動訪問自己的專案。專案可以有單獨的name、display name和description。 name是專案的唯一識別符號，在使用CLI工具或API時都是基於name，name的最大長度為63個字元。 display name是專案在web控制檯中顯示的方式(預設為name)。 description是專案的更詳細描述，並且在web控制檯中也可見。以下元件適用於專案:

Object：pod、service、rc等；

Policies：決定使用者可以或不能對物件執行哪些操作的規則；
Constraints：可以限制的每種物件的配額。

1.3 cluster管理

叢集管理員可以建立專案並將專案的管理許可權委託給任何使用者。在OpenShift容器平臺中，專案用於對相關物件進行分組和隔離。管理員可以讓使用者訪問某些專案，允許他們建立自己的專案，並在單個專案中賦予他們管理許可權。管理員可以將角色應用於允許或限制其建立專案能力的使用者和組，同時可以在使用者初始登入之前分配角色。限制專案建立：從通過身份驗證的使用者和組中刪除self-provisioning叢集角色，將拒絕任何新專案的許可權。 [root@master ~]$ oc adm policy remove-cluster-role-from-group \ self-provisioner \ system:authenticated \ system:authenticated:oauth 授予專案建立：專案建立授予具有self-供應者角色和self-provisione叢集角色繫結的使用者。預設情況下，所有經過身份驗證的使用者都可以使用這些角色。 [root@master ~]$ oc adm policy add-cluster-role-to-group \ self-provisioner \ system:authenticated \ system:authenticated:oauth

1.4 建立project

如果專案建立許可權被授予使用者，則可以使用oc命令建立project。 [root@master ~]$ oc new-project demoproject \ --description="Demonstrate project creation" \ --display-name="demo_project"

二 OpenShift角色

2.1 角色概述

role具有不同級別的訪問和策略，包括叢集和本地策略。user和group可以同時與多個role關聯。執行oc description命令檢視角色及其繫結的詳細資訊。在叢集策略中具有cluster-admin預設角色的使用者可以檢視叢集策略和所有本地策略。在給定的本地策略中具有admin預設角色的使用者可以基於per-project檢視策略。可通過以下命令檢視當前的叢集繫結集，其中顯示繫結到不同角色的使用者和組。 [root@demo ~]# oc describe clusterPolicyBindings :default

2.2 檢視本地policy

儘管本地角色列表及其關聯的規則集在本地策略中是不可檢視的，但是所有預設角色仍然適用，並且可以新增到使用者或組中，cluster-admin預設角色除外。但是，本地繫結是可見的。可通過以下命令檢視當前的本地繫結，其中顯示繫結到不同角色的使用者和組。 [root@demo ~]# oc describe policyBindings :default 提示：預設情況下，在本地策略中，只會列出admin角色的繫結。但是，如果將其他預設角色新增到本地策略中的使用者和組，也會列出它們。

2.3 管理role繫結

向用戶或組新增或繫結角色，從而實現向用戶或組提供角色授予的相關訪問許可權。可以使用oc adm policy命令在使用者和組之間新增和刪除角色。當使用以下操作管理本地策略的使用者和組角色時，可以使用-n選項指定專案。如果沒有指定，則使用當前專案。常見管理本地策略操作：

命令	描述
oc adm policy who-can verb resource	設定哪些使用者可以對資源執行操作
oc adm policy add-role-to-user role username	將指定角色繫結到指定使用者
oc adm policy remove-role-from-user role username	從指定使用者中移除給定角色
oc adm policy remove-user username	刪除指定的使用者及其所有角色
oc adm policy add-role-to-group role groupname	將指定的角色繫結到指定的組
oc adm policy remove-role-fromgroup role groupname	從指定組中移除給定角色
oc adm policy remove-group groupname	刪除指定的組及其所有角色

還可以使用如下所示的的操作管理cluster policy的role binding，這類命令不需要-n選項，因為cluster policy不在namespace級別上操作。常見管理cluster policy操作：

命令	描述
oc adm policy add-cluster-role-to-user role username	將叢集中所有專案的指定角色繫結到指定使用者
oc adm policy remove-cluster-role-from-user role username	為叢集中的所有專案從指定使用者中刪除指定角色
oc adm policy add-cluster-role-togroup role groupname	為叢集中的所有專案將指定的角色繫結到指定的組
oc adm policy remove-cluster-role-from-group role groupname	從叢集中所有專案的指定組中移除給定角色

提示：oc policy命令應用於當前專案，而oc adm policy命令應用於叢集範圍的操作。示例：在example專案中為developer使用者提供admin角色。 [root@demo ~]# oc adm policy add-role-to-user admin developer -n example [root@demo ~]# oc describe policybindings :default -n example #檢查繫結

三安全上下文約束（SCCS）

3.1 SCCS概述

OpenShift提供安全上下文約束(SCCS)，它控制pod可以執行的操作和它可以訪問的資源。預設情況下，任何容器的執行都只授予受限制的SCC定義的功能。 SCCS相關命令：

  1 [user@demo ~]$ oc get scc			                        #列出可用的SCC
  2 [user@demo ~]$ oc describe scc scc_name		                #現實特定SCC詳細資訊
  3 [user@demo ~]$ oc adm policy add-scc-to-user scc_name user_name
  4 [user@demo ~]$ oc adm policy add-scc-to-group scc_name group_name	#要授予使用者或組特定的SCC
  5 [user@demo ~]$ oc adm policy remove-scc-from-user scc_name user_name
  6 [user@demo ~]$ oc adm policy remove-scc-from-group scc_name group_name	#從特定的SCC中刪除使用者或組

四服務賬戶

4.1 服務賬戶

service account提供了一種靈活的方法來控制API訪問，而無需共享常規使用者的憑據。如果應用程式需要訪問受限制的SCC未授予的功能，可建立一個新的、特定的service account並將其新增到適當的SCC中。例如，在預設情況下，OpenShift不支援部署需要提升特權的應用程式。若有此需求，可建立一個service account，修改dc，然後新增service account至SCC。示例：將anyuid配置為在容器中作為root使用者執行。 [user@demo ~]$ oc create serviceaccount useroot #建立一個名為useroot的新服務帳戶 [user@demo ~]$ oc patch dc/demo-app \ --patch '{"spec":{"template":{"spec":{"serviceAccountName": "useroot"}}}}' #修改應用程式的DC [user@demo ~]$ oc adm policy add-scc-to-user anyuid -z useroot #將useroot服務帳戶新增到anyuid SCC中，作為容器中的根使用者執行

4.2 Web管理user成員

OCP平臺的預設配置是，在使用者首次登入成功時，自動建立該使用者物件。要管理允許訪問專案的使用者，請以專案管理員或叢集管理員的身份登入到web控制檯，並選擇要管理的專案。在左側窗格中，單擊Resources——>membership進入專案member頁面。在Users列中，在突出顯示的文字框中輸入使用者名稱。在“新增另一個角色”列中，從使用者所在行的列表中選擇一個角色，然後單擊“新增”。

4.3 Cli管理user成員

CLI中如果自動建立物件功能被關閉，叢集管理員可通過如下方式建立新使用者： [root@master ~]$ oc create user demo-user 同時還需要在身份認證軟體中建立使用者，如為HTPasswdIdentityProvider才用戶命令如下： [root@master ~]$ htpasswd /etc/origin/openshift-passwd demo-user 要向用戶新增專案角色，首先使用oc project命令輸入專案，然後使用oc policy add-role-to-user命令： [root@master ~]$ oc policy add-role-to-user edit demo-user 要從使用者中刪除專案角色，使用oc policy remove-role-from-user命令： [root@master ~]$ oc policy remove-role-from-user edit demo-user 並不是所有OpenShift角色都由專案限定範圍。要分配這些規則，請使用oc adm policy command命令。 [root@master ~]$ oc adm policy add-cluster-role-to-user cluster-admin admin

4.4 身份驗證和授權

身份驗證層標識與對OpenShift容器平臺API的請求相關聯的使用者，然後授權層使用關於請求使用者的身份資訊來確定是否應該允許該請求。

user和group

OCP容器平臺中的使用者是一個可以向OpenShift API發出請求的實體。通常，這表示與OpenShift互動的develop或administrator的帳戶。可以將使用者分配給一個或多個組，每個組表示一組特定的角色(或許可權)。當需要通過管理授權策略給多個客戶授權時候，group會比較合適。例如允許訪問專案中的物件，而不是單獨授予使用者。

Authentication Tokens

API呼叫必須使用訪問令牌或X.509證書進行身份驗證，會話token表示使用者，並且是短期的，預設情況下在24小時內到期。可以通過執行oc whoami命令來驗證經過身份驗證的使用者。 [root@master ~]$ oc login -u demo-user [root@master ~]$ oc whoami demo-user

4.5 身份驗證型別

本環境中，身份驗證由HTPasswdIdentityProvider模組提供，該模組根據使用htpasswd命令生成的檔案驗證使用者名稱和密碼。 OpenShift容器平臺支援的其他認證型別包括:

Basic Authentication (Remote)

一種通用的後端整合機制，允許使用者使用針對遠端標識提供者驗證的憑據登入到OpenShift容器平臺。使用者將他們的使用者名稱和密碼傳送到OpenShift容器平臺，OpenShift平臺通過到伺服器的請求驗證這些憑據，並將憑據作為基本的Auth頭傳遞。這要求使用者在登入過程中向OpenShift容器平臺輸入他們的憑據。

Request Header Authentication

使用者使用請求頭值(如X-RemoteUser)登入到OpenShift容器平臺。它通常與身份驗證代理結合使用，身份驗證代理對使用者進行身份驗證，然後通過請求頭值為OpenShift容器平臺提供使用者標識。

Keystone Authentication

Keystone是一個OpenStack專案，提供標識、令牌、目錄和策略服務。OpenShift容器平臺與Keystone整合，通過配置OpenStack Keystone v3伺服器將使用者儲存在內部資料庫中，從而支援共享身份驗證。這種配置允許使用者使用Keystone憑證登入OpenShift容器平臺。

LDAP Authentication

使用者使用他們的LDAP憑證登入到OpenShift容器平臺。在身份驗證期間，LDAP目錄將搜尋與提供的使用者名稱匹配的條目。如果找到匹配項，則嘗試使用條目的專有名稱(DN)和提供的密碼進行簡單繫結。

GitHub Authentication

GitHub使用OAuth，它允許與OpenShift容器平臺整合使用OAuth身份驗證來促進令牌交換流。這允許使用者使用他們的GitHub憑證登入到OpenShift容器平臺。為了防止使用GitHub使用者id的未授權使用者登入到OpenShift容器平臺叢集，可以將訪問許可權限制在特定的GitHub組織中。

五管理專案及賬戶

5.1 前置準備

準備完整的OpenShift叢集，參考《003.OpenShift網路》2.1。

5.2 本練習準備

[student@workstation ~]$ lab secure-resources setup

5.3 建立htpasswd賬戶

  1 [kiosk@foundation0 ~]$ ssh root@master
  2 [root@master ~]# htpasswd -b /etc/origin/master/htpasswd user1 redhat
  3 [root@master ~]# htpasswd -b /etc/origin/master/htpasswd user2 redhat
  4 #新增基於htpasswd形式的user1和user2，密碼都為redhat。

5.4 設定策略

  1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com	#使用管理員登入
  2 [student@workstation ~]$ oc adm policy remove-cluster-role-from-group \
  3 self-provisioner system:authenticated:oauth
  4 #刪除所有賦予普通建立專案的功能，該命令可參考本環境如下目錄中的命令。
  5 [student@workstation ~]$ cat /home/student/DO280/labs/secure-resources/configure-policy.sh
  6 #!/bin/bash
  7 oc adm policy remove-cluster-role-from-group \
  8     self-provisioner system:authenticated system:authenticated:oauth

5.5 驗證策略

  1 [student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com	#使用普通使用者user1登入
  2 [student@workstation ~]$ oc new-project test					#測試建立project
  3 Error from server (Forbidden): You may not request a new project via this API.

5.6 建立專案

  1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com	#使用叢集管理員登入
  2 [student@workstation ~]$ oc new-project project-user1				#建立兩個專案
  3 [student@workstation ~]$ oc new-project project-user2

5.7 將專案與user關聯

  1 #選擇專案1
  2 Now using project "project-user1" on server "https://master.lab.example.com:443".
  3 [student@workstation ~]$ oc policy add-role-to-user admin user1		#將user1新增為專案1的管理員
  4 role "admin" added: "user1"
  5 [student@workstation ~]$ oc policy add-role-to-user edit user2		#將user2新增為專案1的開發員
  6 role "edit" added: "user2"
  7 
  8 [student@workstation ~]$ oc project project-user2			        #選擇專案2
  9 Now using project "project-user2" on server "https://master.lab.example.com:443".
 10 [student@workstation ~]$ oc policy add-role-to-user edit user2		#將user2新增為專案2的開發員
 11 role "edit" added: "user2"

5.8 驗證訪問

  1 [student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com	#使用user1登入
  2 [student@workstation ~]$ oc project project-user1					#驗證專案1的訪問
  3 Already on project "project-user1" on server "https://master.lab.example.com:443".
  4 [student@workstation ~]$ oc project project-user2					#驗證專案2的訪問
  5 error: You are not a member of project "project-user2".
  6 You have one project on this server: project-user1
  7 
  8 [student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com	#使用user2登入
  9 [student@workstation ~]$ oc project project-user1
 10 Already on project "project-user1" on server "https://master.lab.example.com:443".	#驗證專案1的訪問
 11 [student@workstation ~]$ oc project project-user2
 12 Now using project "project-user2" on server "https://master.lab.example.com:443".	#驗證專案2的訪問

5.9 部署特權應用

  1 [student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc project project-user1
  3 Now using project "project-user1" on server "https://master.lab.example.com:443".
  4 [student@workstation ~]$ oc new-app --name=nginx --docker-image=registry.lab.example.com/nginx:latest
  5 #使用在專案1上不具備admin許可權的使用者user2登入，並部署應用，會出現如下提示：

5.10 驗證部署

  1 [student@workstation ~]$ oc get pods

結論：由上可知，部署失敗是因為容器映像需要root使用者，pod以CrashLoopBackOff或錯誤狀態結束。

5.11 故障排除

若要解決此故障需要減少特定專案的安全限制。要使用特權訪問執行容器，可建立一個允許pod使用作業系統普通使用者執行的service account。如下部分需要具有專案管理員特權的使用者執行，而另一些操作需要具有叢集管理員特權的使用者執行。本環境中，相關操作命令可以從/home/student/DO280/labs/secure-resources資料夾中的configure-sc.sh指令碼執行或複製。

  1 [student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com	#使用專案1的admin賬戶登入 
  2 [student@workstation ~]$ oc create serviceaccount useroot		  #建立服務賬戶
  3 serviceaccount "useroot" created
  4 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com	#使用叢集管理員登入
  5 [student@workstation ~]$ oc project project-user1			  #選擇專案1
  6 Already on project "project-user1" on server "https://master.lab.example.com:443".
  7 [student@workstation ~]$ oc adm policy add-scc-to-user anyuid -z useroot  #設定SCC策略
  8 scc "anyuid" added to: ["system:serviceaccount:project-user1:useroot"]    #將服務帳戶與anyuid安全上下文關聯，此操作需要叢集管理員使用者。
  9 [student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com	#切換user2使用者
 10 [student@workstation ~]$ oc project project-user1
 11 Already on project "project-user1" on server "https://master.lab.example.com:443".
 12 [student@workstation ~]$ oc patch dc nginx --patch='{"spec":{"template":{"spec":{"serviceAccountName": "useroot"}}}}'

#更新負責管理nginx的dc資源，任何開發人員使用者都可以執行此操作。本環境中，相關操作命令可以從/home/student/DO280/labs/secure-resources資料夾中的configure-sc.sh指令碼執行或複製。

5.12 驗證確認

  1 [student@workstation ~]$ oc get pods
  2 NAME            READY     STATUS    RESTARTS   AGE
  3 nginx-2-98k8f   1/1       Running   0          3m
  4

5.13 暴露服務

  1 [student@workstation ~]$ oc expose svc nginx
  2 route "nginx" exposed
  3 [student@workstation ~]$ oc get svc
  4 NAME      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
  5 nginx     ClusterIP   172.30.118.63   <none>        80/TCP    13m
  6 [student@workstation ~]$ oc get route
  7 NAME      HOST/PORT                                  PATH      SERVICES   PORT      TERMINATION   WILDCARD
  8 nginx     nginx-project-user1.apps.lab.example.com             nginx      80-tcp                  None

5.14 測試訪問

  1 [student@workstation ~]$ curl -s http://nginx-project-user1.apps.lab.example.com

5.15 策略刪除演示

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated system:authenticated:oauth
  3 cluster role "self-provisioner" added: ["system:authenticated" "system:authenticated:oauth"]
  4 [student@workstation ~]$ oc delete project project-user1
  5 project "project-user1" deleted
  6 [student@workstation ~]$ oc delete project project-user2
  7 [root@master ~]# htpasswd -D /etc/origin/master/htpasswd user1 
  8 [root@master ~]# htpasswd -D /etc/origin/master/htpasswd user2

#為所有常規使用者重新啟用專案建立，即重置為初始狀態。本環境中，相關操作命令可以從/home/student/DO280/labs/secure-resources資料夾中的restore-policy.sh指令碼執行或複製。

六管理加密資訊

6.1 secret特性

Secret物件型別提供了一種機制來儲存敏感資訊，如密碼、OCP客戶端配置檔案、Docker配置檔案和私有倉庫憑據。Secrets將敏感內容與Pod解耦。可以使用Volume外掛將Secrets掛載到容器上，或者系統可以使用Secrets代表pod執行操作。 Secrets的主要特徵包括:

Secrets data可以獨立於其定義引用。
Secrets data Volume由臨時檔案儲存支援。
可以在名稱空間中共享Secrets data。

6.2 建立Secrets

在依賴於該Secrets的pod之前建立一個Secrets。

  1 [user@demo ~]$ oc create secret generic secret_name \
  2 --from-literal=key1=secret1 \
  3 --from-literal=key2=secret2	#用secret data建立secret物件
  4 [user@demo ~]$ oc secrets add --for=mount serviceaccount/serviceaccount-name \
  5 secret/secret_name		#更新pod的服務帳戶，允許引用該secrets。

例如，允許一個執行在指定服務帳戶下的pod掛載一個secrets 建立一個pod，該pod使用環境變數或資料卷作為檔案的方式使用該secret，通常使用模板完成。

6.3 使用secret暴露Pod

secrets可以作為資料卷掛載，也可以作為環境變數以便供pod中的容器使用。例如，要向pod公開一個secrets，首先建立一個secrets並將username和password以k/v形式配置，然後將鍵名分配給pod的YAML檔案env定義。示例：建立名為demo-secret的secrets，它定義使用者名稱和密碼為username/demo-user。 [user@demo ~]$ oc create secret generic demo-secret \ --from-literal=username=demo-user 要使用前面的secret作為MySQL資料庫pod的資料庫管理員密碼，請定義環境變數，並引用secret名稱和密碼。

  1 env:
  2   - name: MYSQL_ROOT_PASSWORD
  3     valueFrom:
  4       secretKeyRef:
  5        key: username
  6        name: demo-secret

6.4 web端管理secret

從web控制檯管理secret: 1. 以授權使用者身份登入到web控制檯。 2. 建立或選擇一個專案來承載secret。 3. 導航到resource——>secrets。

6.5 Secret使用場景

password和user names

敏感資訊(如password和user name)可以儲存在一個secret中，該secret被掛載為容器中的資料卷。資料顯示為位於容器的資料卷目錄中的檔案中的內容。然後，應用程式(如資料庫)可以使用這些secret對使用者進行身份驗證。

傳輸層安全性(TLS)和金鑰對

通過讓叢集將簽名證書和金鑰對生成到專案名稱空間中的secret中，可以實現對服務的通訊的保護。證書和金鑰對使用PEM格式儲存以類似tls.crt和tls.key的格式儲存在secret的pod中。

七 ConfigMap物件

7.1 ConfigMap概述

ConfigMaps物件類似於secret，但其設計目的是支援處理不包含敏感資訊的字串。ConfigMap物件持有配置資料的鍵值對，這些配置資料可以在pods中使用，或者用於儲存系統元件(如控制器)的配置資料。 ConfigMap物件提供了將配置資料注入容器的機制。ConfigMap儲存精細的粒度資訊，比如單個屬性，或者詳細資訊，比如整個配置檔案或JSON blob。

7.2 CLI建立ConfigMap

可以使用--from-literal選項從CLI建立ConfigMap物件。示例：建立一個ConfigMap物件，該物件將IP地址172.20.30.40分配給名為serverAddress的ConfigMap金鑰。

  1 [user@demo ~]$ oc create configmap special-config \
  2 --from-literal=serverAddress=172.20.30.40
  3 [user@demo ~]$ oc get configmaps special-config -o yaml		#檢視configMap
  4 apiVersion: v1
  5 data:
  6   key1: serverAddress=172.20.30.40
  7 kind: ConfigMap
  8 metadata:
  9   creationTimestamp: 2017-07-10T17:13:31Z
 10   name: special-config
 11 ……
 12 在配置對映的pod定義中填充環境變數APISERVER。
 13 env:
 14   - name: APISERVER
 15       valueFrom:
 16         configMapKeyRef:
 17           name: special-config
 18           key: serverAddress

7.3 web管理ConfigMap

從web控制檯管理ConfigMap物件: 1. 以授權使用者身份登入到web控制檯。 2. 建立或選擇一個專案來承載ConfigMap。 3. 導航到資源→配置對映。

八加密練習

8.1 前置準備