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

木二發表於2020-06-20

一 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 驗證確認

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


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 前置準備

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

8.2 本練習準備

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

8.3 建立專案

  1 [student@workstation ~]$ oc login -u developer -p redhat
  2 [student@workstation ~]$ cd /home/student/DO280/labs/secure-secrets/
  3 [student@workstation secure-secrets]$ less mysql-ephemeral.yml		#匯入本環境MySQL模板

模板解讀：

該mysql-ephemeral.yml模板檔案，包含openshift專案中的mysql臨時模板，pod所需的其他環境變數由模板引數初始化，並具有預設值。

但沒有secret定義，後續操作將手動建立模板所需的secret。

根據模板的要求，建立一個包含MySQL容器image使用的憑證的secret，將這個secret命名為mysql。

應用程式訪問的資料庫使用者名稱由database-user定義。

資料庫使用者的密碼由database-password定義。

資料庫管理員密碼由database-root-password定義

8.4 建立新secret

  1 [student@workstation secure-secrets]$ oc create secret generic mysql \
  2 --from-literal='database-user'='mysql' \
  3 --from-literal='database-password'='redhat' \
  4 --from-literal='database-root-password'='do280-admin'
  5 [student@workstation secure-secrets]$ oc get secret mysql -o yaml	#確認secret

8.5 建立應用

  1 [student@workstation secure-secrets]$ oc new-app --file=mysql-ephemeral.yml
  2 [student@workstation secure-secrets]$ oc get pods		#確認應用
  3 NAME            READY     STATUS    RESTARTS   AGE
  4 mysql-1-j4fnz   1/1       Running   0          1m

8.6 埠轉發

  1 [student@workstation secure-secrets]$ cd
  2 [student@workstation ~]$ oc port-forward mysql-1-j4fnz 3306:3306

提示：驗證完成之前forward不要關閉。

8.7 確認驗證

  1 [student@workstation ~]$ mysql -uroot -pdo280-admin -h127.0.0.1	#新開終端測試MySQL

九管理security policy

9.1 OCP authorization授權

OCP定義了使用者可以執行的兩組主要操作：

與專案相關的操作(也稱為本地策略)：project-related

與管理相關的操作(也稱為叢集策略)：administration-related

由於這兩種策略都有大量可用的操作，所以將一些操作分組並定義為角色。

預設角色	描述
cluster-admin	此角色中的所有使用者都可以管理OpenShift叢集。
cluster-status	此角色中的所有使用者都提供對叢集資訊的只讀訪問。

為管理本地政策，OCP提供以下角色：

預設角色	描述
edit	角色中的使用者可以從專案中建立、更改和刪除公共應用程式資源，比如service和dc。但是不能對限制範圍和配額等管理資源採取行動，也不能管理對專案的訪問許可權。
basic-user	角色中的使用者具有對專案的讀訪問權。
self-provisioner	角色中的使用者可以建立新專案。這是一個叢集角色，而不是專案角色。
admin	角色中的使用者可以管理專案中的所有資源，包括授予對專案的其他使用者的訪問權

除了能夠建立新應用程式之外，admin角色還允許使用者訪問專案資源，比如配額和限制範圍。

edit角色允許使用者在專案中充當開發人員，但要在專案管理員配置的約束下工作。

9.2 相關命令

  1 向叢集使用者新增角色
  2 $ oc adm policy add-cluster-role-to-user cluster-role username
  3 示例：將普通使用者更改為叢集管理員。
  4 $ oc adm policy add-cluster-role-to-user cluster-role username
  5 從使用者中刪除叢集角色
  6 $ oc adm policy remove-cluster-role-from-user cluster-role username
  7 示例：將叢集管理員更改為普通使用者。
  8 $ oc adm policy remove-cluster-role-from-user cluster-admin username
  9 將指定的使用者繫結到專案中的角色
 10 $ oc adm policy add-role-to-user role-name username -n project
 11 示例：在WordPress專案中dev使用者繫結basic-user角色。
 12 $ oc adm policy add-role-to-user basic-user dev -n wordpress

9.3 許可權及規則

