13.1.在pod中使用宿主节点的Linux命名空间

13.1.1.在pod中使用宿主节点的网络命名空间

  在pod的yaml文件中就设置spec.hostNetwork: true

   这个时候pod使用宿主机的网络,如果设置了端口,则使用宿主机的端口。

apiVersion: v1
kind: pod
metadata:
name: pod-host-yaohong
spec:
hostNetwork: true //使用宿主节点的网络命名空间
containers:
- image: luksa/kubia
command: ["/bin/sleep", "9999"]

13.1.2.绑定宿主节点上的端口而不使用宿主节点的网络命名空间

  在pod的yaml文件中就设置spec.containers.ports字段来设置

   在ports字段中可以使用

  containerPorts设置通过pod 的ip访问的端口

  container.hostPort设置通过所在节点的端口访问

apiVersion: v1
kind: pod
metadata:
name: kubia-hostport-yaohong
spec:
containers:
- image: luksa/kubia
- name: kubia
ports:
- containerport: 8080 //该容器通过pod IP访问该端口
hostport: 9000 //该容器可以通过它所在节点9000端口访问
protocol: Tcp

13.1.3.使用宿主节点的PID与IPC

   PID是进程ID,PPID是父进程ID

  在linux下的多个进程间的通信机制叫做IPC(Inter-Process Communication),它是多个进程之间相互沟通的一种方法。

apiVersion: v1
kind: pod
metadata:
name: pod-with-host-pid-and-ipc-yaohong
spec:
hostPID: true //你希望这个pod使用宿主节点的PID命名空间
hostIPC: true //你希望pod使用宿主节点的IPC命名空间
containers:
- name: main
image: alpine
command: ["/bin/sleep", "99999"]

 

13.2.配置节点的安全上下文

13.2.1.使用指定用户运行容器

  查看某个pod运行的用户

$ kubectl -n kube-system exec coredns-7b8dbb87dd-6ll7z id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

  容器的运行用户再DockerFile中指定,如果没有指定则为root

  指定pod的运行的用户方法如下

apiVersion: v1
kind: pod
metadata:
name: pod-as-user
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "99999"]
securityContext:
runAsUser: 405 //你需要指定的用户ID,而不是用户名

13.2.2.阻止容器以root用户运行

  runAsNonRoot来设置
apiVersion: v1
kind: pod
metadata:
name: pod-as-user
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "99999"]
securityContext:
runAsNonRoot: true //这个容器只允许以非root用户运行

13.2.3.使用特权模式运行pod

  为了获得宿主机内核完整的权限,该pod需要在特权模式下运行。需要添加privileged参数为true。

apiVersion: v1
kind: pod
metadata:
name: pod-as-privileged
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "99999"]
securityContext:
privileged: true //这个容器将在特权模式下运行

13.2.4.为容器单独添加内核功能

apiVersion: v1
kind: pod
metadata:
name: pod-as-capability
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "99999"]
securityContext:
capabilities: //该参数用于pod添加或者禁用某项内核功能
add:
- SYS_TIME //添加修改系统时间参数

13.2.5.在容器中禁止使用内核功能

apiVersion: v1
kind: pod
metadata:
name: pod-as-capability
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "99999"]
securityContext:
capabilities: //该参数用于pod添加或者禁用某项内核功能
drop:
- CHOWN //禁用容器修改文件的所有者

13.2.6.阻止对容器根文件系统的写入

  securityContext.readyOnlyFilesystem设置为true来实现阻止对容器根文件系统的写入。
apiVersion: v1
kind: pod
metadata:
name: pod-with-readonly-filesystem
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "99999"]
securityContext:
readyOnlyFilesystem: true //这个容器的根文件系统不允许写入
volumeMounts:
- name: my-volume
mountPath: /volume //volume写入是允许的,因为这个目录挂载一个存储卷
readOnly: false 

13.3.限制pod使用安全相关的特性

13.3.1.PodSecurityPolicy资源介绍

  PodSecurityPolicy是一种集群级别(无命名空间)的资源,它定义了用户能否在pod中使用各种安全相关的特性。

