@云原生之容器安全实践( 六 )

内核后话
最后，分享一下笔者眼中较为理想中的状况。当然，我们得根据实际情况“因地制宜” ，在不同阶段做出不同的取舍与选择。

将内核团队看成社区，我们向他们提交代码，如同Linux内核社区有RFC(Request for Comment)、Patch Review等，无争议后合并进公司内核。
先挑选实用的安全特性且代码量少的，去移植，去实现，并落地。代码量少意味着对内核代码改动少，出问题的可能性越小，稳定性越高，性能损耗越低。
一年完成几个安全特性，不需要多， 1～2个即可，对于内核态的加固，慎重慎重再慎重，譬如国外G家公司数据中心的内核发版前大概需要6～7个月时间做性能、稳定性测试。
需要做到加固某个安全特性后，使用0day或Nday去验证防御效果，且基于该内核跑业务是稳定，性能损耗在可接受范围之内或者可控。每个安全特性需要技术评审。为保障代码质量的问题，找实际的高吞吐以及高并发低延迟的服务器小范围灰度测试，无争议后，再推送给内核团队。
最后，我们还可以通过将安全特性的代码直接提交给Linux内核社区，如果代码有不足的地方也可以和社区协同解决，合并进Linux内核主线代码，从而侧面推动落地。

作者简介
Pray3r ，负责美团内部操作系统安全、云原生安全、重大高危漏洞应急响应，长期专注于Linux内核安全及开源软件安全。
参考文献
https://github.com/cncf/foundation/blob/master/charter.mdhttps://mp.weixin.qq.com/s/5pVKNI6_hzhaXTOUxU9bTAhttps://dirtycow.ninja/https://github.com/opencontainers/runchttps://github.com/containerd/containerdhttps://github.com/docker/containerd/blob/master/design/architecture.mdhttps://www.openwall.com/lists/oss-security/2019/02/11/2https://github.com/Frichetten/CVE-2019-5736-PoChttps://github.com/dockerhttps://www.cisecurity.org/benchmark/docker/https://gvisor.dev/docs/https://schd.ws/hosted_files/kccnceu18/47/Container%20Isolation%20at%20Scale.pdfhttps://github.com/kata-containers/documentation/https://www.kernel.org/https://www.redhat.com/https://lwn.net/Articles/531114/https://lwn.net/Articles/604609/https://github.com/Pray3r/container-securityhttps://www.slideshare.net/jpetazzo/anatomy-of-a-container-namespaces-cgroups-some-filesystem-magic-linuxcon招聘信息
美团-信息安全部招聘：云原生安全工程师/专家
岗位职责：