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 控制访问
通过自助服务网络控制台
按平台证书

通过 OAuth 控制访问

在此方法中，对 API 控制访问的身份验证进行存档，获取安全令牌以通过 OAuth 服务器进行身份验证，该服务器内置于 OpenShift 主机中。作为管理员，您有权修改 OAuth 服务器配置的配置。

有关 OAuth 服务器配置的更多详细信息，请参阅本教程的第 5 章。

通过自助服务 Web 控制台

此 Web 控制台安全功能内置于 OpenShift Web 控制台中。该控制台可确保所有一起工作的团队在未经身份验证的情况下无法访问其他环境。OpenShift 中的多 Telnet 主控具有以下安全功能 -

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 中主要有四个部分来控制对卷的访问。

补充组
FS集团
以用户身份运行
seLinux选项

补充组 - 补充组是常规 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

FS集团

fsGroup 代表文件系统组，用于添加容器补充组。补充组ID用于共享存储，fsGroup用于块存储。

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

以用户身份运行

runAsUser 使用用户 ID 进行通信。这用于在 pod 定义中定义容器镜像。如果需要，可以在所有容器中使用单个 ID 用户。

运行容器时，定义的 ID 与导出上的所有者 ID 相匹配。如果指定的 ID 是在外部定义的，那么它对于 pod 中的所有容器来说将成为全局的。如果它是用特定的 pod 定义的，那么它就变得特定于单个容器。

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