OpenShift - 安全

OpenShift 安全主要是两个组件的组合,主要处理安全约束。

  • 安全上下文约束 (SCC)
  • 服务帐户

安全上下文约束 (SCC)

它主要用于 pod 限制,这意味着它定义了 pod 的限制,例如它可以执行哪些操作以及它可以在集群中访问哪些内容。

OpenShift 提供了一组预定义的 SCC,管理员可以使用、修改和扩展这些 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 控制访问

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

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

通过自助服务 Web 控制台

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

  • TCL layer is enabled
  • Uses x.509 certificate for authentication
  • Secures the etcd configuration on the master machine

通过平台证书

在此方法中,每个主机的证书在安装期间通过 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-networkisolate-projects <项目名称 1> <项目名称 2>

这意味着上面定义的项目无法与集群中的其他项目通信。

卷安全

卷安全显然意味着保护 OpenShift 集群中项目的 PV 和 PVC。主要有四个部分来控制对 OpenShift 中卷的访问。

  • Supplemental Groups
  • 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)

UID 454265 和组 2325 可以访问 /opt/nfs/ 导出。

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 中所有容器的全局 ID。如果它与特定 pod 一起定义,则它将成为单个容器的特定 ID。

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