qtreewidget 获取根节点_openshift 调试RHCOS节点的实现过程分析

Openshift 4版本后容器操作系统不再使用RHEL，而是使用rhcos，由于RHCOS接触的人较少，对其实现原理存在盲区，同时也会考虑其安全性。在我之前分享的RHCOS实现原理中，已经分析了RHCOS的关键技术，如何保证系统安全，其中有一条是不建议管理员直接通过ssh的方式登录到RHCOS中对文件系统进行操作，这样会带来安全隐患，主要是只管理员的操作将缺少审计动作，同时openshift也会对用户手动更改的部分缺统计，导致对配置的无感知，红帽的官方建议方案是通过openshift debug 模式进入节点，对节点调试。此动作主要是对节点进行调试类的操作，而并非更改RHCOS的核心配置文件，如果要更改RHCOS核心配置文件，我们建议使用MachineConfigOperator来操作目标节点。那么我们如何通过openshiftdebug模式进入目标节点呢？这种模式的实现机制是什么？其机制是否安全可靠？接下来我们一一分析。

1.   如何登录openshift的master或node节点

Openshift登录master或者node节点的方式有两种：

1. ssh core@xxxxx 直接ssh到目标节点上

2. oc debug node/xxxxx(nodename)，通过oc debug命令，指定节点名称进行调试。

通常情况下，我们建议使用第二种方式。

2.   debug方式实现原理

当我们在openshift中执行oc debug node/xxxx 命令后，我们就等登录到要debug的节点中。其效果类似于ssh方式直接登陆。基本原理，概括就是openshift在要调试的节点上启动一个debug pod，这个debug pod的权限很高，同时将调试节点的根文件系统通过hostPath的方式挂载到pod的/host目录下。

这时候可能会有同学问到，在openshift的节点上启动pod，就能获取到节点的全部操作权限，这样是不是很危险。既然是创建pod，那这种pod和我们正常使用集群的时候创建的pod有什么差别，如果openshift普通用户在使用集群时，也自行创建了这样的pod那岂不是很危险。

其实有同学提到这样的问题也不奇怪，主要是对openshift debug的实现机制不了解，一旦了解了原理，这样的问题就自己解答了。接下来我们看下openshift的debug模式实现原理。我们可以通过 oc debug node/xxxx –loglevel=15来看起启动过程。整个启动过程如下所示：

1. 执行Debug.go文件开始启动调试过程

2. Loader.go获取openshift管理员的证书配置信息/root/.kube/config

3. Cached_discovery.go获取openshift运行的各种缓存信息

4. 使用/root/.kube/config中的管理员证书去curl要debug节点的openshift节点API：https://xxxxx:6443/api/v1/nodes/xxxxx(nodename)

5. 通过API获取了要debug节点的主机所有信息，包括：主机名，CPU架构，内存分布，运行了多少容器，服务器的创建时间，是否有内存或者资源使用压力，操作系统的版本号，节点被占用的端口，节点的IP地址，节点上可用的容器镜像名字等

6. Request.go通过已配置pod的spec文件在openshift的default namespace下创建pod。容器spec文件内容类似如下：

   

   由配置文件可以看出来，创建容器的过程使用support-tools镜像来启动这个pod，启动后将宿主机的根文件系统目录通过hostPath方式挂载到容器的pod中的/host目录下。因为涉及到访问宿主机的根文件系统，因此运行容器需要特权级操作权限和root身份。启动镜像后直接运行/bin/sh命令进入shell中。

7. Curl刚刚创建的pod的openshift API，查看pod是否启动正常。

8. 打印提示信息：启动pod/xxxx; 如果要使用登录到调试宿主机的跟文件系统执行如下命令：chroot /host

9. 调用pod API登录pod中，即进入pod中的/bin/sh脚本启动的shell命令行。命令行提示符将发生变化：将是以“sh-4.x:”为提示符.

10. 此时已经成功登录到debug pod中，如果要操作RHCOS的文件系统，执行 chroot /host即可。以后的工作即正常操作文件系统一样。

11. 当调试结束后，我们执行exit退出debug pod时。Request.go将通过curl命令给Openshift API发送delete请求。将debug POD删除。

    总结：

这种debug pod和我们正常使用集群的时候创建的pod的主要差别，在于debug pod的运行需要用openshift cluster admin管理员权限创建，创建pod的时候要给pod 的scc赋予privileged=true 和 runAsUser=0权限，即root权限启动容器。

创建debug pod的过程已经有openshift集成自动化，无须用户编写配置文件创建特权容器，通常情况下，我们不会创建这样权限的pod。

此pod创建的namespace默认在defaultproject下面。方便查看。

如果openshift普通用户在使用集群时，也自行创建了这样的pod那岂不是很危险。Openshift普通用户无法创建这样的pod，没权限。如果是openshift的cluster admin用户创建这样的pod是可以的，但是已经有了cluster admin的权限，他已经可以直接通过ssh方式登录目标节点了。所以用户要做好对集群管理员的管控，只有指定的人员可以操作。

通过以上分析，openshift的debug模式实现机制非常安全，全部过程由openshift自动化完成。退出后也不会留下任何残留。