OpenShift – 安全性
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 中,容器的安全性基于容器平台的安全性以及容器在哪里运行的概念。当我们谈论容器安全性以及需要注意的事项时,会涉及很多方面。
Image Provenance – 一个安全的标签系统到位,可以准确无误地识别在生产环境中运行的容器的来源。
安全扫描– 图像扫描仪会自动检查所有图像是否存在已知漏洞。
审核– 定期审核生产环境,以确保所有容器都基于最新的容器,并且主机和容器均已安全配置。
隔离和最低权限– 容器以有效运行所需的最少资源和权限运行。他们不能过度干扰主机或其他容器。
运行时威胁检测– 一种在运行时检测针对容器化应用程序的主动威胁并自动响应的功能。
访问控制– Linux 安全模块,例如 AppArmor 或 SELinux,用于实施访问控制。
归档容器安全的关键方法很少。
- 通过 oAuth 控制访问
- 通过自助服务 Web 控制台
- 按平台证书
通过 OAuth 控制访问
在这种方法中,API 控制访问的身份验证被存档,通过 OAuth 服务器获取用于身份验证的安全令牌,OAuth 服务器内置于 OpenShift 主机中。作为管理员,您可以修改 OAuth 服务器配置的配置。
有关 OAuth 服务器配置的更多详细信息,请参阅本教程的第 5 章。
通过自助服务 Web 控制台
此 Web 控制台安全功能内置于 OpenShift Web 控制台中。此控制台可确保所有协同工作的团队在未经身份验证的情况下无法访问其他环境。OpenShift 中的多 telnet master 具有以下安全功能 –
- TCL层已启用
- 使用 x.509 证书进行身份验证
- 保护主机上的 etcd 配置
按平台证书
在这种方法中,每个主机的证书都是在安装过程中通过 Ansible 配置的。由于它通过 Rest API 使用 HTTPS 通信协议,我们需要 TCL 安全连接到不同的组件和对象。这些是预定义的证书,但是,您甚至可以在主集群上安装自定义证书以供访问。在 master 的初始设置期间,可以通过使用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 中主要有四个部分来控制对卷的访问。
- 补充组
- 组
- 以用户身份运行
- 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
组
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