13.3.2.了解runAsUser、fsGroups和supplementalGroup策略

runAsUser:
runle: MustRunAs
ranges:
- min: 2 //添加一个max=min的range,来指定一个ID为2的user
max: 2
fsGroup:
rule: MustRunAs
ranges:
- min: 2
max: 10 //添加多个区间id的限制,为2-10 或者20-30
- min: 20
max: 30
supplementalGroups:
rule: MustRunAs
ranges:
- min: 2
max: 10
- min: 20
max: 30

13.3.3.配置允许、默认添加、禁止使用的内核功能

  三个字段会影响容器的使用

  allowedCapabilities:指定容器可以添加的内核功能
  defaultAddCapabilities:为所有容器添加的内核功能
  requiredDropCapabilities:禁止容器中的内核功能
apiVersion: v1
kind: PodSecurityPolicy
spec:
allowedCapabilities:
- SYS_TIME //允许容器添加SYS_time功能
defaultAddCapabilities:
- CHOWN //为每个容器自动添加CHOWN功能
requiredDropCapabilities:
- SYS_ADMIN //要求容器禁用SYS_ADMIN和SYS_MODULE功能

13.4.隔离pod网络

13.4.1.在一个命名空间中使用网络隔离

  podSelector进行对一个命名空间下的pod进行隔离

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: postgres-netpolicy
spec:
podSelector: //这个策略确保了对具有app=databases标签的pod的访问安全性
matchLabels:
app: database
ingress:
- from:
- podSelector: //它只允许来自具有app=webserver标签的pod的访问
matchLabels:
app: webserver
ports:
- port: 5432 //允许对这个端口的访问

13.4.2.在 不同的kubernetes命名空间之间进行网络隔离

  namespaceSelector进行对不同命名空间间进行网络隔离

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: postgres-netpolicy
spec:
podSelector: //这个策略确保了对具有app=databases标签的pod的访问安全性
matchLabels:
app: database
ingress:
- from:
- namespaceSelector: //只允许tenant: manning标签的命名空间中运行的pod进行互相访问
matchLabels:
tenant: manning
ports:
- port: 5432 //允许对这个端口的访问

13.4.3.使用CIDR网络隔离

  ingress:
- from:
- ipBlock:
cidr: 192.168.1.0/24 //指明允许访问的ip段

13.4.4.限制pod对外访问流量

  使用egress进行限制

spec:
podSelector: //这个策略确保了对具有app=databases标签的pod的访问安全性
matchLabels:
app: database
egress: //限制pod的出网流量
- to:
- podSelector:
matchLables: //database的pod只能与有app: webserver的pod进行通信
app: webserver

  