OpenShift將一組規則集合成一個角色，規則由謂詞和資源定義。如create user是OpenShift中的一條規則，它是一個名為cluster-admin的角色的所擁有的許可權的一部分。

  1 $ oc adm policy who-can delete user

9.4 user型別

與OCP的互動基於使用者，OCP的user物件表示可以通過向該使用者或使用者組新增角色來從而實現相應許可權的授予。

Regular users：通常以這種使用者型別與OCP互動，常規使用者用User物件表。例如，user1，user2。

System users：通常在安裝OCP中定義基礎設施時自動建立的，主要目的是使基礎設施能夠安全地與API互動。包括叢集管理員(可以訪問所有內容)、每個節點的使用者、路由器和內部倉庫使用的使用者，以及各種其他使用者。還存在一個匿名系統使用者，預設情況下，該使用者用於未經身份驗證的請求。system user主要包括：system:admin、system:openshift-registry和system:node:node1.example.com。

Service accounts：這些是與專案關聯的特殊系統使用者。有些是在第一次建立專案時自動建立的，專案管理員可以建立多個，以便定義對每個專案內容的訪問。Service accounts由ServiceAccount物件表示。Service accounts主要包括：system:serviceaccount:default:deployer和system:serviceaccount:foo:builder。

每個使用者在訪問OpenShift容器平臺之前必須進行身份驗證。沒有身份驗證或身份驗證無效的API請求將使用匿名系統使用者身份驗證來請求服務。身份驗證成功後，策略確定使用者被授權做什麼。

9.5 安全上下文約束（SCCS）

OpenShift提供了一種名為安全上下文約束的安全機制，它限制對資源的訪問，但不限制OpenShift中的操作。

SCC限制從OpenShift中執行的pod到主機環境的訪問：

執行特權容器

請求容器的額外功能

更改容器的SELinux上下文

更改使用者ID

社群開發的一些容器可能需要放鬆安全上下文約束，因為它們可能需要訪問預設禁止的資源，例如檔案系統、套接字或訪問SELinux上下文。

OpenShift定義的安全上下文約束(SCCs)可以使用以下命令作為叢集管理員列出。

$ oc get scc

SCC通常有以下7中SCCS：

anyuid

hostaccess

hostmount-anyuid

nonroot

privileged

restricted（預設）

$ oc describe scc anyuid		#檢視某一種SCC詳情

OpenShift建立的所有容器都使用restricted型別的SCC，它提供了對OpenShift外部資源的有限訪問。

對於anyuid安全上下文，run as user策略被定義為RunAsAny，表示pod可以作為容器中可用的任何使用者ID執行。這允許需要特定使用者使用特定使用者ID執行命令的容器。

要將容器更改為使用不同的SCC執行，需要建立繫結到pod的服務帳戶。

$ oc create serviceaccount service-account-name		#首先建立服務賬戶

$ oc adm policy add-scc-to-user SCC -z service-account	#將服務帳戶與SCC關聯

要確定哪個帳戶可以建立需要更高安全性要求的pod，可以使用scc-subject-review子命令。

$ oc export pod pod-name > output.yaml

$ oc adm policy scc-subject-review -f output.yaml

9.6 OpenShift與SELinux

OpenShift要求在每個主機上啟用SELinux，以便使用強制訪問控制提供對資源的安全訪問。同樣，由OpenShift管理的Docker容器需要管理SELinux上下文，以避免相容性問題。

為了最小化在不支援SELinux的情況下執行容器的風險，可以建立SELinux上下文策略。

為了更新SELinux上下文，可以使用現有的SCC作為起點生成一個新的SCC。

$ oc export scc restricted > custom_selinux.yml		#匯出預設的SCC

編輯匯出的YAML檔案以更改SCC名稱和SELinux上下文。

$ oc create -f yaml_file				#使用修改後的ymal重新建立一個SCC

9.7 特權容器

有些容器可能需要訪問主機的執行時環境。S2I構建器容器需要訪問宿主docker守護程式來構建和執行容器。

例如，S2I構建器容器是一類特權容器，它要求訪問超出其自身容器的限制。這些容器可能會帶來安全風險，因為它們可以使用OpenShift節點上的任何資源。通過建立具有特權訪問權的服務帳戶，可以使用SCCs啟用特權容器的訪問。

