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 ...
随机推荐
- unity入门—资源导入与场景创建
前言: 从这一篇章开始,我将会通过游戏实例来讲解如何使用unity制作一个标准的游戏,介绍的内容较多,需要整理的东西也多可能中途会有一两天的咕咕咕,预计想要完成两个游戏,一个射击类一个塔防类,从射击类 ...
- 二、TestNG的Hello World
创建第一个TestNG的例子 1.创建一个TestNG的类 选择项目路径"右键"--NEW--Other 选择TestNG cLass(如果没有这个选项是testng没有配置成功) ...
- Rest vs Soap 比较
一.前言 昨天为止,政府的一个公共部门的项目顺利结束,就系统间消息传输这个点,知识点总结一下.本文主要参考octoperf的文章,链接见文末参考资料. 系统中用到的是SOAP协议进行传输数据,有人会立 ...
- Eureka 集群Demo
由于自己遇到了一些eureka集群疑问,就自己搭了一个集群demo进行测试.测试中通过两个eureka相互注册形成集群,两个服务提供者向eureka中注册服务,两个服务消费者通过feign进行服务调用 ...
- 利用302绕过http协议限制
360某处ssrf漏洞可探测内网信息(附内网6379探测脚本) http://xss.one/bug_detail.php?wybug_id=wooyun-2016-0229611
- swift笔记简录
一,变量和常量 /***************************基本数据类型*************************/ /****************************** ...
- MongoDB导入bson文件(元数据),mongorestore命令行方式导入
MongoDB导入bson文件(元数据),mongorestore命令行方式导入 不推荐使用MongoDB Compass等图形化数据库管理软件,例如MongoDB Compass只能导入json和c ...
- RocketMQ(七):高性能探秘之线程池
上一篇文章讲了如何设计和实现高并发高性能的应用,从根本上说明了一些道理.且以rocketmq的mappedFile的实现作为一个突破点,讲解了rocketmq是如何具体实现高性能的.从中我们也知道,m ...
- Dubbo服务调用过程源码解析④
目录 0.服务的调用 1.发送请求 2.请求编码 3.请求的解码 4.调用具体服务 5.返回调用结果 6.接收调用结果 Dubbo SPI源码解析① Dubbo服务暴露源码解析② Dubbo服务引用源 ...
- Java学习_反射
什么是反射? 反射就是Reflection,Java的反射是指程序在运行期可以拿到一个对象的所有信息. 反射是为了解决在运行期,对某个实例一无所知的情况下,如何调用其方法. JAVA反射机制是在运行状 ...