Kubernetes-保障集群内节点和网络安全的更多相关文章

  1. kubernetes 搭建集群内服务

    nginx-rc.yaml apiVersion: v1 kind: ReplicationController metadata: name: webapp spec: replicas: 2 te ...

  2. Kubernetes容器集群管理环境 - 完整部署(上篇)

    Kubernetes(通常称为"K8S")是Google开源的容器集群管理系统.其设计目标是在主机集群之间提供一个能够自动化部署.可拓展.应用容器可运营的平台.Kubernetes ...

  3. Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列之部署master/node节点组件(四)

    0.前言 整体架构目录:ASP.NET Core分布式项目实战-目录 k8s架构目录:Kubernetes(k8s)集群部署(k8s企业级Docker容器集群管理)系列目录 1.部署master组件 ...

  4. 云原生时代, Kubernetes 多集群架构初探

    为什么我们需要多集群? 近年来,多集群架构已经成为“老生常谈”.我们喜欢高可用,喜欢异地多可用区,而多集群架构天生就具备了这样的能力.另一方面我们也希望通过多集群混合云来降低成本,利用到不同集群各自的 ...

  5. 实现Kubernetes跨集群服务应用的高可用

    在Kubernetes 1.3版本,我们希望降低跨集群跨地区服务部署相关的管理和运营难度.本文介绍如何实现此目标. 注意:虽然本文示例使用谷歌容器引擎(GKE)来提供Kubernetes集群,您可以在 ...

  6. 手动部署 kubernetes HA 集群

    前言 关于kubernetes HA集群部署的方式有很多种(这里的HA指的是master apiserver的高可用),比如通过keepalived vip漂移的方式.haproxy/nginx负载均 ...

  7. Elasticsearch从入门到精通之Elasticsearch集群内的原理

    上一章节我介绍了Elasticsearch安装与运行,本章节及后续章节将全方位介绍 Elasticsearch 的工作原理 在这个章节中,我将会再进一步介绍 cluster . node . shar ...

  8. 一键安装基于dns的高可用k8s集群(3节点,etcd https)

    在公司,使用dns切换,可能会比keepalived+haproxy,更精简的易维护. 毕竟,高可用只是偶尔切换,不是时时切换. 且dns解析在自己可控时,更不会影响k8s线上使用了. (部分代码,由 ...

  9. 如何落地全球最大 Kubernetes 生产集群

        鲍永成   京东基础架构部技术总监,   DevOps 标准核心编写专家   前言   JDOS 就是京东数据中心操作系统,随着数据中心规模不断的扩大,我们需要对数据中心做综合的考虑.所以一开 ...

随机推荐

  1. 解决webpack打包速度慢的解决办法

    技巧1 webpack在打包的时候第一次总是会做很长的准备工作,包括加载插件之类的.在刚接触webpack的时候总是webpack一下-测一下-改一下-再webpack一下,这种方式最后让很多人崩溃了 ...

  2. JAVA十大经典排序算法最强总结(含JAVA代码实现)

    十大经典排序算法最强总结(含JAVA代码实现)   最近几天在研究排序算法,看了很多博客,发现网上有的文章中对排序算法解释的并不是很透彻,而且有很多代码都是错误的,例如有的文章中在“桶排序”算法中对每 ...

  3. Socket编程(C语言实现):bind()函数英文翻译

    本篇翻译的bind()函数,我参考的国外网站是: bind 朋友们可以自由转载我对英文的中文翻译,但是对于"作者注:"的描述,转载时请注明出处和作者,否则视为侵权. 下面是翻译的正 ...

  4. Single Thread Execution设计模式

    public class Test { public static void main(String[] args){ // FlightSercurityTest.test(); // EatNoo ...

  5. 【最小生成树之Kruskal例题-建设电力系统】-C++

    前置知识点Kruskal最短路算法,如果没掌握的请先去掌握! 描述 小明所在的城市由于下暴雪的原因,电力系统严重受损.许多电力线路被破坏,因此许多村庄与主电网失去了联系.政府想尽快重建电力系统,所以, ...

  6. python 的深浅拷贝问题

    深浅拷贝概念 基本类型和引用类型数据拷贝的问题.因为基本类型的数据大小是固定的,所以他保存在栈内存中:而引用类型的数据大小不固定,因而保存在堆内存中,单引用类型在栈内存中只保存一个指向堆内存的指针. ...

  7. UVA514 铁轨 Rails:题解

    题目链接:https://www.luogu.org/problemnew/show/UVA514 分析: 入站序列是1-n,入站后判断如果等于出站序列的当前值,则直接出站.否则就在栈里待着不动.模拟 ...

  8. 踩坑 Spring Cloud Hystrix 线程池队列配置

    背景: 有一次在生产环境,突然出现了很多笔还款单被挂起,后来排查原因,发现是内部系统调用时出现了Hystrix调用异常.在开发过程中,因为核心线程数设置的比较大,没有出现这种异常.放到了测试环境,偶尔 ...

  9. restapi(2)- generic restful CRUD:通用的restful风格数据库表维护工具

    研究关于restapi的初衷是想搞一套通用的平台数据表维护http工具.前面谈过身份验证和使用权限.文件的上传下载,这次来到具体的数据库表维护.我们在这篇示范里设计一套通用的对平台每一个数据表的标准维 ...

  10. Js面向对象构造函数继承

    构造函数继承 <!-- 创建构造函数 --> function Animal(){ this.species= '动物'; } function Dog(name,color){ this ...