十資源訪問控制綜合實驗

10.1 前置準備

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

10.2 本練習準備

  1 [student@workstation ~]$ lab secure-review setup

10.3 建立使用者

  1 [root@master ~]# htpasswd /etc/origin/master/htpasswd user-review
  2 New password: 【redhat】
  3 Re-type new password: 【redhat】

10.4 修改策略

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ oc adm policy remove-cluster-role-from-group \
  3 self-provisioner system:authenticated system:authenticated:oauth
  4 禁用所有常規使用者的專案建立功能

10.5 確認驗證

  1 [student@workstation ~]$ oc login -u user-review -p redhat
  2 [student@workstation ~]$ oc new-project test			#普通使用者無法建立專案
  3 Error from server (Forbidden): You may not request a new project via this API.

10.6 建立專案

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ oc new-project secure-review		#使用管理員建立專案

10.7 授權使用者

  1 [student@workstation ~]$ oc project secure-review
  2 Already on project "secure-review" on server "https://master.lab.example.com:443".
  3 [student@workstation ~]$ oc policy add-role-to-user edit user-review	#將edit的role和user-review進行關聯

10.8 測試訪問

  1 [student@workstation ~]$ oc login -u user-review -p redhat
  2 [student@workstation ~]$ oc project secure-review		#測試訪問
  3 Already on project "secure-review" on server "https://master.lab.example.com:443".

10.9 檢查模板

  1 [student@workstation ~]$ cd /home/student/DO280/labs/secure-review/
  2 [student@workstation secure-review]$ less mysql-ephemeral.yml

模板解讀：

該mysql-ephemeral.yml模板檔案，包含openshift專案中的mysql臨時模板，pod所需的其他環境變數由模板引數初始化，並具有預設值。

但沒有secret定義，後續操作將手動建立模板所需的secret。

根據模板的要求，建立一個包含MySQL容器image使用的憑證的secret，將這個secret命名為mysql。

應用程式訪問的資料庫使用者名稱由database-user定義。

資料庫使用者的密碼由database-password定義。

資料庫管理員密碼由database-root-password定義

使用user-review developer使用者建立一個名為mysql的secret。這個secret應該儲存使用者名稱mysql、密碼redhat和資料庫管理員密碼do280-admin。

資料庫使用者名稱由database-user定義。此使用者的密碼由mysql secret金鑰定義。

資料庫管理員密碼由database-root-password定義。

10.10 建立secret

  1 [student@workstation secure-review]$ oc create secret generic mysql \
  2 --from-literal='database-user'='mysql' \
  3 --from-literal='database-password'='redhat' \
  4 --from-literal='database-root-password'='do280-admin'
  5 [student@workstation secure-review]$ oc get secret mysql -o yaml	#確認驗證secret

10.11 部署應用

  1 [student@workstation secure-review]$ oc new-app --file=mysql-ephemeral.yml
  2 [student@workstation secure-review]$ oc get pods
  3 NAME            READY     STATUS    RESTARTS   AGE
  4 mysql-1-2lr7t   1/1       Running   0          31s

10.12 轉發埠

  1 [student@workstation ~]$ oc port-forward mysql-1-2lr7t 3306:3306

10.13 測試訪問

  1 [student@workstation ~]$ mysql -umysql -predhat -h127.0.0.1

10.14 部署phpmyadmin應用

使用內部倉庫registry.lab.example.com的image部署phpmyadmin:4.7容器。phpmyadmin:4.7容器需要名為PMA_HOST的環境變數來提供MySQL伺服器的IP地址。

使用模板建立一個基於FQND的MySQL pod的service。

為使用模板建立的MySQL伺服器pod使用服務FQDN，該模板是mysql.secure-review.svc.cluster.local。

  1 [student@workstation ~]$ oc new-app --name=phpmyadmin \
  2 --docker-image=registry.lab.example.com/phpmyadmin/phpmyadmin:4.7 \
  3 -e PMA_HOST=mysql.secure-review.svc.cluster.local

結論：該命令會發出警告，提示需要root特權。預設情況下，OpenShift不支援使用作業系統的root使用者執行容器。

