原文:https://blog.csdn.net/bloodzero_new/article/details/110328113
Docker Security Capability:
AppArmor: AppArmor(应用程序防护)是一种Linux安全模块,可保护操作系统及其应用程序免受安全威胁;
SELinux: SELinux是一个应用程序安全系统,它提供了一个访问控制系统,大大增强了自由访问控制模型;
Seccomp: Seccomp是一种Linux内核功能,可用于限制容器中可用的操作;
不使用–privileged参数启动容器;
端口开放必须遵循最小权限原则,不暴露未使用的端口;
不在容器中启用SSH服务;
不共享主机的网络命名空间(Namespace),也就是不要使用–net=host参数启动容器;
设置故障容器自动重启策略,也就是使用–restart参数;
容器根文件系统设置为只读;
对容器的出口流量进行安全分析,接入NIDS进行分析;
————————————————
版权声明:本文为CSDN博主「zer.zhang」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/bloodzero_new/article/details/110328113
容器集群的安全性
对于容器集群Kubernete安全较重要的如下:
控制对Kubernetes API的访问:TLS APII、API认证与授权;
控制对Kubernetes Kubelet的访问;
在运行时控制工作负载或用户的功能:
限制集群中的资源使用;
控制容器的运行权限;
防止容器加载不必要的内核模块;
限制网络访问;
限制云元数据API访问;
控制Pod可以访问哪些节点。
保护集群组件:
限制访问etcd;
启用审计日志
限制访问alpha或beta功能;
定期轮换基础架构的凭据;
集成第三方组件之前必须执行审计;
加密静止的密钥;
接收安全更新警报并报告漏洞。
如同上面所说,集群安全已经算是容器安全的另一个主题,所以本文对集群的安全不过多描述(主要是我还没有吃透)。
容器的安全工具
容器在前几年发展迅速,安全问题也得到了相应的重视,业内出现了很多针对容器安全的工具。当然工具不是本篇文章的重点,后续我会更新关于容器安全工具的安装、使用与对比。这部分主要来源于:https://sysdig.com/blog/33-kubernetes-security-tools/
未完待更新。
Appendix
Docker容器最佳安全实践白皮书V1.0
https://share.weiyun.com/e01eklAr
Aliyun Docker and K8s ATT&CK Matrix
其他文章阅读:
10个确保微服务与容器安全的最佳实践:http://dockone.io/article/8207
20种终极工具,为你的Docker搭建安全防火墙:https://mp.weixin.qq.com/s/3IFodzE6K7vr1mHEZdZskA
29 Docker security tools compared:https://sysdig.com/blog/20-docker-security-tools/
33个Kubernetes安全工具:https://blog.fleeto.us/post/33-kubernetes-security-tools/
76%都存在漏洞?!Docker镜像安全扫描应该这样做:https://dbaplus.cn/news-160-2275-1.html
2018 绿盟科技容器安全技术报告:http://www.nsfocus.com.cn/upload/contents/2018/11/20181109100414_79051.pdf
2019年度容器安全现状分析:https://mp.weixin.qq.com/s/jtDlMe5SprpZfIfXryAjzg
DOCKER SECURITY BEST PRACTICES PART 4 – RUNTIME SECURITY:https://anchore.com/blog/docker-security-best-practices-part-4-runtime-security/
Docker Security Guideline:https://docs.docker.com/engine/security/
Docker安全入门与实战(一):https://zhuanlan.zhihu.com/p/43586159
Docker安全入门与实战(二):https://zhuanlan.zhihu.com/p/43671129
Docker安全入门与实战(三):https://zhuanlan.zhihu.com/p/43671511
Docker安全入门与实战(四):https://zhuanlan.zhihu.com/p/43673419
Docker安全自动化扫描工具对比测试:https://blog.csdn.net/wutianxu123/article/details/83216219
Docker容器安全实践:https://www.secrss.com/articles/7016
Docker 容器逃逸案例汇集:https://www.cnblogs.com/xiaozi/p/13423853.html
Securing a Cluster:https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/
国内首个云上容器ATT&CK攻防矩阵发布,阿里云助力企业容器化安全落地:https://developer.aliyun.com/article/765449?spm=a2c6h.13148508.0.0.29cb4f0ejECYcC
全面易用的镜像漏洞检测工具Trivy:https://blog.fleeto.us/post/introducing-trivy/
容器安全风险解决方案(下篇):https://mp.weixin.qq.com/s/NgIT1tX2uTBt3xJ3Jq9ZdA
容器安全学习课程:https://www.katacoda.com/
容器安全在证券行业的最佳实践:https://mp.weixin.qq.com/s/TFlWF7WcC1lT1X244o4VBw
容器静态安全漏洞扫描工具Clair介绍:https://zhuanlan.zhihu.com/p/43547242
探索容器安全性(概述):http://dockone.io/article/5515
如何打造安全的容器云平台:https://blog.qiniu.com/archives/7743
五个Docker监控工具的对比:http://dockone.io/article/397
云原生之容器安全实践:https://tech.meituan.com/2020/03/12/cloud-native-security.html
针对容器的渗透测试方法:https://mp.weixin.qq.com/s/o5fGivwgBMR-w60SXQbSYA
————————————————
版权声明:本文为CSDN博主「zer.zhang」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/bloodzero_new/article/details/110328113
参考文章:保障集群内节点和网络安全(SecurityContext PodSecurityPolicy NetworkPolicy)
链接:https://blog.csdn.net/WuYuChen20/article/details/103683502
2.1 securityContext
阻止容器以root用户运行
如果攻击者获取了访问镜像仓库的权限,并上传一个标签一样的镜像,并以root用户运行。kubernetes的调度器运行该pod实例,kubelet会拉取攻击者的镜像,并运行该镜像中的任何代码。
虽然容器与宿主节点基本上是隔离的,使用root用户运行容器中的进程然然是不好的实践。例如,当宿主节点上的一个目录被挂载到容器中,如果该容器使用了root用户运行,那它就用于该目录的所有权限,如果是非root用户运行,它就只有部分权限。
apiVersion: v1
kind: Pod
metadata:
name: xxx
spec:
containers:
- name: xxx
image: alpine
command: ["/bin/sleep", "9999"]
securityContext:
runAsNonRoot: true
2.2 PodSecurityPolicy
在上面已经介绍了如何在部署一个pod时在一个宿主节点上做任何想做的事情,很明显要有一种机制来限制用户使用其中部分功能,集群管理员可以使用 PodSecurityPolicy资源来限制对以上安全相关的特性的使用。
如果pod spec中任何一个字段向设置该范围以外的值,那该pod将不会被API服务器接收。
注意:PodSecurityPolicy策略对已存在的pod无效,因为PodeSecurityPolicy资源只在创建和升级pod的时候生效
PodSecurityPolicy 资源介绍
PodSecurityPolicy是一种集群资源(无命名空间)的资源,它定义了用户能否在pod中使用各种安全相关的特性。维护PodSecurityPolicy资源中的配置策略的工作由集成在API服务器中的PodSecurityPolicy准入插件来完成。
注意:你的集群不一定开启了PodSecurityPoicy 准入控制插件,需要开启它才行
当向API服务器发送pod资源时,PodSecurityPolicy准入控制插件会将这个pod与已经配置的PodSecurityPolicy进行校验,如果这个pod符合集群中已有的安全策略,它会被存入etcd。如果不符合将会被直接拒绝。这个插件也会根据安全策略中配置的默认值对pod进行修改。
了解PodSecurityPolicy可以做的事情
一个PodSecurityPolicy资源可以定义以下事项:
是否允许pod使用宿主节点的PID、IPC和网络命名空间
pod允许绑定宿主节点端口
容器运行时允许使用用户的ID
是否允许拥有特权模式容器的pod
允许添加哪些内核功能、默认使用哪些内核功能,总是禁用哪些内核功能
允许使用哪些SELinux选项
容器是否允许使用可写入的根文件系统
允许容器在哪些文件系统组下运行
允许pod使用哪些类型的存储卷
查看一个PodSecurityPolicy样例
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: default
spec:
hostPID: false // 禁用宿主节点的PID命名空间
hostIPC: false // 禁用宿主节点的IPC命名空间
hostNetwork: false // 禁用宿主节点的网络命名空间
hostPorts: // 限制容器可以绑定宿主节点的哪些端口
- min: 10000 // 10000-110000 可以绑定
max: 11000
- min: 13000 // 13000-14000 可以绑定
max: 14000
privileged: false // 禁止使用特权模式的容器运行
readOnlyRootFilesystem: true // 容器强制使用只读的根文件系统
runAsUser: // 以supplemental、fsGroup
rule: RunAsAny // 一起允许用户使用任何的用户或用户组运行容器
fsGroup:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
seLinux: // 可以使用SELinux的任何选项
rule: RunAsAny
volumes: // 可以使用任何类型的存储卷
- '*'
runasuser fsGroup 具体策略:
runAsUser:
rule: MustRunAs
range:
- min: 2 // min=max 可以指定一个特定的ID
max: 2
fsGroup:
rule: MustRunAs
range: // 指定了用户组ID在 2-10,20-30(包含临界值) 范围内用户组ID
- min: 2
max: 10
- min: 20
max: 30
supplementalGropus:
rule: MustRunAs
range:
- min: 2
max: 10
- min: 20
max: 30
2.3 NetworkPolicy
上面所讲的安全特性配置都是pod和pod中的容器上。现在来了解一下如何通过限制pod与pod之间通信,来确保pod之间的网络安全。
是否可以进行这些配置取决于集群中使用的网络插件,如果网络插件支持,可以通过NetworkPolicy资源配置网络隔离。
一个NetworkPolicy会应用在匹配它的标签选择器的pod上,指明这些允许访问这些pod的源地址,或这些pod可以访问的目标地址。这些分别由入向(ingress)和出向(egress)规则指定。这两者都可以匹配由标签选择器选出的pod,或者一个namespace中的所有pod,或者通过无类别域间路由CIDR指定的IP地址段。
在一个命名空间中启用网络隔离
apiVersion: network.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector:
// 空的标签选择器会匹配命名空间中所有的pod
pod安全三策略SecurityContext PodSecurityPolicy NetworkPolicy 参考文章:
https://blog.csdn.net/WuYuChen20/article/details/103683502
(本文章是学习《kubernetes in action》 一书时做的笔记,由于本人是刚学习k8s,且自学方式就是把它敲一遍,然后加一些自己的理解。所以会发现很多内容是跟书中内容一模一样,如果本文是对本书的侵权,敬请谅解,告知后会删除。如果引用或转载,请注明出处——谢谢)