一 官网参考文档
Docker侧的文档
Kubernetes侧的文档
二 Seccomp
secccomp深入了解
内核文档学习
对于'业务安全等级要求较高'的应用场景,我们需要限制'应用容器的内核能力',可以配合'Seccomp'/AppArmor/SELinux等'策略工具'达到限制'容器运行时刻capabilities'的目的
(1)基本概念
wiki
seccomp 其实是 'secure computing mode' 的缩写,是 Linux 内核中的一个安全计算工具。seccomp 允许进程单向转换为'安全状态',在此状态下的进程,除了 'exit(),sigreturn(),read() 和 write()' '已打开的文件描述符外'等系统调用外,'不允许执行'其他任何系统调用
如果'该进程'尝试进行'其他的系统调用',则内核会使用 'SIGKILL 或 SIGSYS' 终止该进程,从这个意义上看,它'并没有'虚拟化系统资源,而是'完全'将其进行了'隔离'
通俗点来说,seccomp 的作用相当于是充当了'系统调用(syscall)的防火墙',它利用 'BPF 规则'来过滤系统调用,并控制'如何处理'它们
更通俗的理解
它允许对'系统调用'进行'筛选',这样我们就能够为'应用程序-->进程'定义其'need-->需要的系统调用',并'deny-->拒绝'其它一切'不必要'的调用行为
BPF简介
不错的科普文章
目的: 限制'容器内'可用的'操作-->operation',seccomp()系统调用在'调用进程'seccomp状态下运行,使用此功能限制'容器内-->应用程序'的访问权限
沙盒理解
(2)查看内核是否支持
grep CONFIG_SECCOMP= /boot/config-`uname -r`
详细操作系统版本支持的情况
(3)传递给容器的配置文件
SCMP_ACT_ERRNO: default action, 'Permission Denied'
SCMP_ACT_ALLOW: '允许'
明确指定策略覆盖默认
docker run --rm \
-it \
--security-opt 'seccomp=/path/to/seccomp/profile.json' \
hello-world
备注: 必须是一个'json格式'的文件
(4)小扩展
(5)默认禁止的功能
思考: 'seccomp'和'capailities'的区别?
个人理解: 好多功能是'一致'的
+++++++++++++++++++'分割线'+++++++++++++++++++
s说明: 直接'机器翻译'的并不准确,核心是理解'功能',大致有一个'全局性的'理解
'也门' -->'be gated by' -->'等价的cap方式替代'
(6)需求:运行时不使用默认的seccomp配置文件
传递'unconfined'运行'没有默认'seccomp配置文件的容器
docker run --rm -it '--security-opt seccomp=unconfined' debian:jessie unshare --map-root-user --user sh -c whoami
三 Seccomp在k8s上的应用
(1)总的学习目标
(2)帮助文档查看
说明的是: 'v1.19 或更新-->update'版本(GA)和 'v1.19之前-->old'版本(alpha)版本关于seccomp使用方式是'有差异'的
在1.19版中,'Seccomp 功能 GA',将新的'seccompProfile字段'添加到pod和容器的securityContext对象中
将'unconfined传入'docker run的security-opt seccomp选项,'(forbidden)禁用默认(default)'的seccomp profile
备注1: '/var/lib/kubelet/seccomp/' 目录'默认没有创建',如果要使用需要'手动创建'
备注2: 和'static pod'不一样,在kubelet起动后,不会'主动扫描',只有在'kubelt启动时候'加载
(3)annoation注解的说明
说明: 1.19之前以'注解'的方式运行
(4) kubelet加载节点上seccomp 配置文件,在Pod中使用
参考内容
说明: 以下实验都基于'1.19.3'版本做测试
+++'分割线'+++
mkdir -p /var/lib/kubelet/seccomp/profiles
'修改之后重启' --> '从实验效果上来看实际不需要重启'
systemctl restart kubelet.service
备注: 'ps -ef | grep kubelet | grep *seccomp*'发现kubelet的'启动参数'并没有这个配置
测试模板文件
'audit.json'模板文件
{
"defaultAction": "SCMP_ACT_LOG"
}
其他参考
apiVersion: v1
kind: Pod
metadata:
name: audit-pod
labels:
app: audit-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/audit.json --> '相对kubelet 启动参数--seccomp-profile-root的路径' --> '这里是/var/lib/kubelet/seccomp/'
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false
相关报错
备注:1.19之后和1.19之前的方式按照官网均报错,达不到预期的实验效果,目前不知道原因,后续再补充
(5)使用导致违规的 Seccomp 配置文件创建 Pod
需求: '不允许任何'系统调用的配置文件'应用于 Pod'
'violation.json' --> '只要进行系统调用就出错'
{
"defaultAction": "SCMP_ACT_ERRNO"
}
模板文件
apiVersion: v1
kind: Pod
metadata:
name: violation-pod
labels:
app: violation-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/violation.json
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false
分析原因
(6)使用设置仅允许需要的系统调用的配置文件来创建 Pod
cat /var/lib/kubelet/kubeadm-flags.env --> '添加kubelet的启动参数'
备注: 由于是'alpha的特性',所以需要自己在'kubelet侧'开启该参数--> '上面我们已经'
--seccomp-profile-root=/var/lib/kubelet/seccomp
注意: '当pod调度到哪个节点上,就使用该节点上的seccomp配置文件,而不是加载执行apply所对用的文件中'
备注: 修改启动参数之后最好'restart'下kubelet服务
模板文件
apiVersion: v1
kind: Pod
metadata:
name: fine-pod
labels:
app: fine-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/fine-grained.json
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false
备注: '1.19.3'
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"accept4",
"epoll_wait",
"pselect6",
"futex",
"madvise",
"epoll_ctl",
"getsockname",
"setsockopt",
"vfork",
"mmap",
"read",
"write",
"close",
"arch_prctl",
"sched_getaffinity",
"munmap",
"brk",
"rt_sigaction",
"rt_sigprocmask",
"sigaltstack",
"gettid",
"clone",
"bind",
"socket",
"openat",
"readlinkat",
"exit_group",
"epoll_create1",
"listen",
"rt_sigreturn",
"sched_yield",
"clock_gettime",
"connect",
"dup2",
"epoll_pwait",
"execve",
"exit",
"fcntl",
"getpid",
"getuid",
"ioctl",
"mprotect",
"nanosleep",
"open",
"poll",
"recvfrom",
"sendto",
"set_tid_address",
"setitimer",
"writev"
],
"action": "SCMP_ACT_ALLOW"
}
]
}
seccomp概要
(7)使用容器运行时默认的 Seccomp 配置文件创建 Pod
了解: '默认的 seccomp' 配置文件应该为'大多数工作负载'提供足够的权限
模板文件
apiVersion: v1
kind: Pod
metadata:
name: audit-pod
labels:
app: audit-pod
spec:
securityContext:
seccompProfile:
type: RuntimeDefault '注意:与第一个demo的区别就在这个地方的书写上'
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false
四 有效动作值的分析
在seccomp profile规则中,可定义以下'6种'行为对'进程的系统调用'行为'做出响应'
其他参考
五 有demo参考
参考1
参考2