10.15 檢視pod

  1 [student@workstation ~]$ oc get pods
  2 NAME                 READY     STATUS    RESTARTS   AGE
  3 mysql-1-2lr7t        1/1       Running   0          8m
  4 phpmyadmin-1-v7tl7   0/1       Error     2          1m
  5 因為沒有root許可權，因此部署失敗，需要提權。

10.16 授予許可權

  1 [student@workstation ~]$ oc login -u admin -p redhat			#使用管理員登入
  2 [student@workstation ~]$ oc create serviceaccount phpmyadmin-account	#首先建立服務賬戶
  3 [student@workstation ~]$ oc adm policy add-scc-to-user anyuid -z phpmyadmin-account
  4 scc "anyuid" added to: ["system:serviceaccount:secure-review:phpmyadmin-account"]	#將服務帳戶與anyuid安全上下文關聯

10.17 更新應用

  1 [student@workstation ~]$ oc patch dc phpmyadmin --patch='{"spec":{"template":{"spec":{"serviceAccountName": "phpmyadmin-account"}}}}'

#更新負責管理phpmyadmin的dc資源，任何開發人員使用者都可以執行此操作。

本環境中，相關操作命令可以從/home/student/DO280/labs/secure-review資料夾中的patch-dc.sh指令碼執行或複製。

10.18 確認驗證

  1 [student@workstation ~]$ oc login -u user-review -p redhat
  2 [student@workstation ~]$ oc get pods			#確認pod是否正常
  3 NAME                 READY     STATUS    RESTARTS   AGE
  4 mysql-1-2lr7t        1/1       Running   0          13m
  5 phpmyadmin-2-bdjvq   1/1       Running   0          1m

10.19 暴露服務

  1 [student@workstation ~]$ oc expose svc phpmyadmin --hostname=phpmyadmin.apps.lab.example.com

10.20 訪問測試

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

10.21 確認及刪除

  1 [student@workstation ~]$ lab secure-review grade		#環境指令碼判斷
  2 [student@workstation ~]$ oc login -u admin -p redhat
  3 [student@workstation ~]$ oc adm policy add-cluster-role-to-group \
  4 self-provisioner system:authenticated system:authenticated:oauth
  5 [student@workstation ~]$ oc delete project secure-review
  6 [student@workstation ~]$ ssh root@master htpasswd -D \
  7 /etc/origin/master/htpasswd user-review			#刪除使用者
  8 [student@workstation ~]$ oc delete user user-review		#刪除專案

