乐趣区

关于linux:如何通过-kubectl-进入-node-shell

概述

假如这样一个场景:

生产环境中,Node 都须要通过堡垒机登录,然而 kubectl 是能够间接在个人电脑上登录的。

这种场景下,我想要通过 kubectl 登录到 K8S 集群里的 Node,能够实现吗?

能够的!
实质上是利用容器(runC)的弱隔离(共享内核,Cgruop 等实现过程隔离)实现的权限逃逸。

如果贵司应用的一些商业容器平台(如:openshift,rancher)等,可能默认装置时就会通过 PSP scc 或 policy 等事后屏蔽掉这层隐患。
然而如果是原生的 Kubernetes,往往上面的方法是可行的。

原理概述

先说实质,实质上就是:

容器(runC)是弱隔离

  • 对于虚拟机来说,虚拟机是通过内核(kernel)级别的隔离,不同的虚拟机有不同的内核,所以安全性要高很多,从虚拟机逃逸到其所在的物理机上是十分艰难的。
  • 然而,容器(runC)是弱隔离,一台机器上的所有容器都共享同一个内核,他们之所以默认相互看不见,是通过 Cgroup、net namespace 等实现的过程级别的隔离。

那么,退出你没有对容器的权限做进一步的限度,我是能够通过运行一个特权容器,间接进入到其所在的 node 上的。

具体步骤

实用于 K8S 1.25 之前的版本。

步骤很简略,就是创立上文说的这么一个 特权 容器,通过 nsenter command 进入 node shell。示例 yaml 如下:

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nsenter-v0l86q
  name: nsenter-v0l86q
  namespace: default
spec:
  containers:
  - command:
    - nsenter
    - --target
    - "1"
    - --mount
    - --uts
    - --ipc
    - --net
    - --pid
    - --
    - bash
    - -l
    image: docker.io/library/alpine
    imagePullPolicy: Always
    name: nsenter
    securityContext:
      privileged: true
    stdin: true
    stdinOnce: true
    tty: true
  hostNetwork: true
  hostPID: true
  restartPolicy: Never
  tolerations:
  - key: CriticalAddonsOnly
    operator: Exists
  - effect: NoExecute
    operator: Exists

间接 kubectl apply -f node-shell.yaml 即可进入 node shell。

下面的 yaml,要害有这么几点:

进入 node shell 的命令:nsenter --target 1 --mount --uts --ipc --net --pid -- bash -l,在 Linux 零碎里,nsenter 是一个命令行工具,用于进入到另一个 namespace。譬如,nsenter -n -t 1 bash 就是进入到 pid 为 1 的过程所在的网络 namespace 里。

以及进入 node shell 的权限:

  • hostPID: true 共享 host 的 pid
  • hostNetwork: true 共享 host 的网络
  • privileged: true: PSP 权限策略是 privileged, 即齐全无限度。

进入 node shell 的 pod 后,成果如下:

实用工具 – 进入 node shell 更不便

这里举荐 2 个工具,能够更不便地进入 node shell。

krew node-shell

能够通过 kubectl 插件管理工具 krew 装置 node-shell.

如下:

# 装置工具
kubectl krew install node-shell
# 进入 node shell
Kubectl node-shell <node-name>

Lens

Kubernetes 图形化管理工具 – Lens 也有相干性能。

具体应用办法如下:

总结

上文介绍了通过 kubectl 命令以 root 权限进入 node shell 的办法,非常简单,实际上在大多数的原生 Kubernetes 上都失效。

这个命令实际上是肯定水平上利用了平安上的未加固配置。

这里最初还是倡议大家除了对 OS 进行平安加固,对 Kubernetes 也要依照平安最佳实际进行平安加固。(典型的就是起码 PSP 等 policy 不要设置为 privileged, 而是设置为 BaselineRestricted

注意安全!🚧🚧🚧

EOF

本文由博客一文多发平台 OpenWrite 公布!

退出移动版