OpenShift - 安全性

OpenShift 安全性主要由兩個處理安全約束的元件組合而成。

安全上下文約束 (SCC)
服務賬號

安全上下文約束 (SCC)

它主要用於 Pod 限制，這意味著它定義了 Pod 的限制，例如它可以執行哪些操作以及它可以在叢集中訪問哪些內容。

OpenShift 提供了一組預定義的 SCC，管理員可以對其進行使用、修改和擴充套件。

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

如果要使用任何預定義的 SCC，只需將使用者或組新增到 SCC 組即可。

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

服務賬號

服務賬號主要用於控制對 OpenShift 主 API 的訪問，當從任何主節點或節點機器發出命令或請求時，都會呼叫該 API。

任何時候，如果應用程式或程序需要受限 SCC 未授予的功能，則必須建立一個特定的服務賬號並將該賬號新增到相應的 SCC。但是，如果 SCC 不符合您的要求，最好建立一個滿足您特定需求的新 SCC，而不是使用最合適的 SCC。最後，將其設定為部署配置。

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

容器安全

在 OpenShift 中，容器安全基於容器平臺的安全性以及容器執行位置的概念。當我們談論容器安全以及需要處理的內容時，有多個方面需要考慮。

映象來源 - 一個安全的標籤系統，準確無誤地識別生產環境中執行的容器的來源。

安全掃描 - 映象掃描程式會自動檢查所有映象是否存在已知的漏洞。

審計 - 定期對生產環境進行審計，以確保所有容器都基於最新的容器，並且主機和容器都已安全配置。

隔離和最小許可權 - 容器以有效執行所需的最低資源和許可權執行。它們無法過度干擾主機或其他容器。

執行時威脅檢測 - 一種能夠檢測針對執行時容器化應用程式的活動威脅並自動響應它的功能。

訪問控制 - 使用 Linux 安全模組（例如 AppArmor 或 SELinux）來強制執行訪問控制。

有幾種關鍵方法可以實現容器安全。

透過 OAuth 控制訪問
透過自助服務 Web 控制檯
透過平臺證書

透過 OAuth 控制訪問

在這種方法中，透過 OAuth 伺服器（內置於 OpenShift 主機中）獲取安全令牌進行身份驗證來實現對 API 控制訪問的身份驗證。作為管理員，您可以修改 OAuth 伺服器配置。

有關 OAuth 伺服器配置的更多詳細資訊，請參閱本教程的第 5 章。

透過自助服務 Web 控制檯

此 Web 控制檯安全功能內置於 OpenShift Web 控制檯中。此控制檯確保所有協同工作的團隊在未經身份驗證的情況下無法訪問其他環境。OpenShift 中的多終端主機具有以下安全功能：

已啟用 TCL 層
使用 x.509 證書進行身份驗證
保護主機上的 etcd 配置

透過平臺證書

在這種方法中，每個主機的證書都是透過 Ansible 在安裝過程中配置的。因為它透過 Rest API 使用 HTTPS 通訊協議，所以我們需要 TCL 安全連線到不同的元件和物件。這些是預定義的證書，但是，也可以在主叢集上安裝自定義證書以進行訪問。在主機的初始設定期間，可以透過使用openshift_master_overwrite_named_certificates引數覆蓋現有證書來配置自定義證書。

示例

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

有關如何生成自定義證書的更多詳細資訊，請訪問以下連結：

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

網路安全

在 OpenShift 中，軟體定義網路 (SDN) 用於通訊。每個 Pod 在叢集中使用網路名稱空間，其中每個 Pod 獲取自己的 IP 和一系列埠以在其上獲取網路流量。透過這種方法，可以隔離 Pod，因此它無法與其他專案中的 Pod 通訊。

隔離專案

叢集管理員可以使用 CLI 中的以下oadm 命令來執行此操作。

$ oadm pod-network isolate-projects <project name 1> <project name 2>

這意味著上面定義的專案無法與叢集中的其他專案通訊。

卷安全

卷安全明確意味著保護 OpenShift 叢集中專案的 PV 和 PVC。主要有四個部分來控制對 OpenShift 中卷的訪問。

補充組
fsGroup
runAsUser
seLinuxOptions

補充組 - 補充組是常規的 Linux 組。當程序在系統中執行時，它使用使用者 ID 和組 ID 執行。這些組用於控制對共享儲存的訪問。

使用以下命令檢查 NFS 掛載。

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

使用以下命令檢查掛載伺服器上的 NFS 詳細資訊。

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

/opt/nfs/匯出可由 UID 454265 和組 2325 訪問。

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup 代表檔案系統組，用於新增容器補充組。補充組 ID 用於共享儲存，fsGroup 用於塊儲存。

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser 使用使用者 ID 進行通訊。這用於在 Pod 定義中定義容器映象。如果需要，可以在所有容器中使用單個 ID 使用者。

執行容器時，將定義的 ID 與匯出的所有者 ID 匹配。如果指定的 ID 在外部定義，則它對 Pod 中的所有容器都全域性可見。如果它與特定 Pod 一起定義，則它對單個容器特定。

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265

列印頁面