Quarkus中基於角色的許可權訪問控制教程
2024-05-03
Java 訪問許可權控制（6）
2019-01-19
Java訪問許可權
使用nginx控制ElasticSearch訪問許可權
2019-03-28
NginxElasticsearch訪問許可權
論Java訪問許可權控制的重要性
2018-12-06
Java訪問許可權
k8s結合jumpserver做kubectl許可權控制使用者在多個namespaces的訪問許可權 rbac許可權控制
2021-07-09
K8SServernamespace訪問許可權
public, private, protected 訪問許可權
2024-07-07
訪問許可權
mongoDB 3.0 安全許可權訪問
2023-04-10
MongoDB
Ant Design Pro v4 基於角色的許可權訪問控制實戰教程 #1 介紹
2019-12-26
一文讀懂 TKE 及 Kubernetes 訪問許可權控制
2021-01-21
訪問許可權
許可權控制
2019-10-30
17-成員訪問許可權
2019-02-22
訪問許可權
Laravel——使用者角色許可權控制包 Laravel-permission
2019-04-18
Laravel
無程式碼實現CRM角色許可權問題
2020-08-21
遇到問題，需要開發角色許可權模組
2020-03-23
shiro許可權控制
2018-12-04
訪問許可權控制系統|全方位認識 mysql 系統庫
2019-07-29
訪問許可權MySql
jCasbin: 強大的訪問控制、許可權管理框架，支援 ACL, RBAC, ABAC
2020-08-12
框架
Ant Design Pro v4 基於角色的許可權訪問控制實戰教程 #2 初始化專案
2019-12-26
win10老跳出訪問許可權怎麼辦_win10訪問許可權怎麼關閉
2020-09-04
Win10訪問許可權
Ubuntu共享資料夾訪問許可權問題
2020-10-28
Ubuntu訪問許可權
如何用 Vue 實現前端許可權控制（路由許可權 + 檢視許可權 + 請求許可權）
2018-04-12
Vue前端路由
用無程式碼解決CRM角色許可權問題
2020-09-09
教程示例：控制儲存空間和資料夾的訪問許可權
2018-07-04
訪問許可權
使用者角色許可權控制包 Laravel-permission 使用說明
2018-04-12
Laravel
Linux的許可權控制
2024-07-27
Linux
如何在 Linux 中配置 sudo 訪問許可權
2019-04-18
Linux訪問許可權
Think Authz：支援 ACL、RBAC、ABAC 等模型的授權（角色和許可權控制）庫
2019-10-26
模型
MySQL5.7&8.0許可權-角色管理
2024-07-02
MySql
Oracle使用者角色許可權管理
2018-04-11
Oracle
win共享檔案沒有許可權訪問怎麼辦 win10共享檔案許可權訪問的方法
2022-04-26
Win10
友好訪問許可權篇：訪問語音、相簿、通訊錄----iOS
2021-01-03
訪問許可權iOS
Spring Security實現基於RBAC的許可權表示式動態訪問控制
2022-04-19
Spring
geoserver控制服務訪問許可權-類似百度地圖的key
2021-11-11
Server訪問許可權地圖
postgresql關於訪問檢視需要的許可權
2020-03-25
SQL
Laravel實現許可權控制
2020-09-30
Laravel
使用者角色許可權管理架構
2018-06-13
架構
採坑之Android手機訪問相簿許可權問題
2019-02-26
Android
許可權維持專題：域控制器許可權維持
2022-02-21

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

一 Kubetcl namespace

1.1 namespace描述

1.2 project

1.3 cluster管理

1.4 建立project

二 OpenShift角色

2.1 角色概述

2.2 檢視本地policy

2.3 管理role繫結

三 安全上下文約束（SCCS）

3.1 SCCS概述

四 服務賬戶

4.1 服務賬戶

4.2 Web管理user成員

4.3 Cli管理user成員

4.4 身份驗證和授權

4.5 身份驗證型別

五 管理專案及賬戶

5.1 前置準備

5.2 本練習準備

5.3 建立htpasswd賬戶

5.4 設定策略

5.5 驗證策略

5.6 建立專案

5.7 將專案與user關聯

5.8 驗證訪問

5.9 部署特權應用

5.10 驗證部署

5.11 故障排除

5.12 驗證確認

5.13 暴露服務

5.14 測試訪問

5.15 策略刪除演示

六 管理加密資訊

6.1 secret特性

6.2 建立Secrets

6.3 使用secret暴露Pod

6.4 web端管理secret

6.5 Secret使用場景

七 ConfigMap物件

7.1 ConfigMap概述

7.2 CLI建立ConfigMap

7.3 web管理ConfigMap

八 加密練習

8.1 前置準備

8.2 本練習準備

8.3 建立專案

8.4 建立新secret

8.5 建立應用

8.6 埠轉發

8.7 確認驗證

九 管理security policy

9.1 OCP authorization授權

9.2 相關命令

9.3 許可權及規則

9.4 user型別

9.5 安全上下文約束（SCCS）

9.6 OpenShift與SELinux

9.7 特權容器

十 資源訪問控制綜合實驗

10.1 前置準備

10.2 本練習準備

10.3 建立使用者

10.4 修改策略

10.5 確認驗證

10.6 建立專案

10.7 授權使用者

10.8 測試訪問

10.9 檢查模板

10.10 建立secret

10.11 部署應用

10.12 轉發埠

10.13 測試訪問

10.14 部署phpmyadmin應用

10.15 檢視pod

10.16 授予許可權

10.17 更新應用

10.18 確認驗證

10.19 暴露服務

三安全上下文約束（SCCS）

四服務賬戶

五管理專案及賬戶

六管理加密資訊

八加密練習

九管理security policy

十資源訪問控制綜合實驗