kubernets之节点和网络的安全保障策略
一 在pod中使用宿主节点的命名空间
1.1 在pod中使用宿主的网络命名空间
[root@node01 Chapter13]# cat pod-with-host-network.yml
apiVersion: v1
kind: Pod
metadata:
name: pod-with-host-network
spec:
hostNetwork: true
containers:
- name: main
image: alpine
command: ["/bin/sleep", "999999"]
- 如果需要pod使用节点的网络命名空间的话,仅仅需要在pod的mainifest的定义里面添加 hostNetwork: true
1.2 绑定到宿主机的端口上面而不是宿主机的网络的命名空间
[root@node01 Chapter13]# cat kubia-hostport.yml
apiVersion: v1
kind: Pod
metadata:
name: kubia-hostport
spec:
containers:
- name: kubia
image: luksa/kubia
ports:
- containerPort: 8080
hostPort: 9000
- 在pod的容器spec.containers.ports.hostPort:9000就可以将容器使用主机的端口来访问
- 这个与将pod添加到服务有所不同,这个只有被调度到的主机可以访问
1.3 使用宿主机的PID以及PIC的命名空间
apiVersion: v1
kind: Pod
metadata:
name: pod-with-host-pid-and-ipc
spec:
hostPID: true
hostIPC: true
containers:
- name: main
image: alpine
command: ["/bin/sleep", "999999"]
二 配置容器级别的安全上下文
2.1 使用指定用户运行容器
apiVersion: v1
kind: Pod
metadata:
name: pod-as-user-guest
spec:
containers:
- name: mian
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
runAsUser: 405
2.2 阻止容器以root用户运行
apiVersion: v1
kind: Pod
metadata:
name: pod-no-root
spec:
containers:
- name: mian
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
runAsNonRoot: true
2.3 使用特权模式运行pod
apiVersion: v1
kind: Pod
metadata:
name: pod-root
spec:
containers:
- name: mian
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
privileged: true
- 添加之后,pod就会有可以改变宿主机的权限,例如设置iptables规则等
2.4 在容器内部单独添加内核功能而不是将最大的权限全部交给pod
apiVersion: v1
kind: Pod
metadata:
name: pod-with-some
spec:
containers:
- name: mian
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
capabilities:
add:
- SYS_TIME
2.5 关闭容器中某些操作内核的权限
apiVersion: v1
kind: Pod
metadata:
name: pod-with-drop-some
spec:
containers:
- name: mian
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
capabilities:
drop:
- SYS_TIME
2.6 禁止容器里面的进程写入容器的文件系统,但是允许其写入挂载的卷里面
apiVersion: v1
kind: Pod
metadata:
name: pod-with-readonly-filesystem
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep","999999"]
securityContext:
readOnlyRootFilesystem: true
volumeMounts:
- name: my-volume
mountPath: /volume
readOnly: false
volumes:
- name: my-volume
emptyDir:
三 限制pod使用安全相关的特性
3.1 PodSecurityPolicy资源介绍
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: default
spec:
hostIPC: false
hostPID: false
hostNetwork: false
hostPorts:
- min: 10000
max: 11000
- min: 13000
max: 14000
privileged: false
readOnlyRootFilesystem: true
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
seLinux:
rule: RunAsAny
volumes:
- '*'
3.2 如果要对容器内的应用运行时候指定用户名以及用户组需要配置runasuser,fsgroup,supplementalGroup等的属性,其一个示范配置如下
runAsUser:
rule: MustRunAs
ranges:
- min: 2
max: 2
fsGroup:
rule: MustRunAs
ranges:
- min: 2
max: 10
- min:20
max: 30
supplementGroups:
rule: MustRunAs
ranges:
- min: 2
max: 10
- min: 20
max: 30
- 注意一点的是PodsecurityPolicy里面定义的规则不针对集群里面已经存在的pod
- 对于用户推送的pod,如果与策略里面相悖,则无法创建成功,如果创建容器的时候并未对其用户指定,则会使用集群策略里面的条例
- 对于runAsUser而言可以指定mustRunAsNonRoot,如此设置之后必须指定一个非root的用户来运行pod
3.3 更细粒度的内核功能权限划分,被允许添加,默认添加,以及禁止添加的内核功能
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
spec:
allowedCapabilities:
- SYS_TIME
defaultAddCapabilities:
- CHOWN
requiredDropCapabilities:
- SYS_ADMIN
- SYS_MODULE
- allowedcapabilities的作用是,允许pod访问docker系统里面的功能
- defaultAddCapabilities作用是,默认添加到pod里面的对系统权限访问功能
- requiredDropCapabilities作用是不允许添加到pod的系统功能,一旦添加,将无法成功的创建pod
3.4 限制pod可以使用存储卷的类型
kind: PodSecurityPolicy
spec:
volumes:
- emptyDir
- configMap
- secret
- downwardAPI
- persistentVolumeClaim
- 指定了pod可以使用的存储卷类型
3.5 对不同的用户或者用户组分配不同的PodSecurityPolicy
使用的方法是利用集群角色以及集群角色绑定到不同用户或者用户组,使得,不同用户或者不同用户组里面的用户拥有不同的PodSecurityPolicy的规则,前面提到过,PodSeurityPolicy属于集群资源,但是不可能某个Policy可以对集群里面的所有的pod都能有效果,于是我们可以试图用一个之前已经学过的资源来让PodSecurityPolicy来关联不同的用户以及用户组来让不同的用户组拥有不同的权限
3.5.1 创建1个psp
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: privileged
spec:
privileged: true
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
seLinux:
rule: RunAsAny
volumes:
- '*'
3.5.2 为它创建一个集群角色
k create clusterrole privileged --verb=use --resource=podsecuritypolicies --resource-name=privileged
3.5.3 创建一个集群角色绑定
k create clusterrolebinding psp-bob --clusterrole=privileged --user=wxm
3.5.4 创建这个用户
k config set-credentials wxm --username=wxm --password=password
3.5.5 使用这个用户来创建带有特权的pod
k --user wxm create -f pod-privileged.yml
四 隔离pod网络
4.1 在一个命名空间中启用网络隔离
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metddata:
name: default-deny
spec:
podSelector:
- 在任何一个特定的命名空间里面创建这个Networkpolicy,则任何客户端都无法访问这个命名空间的pod
- 前提是kubernets集群里面的网络插件(cni)支持NetworkPolicy
4.2 允许同一个命名空间的部分pod访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: postgres-netpolicy
spec:
podSelector:
matchLabels:
app: database
ingress:
- from:
- podSelector:
matchLabels:
app: webserver
ports:
- port: 5432
- 这个networkpolicy允许命名空间中标签为database的pod被访问
- 并且只能被标签为webserver的pod访问
- 并且只能访问5432的端口
4.3 允许带有特定标签的命名空间的pod访问某个特定标签的pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: shopping-cart-policy
spec:
podSelector:
matchLabels:
app: shopping-cart
ingress:
- from:
- namespaceSelector:
matchLabels:
app: wxm
ports:
- port: 80
4.4 使用CIDR隔离网络
只能允许特定网端的pod访问指定的pod
ingress:
- from:
- ipBlock:
cidr: 192.168.1.0/24
4.5 限制pod的出流量
spec:
podSelector:
matchLabels:
app: webserver
egress:
- to:
- podSelector:
matchLabels:
app: database
- webserver标签只能和ddatabase标签访问,其余的任何pod和IP都不能访问
kubernets之节点和网络的安全保障策略的更多相关文章
- 一个C++版的网络数据包解析策略
C++版的网络数据包解析策略(升级版) 一.数据包格式形如下图 二.代码 int ReceiveFromRemoteEndPoint() { int nPackageDataLength = ; ch ...
- wxs 及 获取节点 和 网络请求
wxs:微信小程序脚本语言,结合 wxml 可以构建页面的结构 在 wxml 中使用 wxs wxs 中的注释 : 单行注释:// 多行注释:/* */ wxs 在页面中的用法 在页面中引用 wxs ...
- weave 建立跨节点docker网络
weave的工作原理上与利用openvswitch建立vxlan基本一样,都是通过用三层的协议封装二层的报文来进行扩展,weave使用的是udp.weave封装了docker,在操作上为我们隐藏了很多 ...
- kubernets 单节点安装
关闭防火墙和Selinux. setenforce 0 systemctl stop firewalld systemctl disable firewalld 配置EPEL源 yum install ...
- 一个节点rac+单节点dg网络配置(listener.ora与tnsnames.ora)
环境说明: 实验环境是 一个节点的 rac + 单机dg (主备全部用asm存储) tnsnames.ora 文件 (oracle用户) node 1 : node1-> pwd / ...
- 十四,K8s集群网络flannel及canal策略
目录 k8s网络CNI之flannel k8s网络通信模型 常见CNI插件(Container,Network,Interface) 插件通信一般的解决方案 网络插件的应用 Flannel插件 fla ...
- C++版的网络数据包解析策略(升级版)
初版:http://www.cnblogs.com/wjshan0808/p/6580638.html 说明:在实现了对应的接口后该策略可以适合绝大多数的网络数据包结构 首先,是三个接口 IProdu ...
- kubernter相关内容
1. Kubernetes 第一章:互联网架构的演变 随着1946年世界上第一台电子计算机的问世网络就随之出现了,只不过当初只是为了解决多个终端之间的连接,这就是局域网的雏形.后来,随着美国国防部高级 ...
- Kubernetes基础:Service
本文的试验环境为CentOS 7.3,Kubernetes集群为1.11.2,安装步骤参见kubeadm安装kubernetes V1.11.1 集群 Service 介绍 我们通过Pod.Deplo ...
随机推荐
- sqli-labs less-24(二次注入)
less-24 原理: 在网站处理用户提交的数据的时候,只是将某些敏感字符进行了转义.因而使得用户第一次提交的时候不会被当做代码执行.但是这些数据存入数据库的时候却没有转义,而网站程序默认数据库中的数 ...
- vue单页面应用刷新网页后vuex的state数据丢失的解决办法
第一种方案 首先将数据保存在vuex的store中,同时将这些信息也保存在sessionStorage中.这里需要注意的是vuex中的变量是响应式的,而sessionStorage不是,当你改变vue ...
- chrome 开发者工具使用一例
今天搜到了一篇我想看的文章,某网站上又是弹出注册小窗遮挡,又是一堆漂浮广告,还把字体搞成灰色. 右键审查元素,找到几个div,删掉:原来那个字体的灰色,是个什么script做的遮罩,也删掉. 然后整个 ...
- 钩子与API截获
http://www.pudn.com/Download/type/id/19.html
- mybatis-plus逻辑删除
MP(mybatis plus)已经大大简化了我们好多的开发操作,基本的增删改查都有了,包括代码生成等等,今天想说的是它的逻辑删除功能.我们都在数据库设计时候经常会有is字段,表示是否删除,为了留下员 ...
- .NET+SqlServer 实现数据读写分离
如今,我们操作数据库一般用ORM框架 现在用.NET Core + EFCore + SqlServer 实现数据读写分离 介绍 为什么要读写分离? 降低数据库服务器的压力 如何实现读写分离? 1.一 ...
- git原理学习记录:从基本指令到背后原理,实现一个简单的git
一开始我还担心 git 的原理会不会很难懂,但在阅读了官方文档后我发现其实并不难懂,似乎可以动手实现一个简单的 git,于是就有了下面这篇学习记录. 本文的叙述思路参照了官方文档Book的原理介绍部分 ...
- Redis 设计与实现 6:五大数据类型之字符串
前文 Redis 设计与实现 2:Redis 对象 说到,五大数据类型都会封装成 RedisObject. typedef struct redisObject { unsigned type:4; ...
- [永恒之黑]CVE-2020-0796(漏洞复现)
实验环境: 靶机:windows10 1903 专业版 攻击机:kali 2020.3 VMware:vmware14 实验工具: Python 3.8.5 msfconsole 实验PROC: ...
- Linux USB子系统(一)—— USB设备基础概念
一.基础概念 在终端用户看来,USB设备为主机提供了多种多样的附加功能,如文件传输,声音播放等,但对USB主机来说,它与所有USB设备的接口都是一致的.一个USB设备由3个功能模块组成:USB总线接口 ...