注：以下内容基于经验主义，不一定对。
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