Kubernetes security context capability

注：以下内容基于经验主义，不一定对。

---

Linux capability

Linux 中，root 作为特权用户，具有执行所有应用的能力。而普通用户只能执行普通应用。如果普通用户需要执行特权应用，需要进行 SUID 提权，使得普通用户在执行具有 SUID 的应用时短暂获得特权用户的身份。

这一设计容易出现漏洞，漏洞在于 SUID 程序上，普通用户在执行 SUID 程序是以特权用户执行的。利用这一功能，可以使普通用户提权。如 SUID 程序中，新开一个 shell，该 shell 可以 root 身份运行的。详细了解可参考 原理+代码实战：SUID提权渗透

因此，需要给普通用户更细粒度的权限，使得普通用户仅能获得给定的能力而不能越权。Linux 的 capability 定义了一系列细粒度的能力供普通用户使用，从而保证安全性。

工具 setcap 和 getcap 可以给应用加 cap 和获取应用的 cap。setcap 加的应用，在移动或操作时，其 cap 会丢失。

给应用加上指定运行应用的 cap 时，普通用户即可运行特权用户才能执行的应用。

Linux 中，setcap 加的是静态的应用属性，真正执行还是要看系统是否具有执行应用的 cap。

Kubernetes capability

Linux 的 capability 理清了，就要上到容器中看。

容器中，应用在 dockerfile 内定义好需要的 cap，这是静态属性。在起容器时，静态的 docker image 将映射为动态的文件系统（容器）。

此时，容器中的应用是具有 cap。也即是，容器作为沙箱需要有运行容器应用的 cap。否则，应用执行会失败。

简单记录如下：

# dockerfile
setcap cap_dac_override,cap_sys_admin,cap_net_admin+ep /usr/sbin/tc

# 容器中的应用
$ kubectl exec -it <pod_id> -c <container_id> /bin/bash
bash-5.1$ getcap /usr/sbin/tc
/usr/sbin/tc cap_dac_override,cap_net_admin,cap_sys_admin=ep

那么，运行应用的 cap 在哪里定义呢？

理解这一点，要从 SCC（security context constraints） 讲起。

SCC 里定义了一系列 security 属性，绑定其上的 serviceaccount 受 SCC 约束。其中，allowPrivilegeEscalation, allowPrivilegedContainer 和 allowedCapabilities 属性和 capability 相关，需要重点关注下。

容器内运行“特权”应用。有三种方式：

• 用户可以以 root 身份运行。
• 普通用户通过权限提升 allowPrivilegeEscalation 为 root 运行。
• 指定容器中 cap，使普通用户具有执行应用的能力。

容器内所需要的 cap 在 container 域定义，container 域定义的 cap 需要在 SCC 中 allow 的，并且要 disable container 中用户的特权提升。

查看 container 中容器的 cap 如下：

bash-5.1$ capsh --print
Current: cap_dac_override,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_admin,cap_sys_nice=i
Bounding set =cap_dac_override,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_admin,cap_sys_nice
Ambient set =
Current IAB: !cap_chown,cap_dac_override,!cap_dac_read_search,!cap_fowner,!cap_fsetid,!cap_kill,!cap_setgid,!cap_setuid,!cap_setpcap,!cap_linux_immutable,cap_net_bind_service,!cap_net_broadcast,cap_net_admin,cap_net_raw,!cap_ipc_lock,!cap_ipc_owner,!cap_sys_module,!cap_sys_rawio,!cap_sys_chroot,!cap_sys_ptrace,!cap_sys_pacct,cap_sys_admin,!cap_sys_boot,cap_sys_nice,!cap_sys_resource,!cap_sys_time,!cap_sys_tty_config,!cap_mknod,!cap_lease,!cap_audit_write,!cap_audit_control,!cap_setfcap,!cap_mac_override,!cap_mac_admin,!cap_syslog,!cap_wake_alarm,!cap_block_suspend,!cap_audit_read,!cap_perfmon,!cap_bpf,!cap_checkpoint_restore

查看进程所具有的 cap:

bash-5.1$ cat /proc/$$/status | grep Cap
CapInh: 0000000000a03402
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000000000a03402
CapAmb: 0000000000000000
bash-5.1$ capsh --decode=0000000000a03402
0x0000000000a03402=cap_dac_override,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_admin,cap_sys_nice

可以看到进程绑定到环境拥有的 cap，这里要注意的是如果二进制文件定义的 cap 不在容器 cap 内，则启动二进制文件会失败。

参考

• Linux Capabilities 简介
• security context constraints
• Linux capability详解
• Kubernetes SecurityContext Capabilities Explained
• 对 Capabilities (libcap, getcap, setcap) 的基本了解
• 原理+代码实战：SUID提权渗透
• Linux的capability深入分析
• Kubernetes security context