导读

Pod容器想要获取集群的资源信息,需要配置角色和ServiceAccount进行授权。为了更精细地控制Pod对资源的使用方式,Kubernetes从1.4版本开始引入了PodSecurityPolicy资源对象对Pod的安全策略进行管理。

Pod特权模式

容器内的进程获得的特权几乎与容器外的进程相同。使用特权模式,可以更容易地将网络和卷插件编写为独立的pod,不需要编译到kubelet中。

PodSecurityPolicy

官网定义

Pod 安全策略(Pod Security Policy) 是集群级别的资源,它能够控制Pod规约 中与安全性相关的各个方面。PodSecurityPolicy 对象定义了一组Pod运行时必须遵循的条件及相关字段的默认值,只有 Pod 满足这些条件才会被系统接受。

Pod 安全策略允许管理员控制如下方面:

Pod 安全策略 由设置和策略组成,它们能够控制 Pod 访问的安全特征。这些设置分为如下三类:

(1)基于布尔值控制 :这种类型的字段默认为最严格限制的值。

(2)基于被允许的值集合控制 :这种类型的字段会与这组值进行对比,以确认值被允许。

(3)基于策略控制 :设置项通过一种策略提供的机制来生成该值,这种机制能够确保指定的值落在被允许的这组值中。

开启

如果需要开启PodSecurityPolicy,需要在kube-apiserver的启动参数中设置如下参数

--enable-admission-plugins=PodSecurityPolicy

  

在开启PodSecurityPolicy准入控制器后,k8s默认不允许创建任何Pod,需要创建PodSecurityPolicy和RBAC授权策略,Pod才能创建成功。

注:修改kube-apiserver配置文件/etc/kubernetes/manifests/kube-apiserver.yaml,由于是static pod,所以修改就会生效。

系统默认此参数为:

--enable-admission-plugins=NodeRestriction

  

开启之后创建Pod会出现如下错误:

创建PodSecurityPolicy

下列PodSecurityPolicy表示是不允许创建特权模式的Pod

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: psp-non-privileged
spec:
privileged: false #不允许特权模式的Pod
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'

  

创建之后查看:

kubectl get psp
或者
kubectl get podSecurityPolicy

  

之后再次创建Pod就能创建成功

上面的PodSecurytiPolicy是设置了不允许创建特权模式的Pod,例如,在下面的YAML配置文件pod-privileged.yaml中为Pod设置了特权模式:

apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
securityContext:
privileged: true

  

创建的时候会报如下错误:

unable to validate against any pod security policy

PodSecurityPolicy配置详解

在PodSecurityPolicy对象中可以设置下列字段来控制Pod运行时的各种安全策略

(1)特权模式相关配置

privileged:是否允许Pod以特权模式运行

(2)宿主机资源相关配置

1、hostPID:是否允许Pod共享宿主机的进程空间

2、hostIPC:是否允许Pod共享宿主机的IPC命名空间

3、hostNetwork:是否允许Pod共享宿主机网络的命名空间

4、hostPorts:是否允许Pod使用宿主机的端口号,可以通过hostPortRange字段设置允许使用的端口号范围,以[min, max]设置最小端口号和最大端口号

5、Volumes:允许Pod使用的存储卷Volume类型,设置为“*”表示允许使用任意Volume类型,建议至少允许Pod使用下列Volume类型。configMap,emptyDir、downwardAPI、persistentVolumeClaim、secret、projected

6、AllowedHostPaths:允许Pod使用宿主机的hostPath路径名称,可通过pathPrefix字段设置路径的前缀,并可以设置是否只读属性,例如:只允许Pod访问宿主机上以“/foo”为前缀的路径,包 括“/foo”“/foo/”“/foo/bar”等,

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: all-hostpath-volumes
spec:
volumes:
- hostPath
allowedHostPaths:
- pathPrefix: "/foo"
readOnly: true

  

7、FSGroup:设置允许访问某些Volume的Group ID范围,可以将rule字段设置为ManyRunAs、MayRunAs、RunAsAny

MustRunAs:需要设置Group ID的范围,例如1~65535,要求Pod的securityContext.fsGroup设置的值必须属于该Group ID的范围。

MayRunAs:需要设置Group ID的范围,例如1~65535,不强制要求Pod设置securityContext.fsGroup。

RunAsAny:不限制Group ID的范围,任何Group都可以访问Volume。

8、ReadOnlyRootFilesystem:要求容器运行的根文件系统(root filesystem)必须是只读的

9、allowedFlexVolumes:对于类型为flexVolume的存储卷,设置允许使用的驱动类型,例如:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: allowedflexvolumes
spec:
volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs

  

(3)用户和组相关配置

1、RunAsUser:设置运行容器的用户ID范围,rule可以被设置为MustRunAs、MustRunAsNonRoot或RunAsAny

MustRunAs:需要设置User ID的范围,要求Pod的securityContext.runAsUser设置的值必须属于该User ID的范围。

MustRunAsNonRoot:必须以非root用户运行容器,要求Pod的 securityContext.runAsUser设置一个非0的用户ID,或者镜像中在USER字段设置了用户ID,建议同时设置allowPrivilegeEscalation=false以避免不 必要的提升权限操作。

RunAsAny:不限制User ID的范围,任何User都可以运行。

2、RunAsGroup:设置运行容器的Group ID范围,可以被设置为MustRunAs、MustRunAsNonRoot、RunAsAny

MustRunAs:需要设置Group ID的范围,要求Pod的securityContext.runAsGroup设置的值必须属于该Group ID的范围。

MustRunAsNonRoot:必须以非root组运行容器,要求Pod的securityContext.runAsUser设置一个非0的用户ID,或者镜像中在USER字段设置了用户ID,建议同时设置allowPrivilegeEscalation=false以避免不必要的提升权限操作。

RunAsAny:不限制Group ID的范围,任何Group的用户都可以运行。

3、SupplementalGroups:设置容器可以额外添加的Group ID范围,可以将规则(rule字段)设置为MustRunAs、MayRunAs或RunAsAny

MustRunAs:需要设置Group ID的范围,要求Pod的securityContext.supplementalGroups设置的值必须属于该Group ID范围。

MayRunAs:需要设置Group ID的范围,不强制要求Pod设置 securityContext.supplementalGroups。

RunAsAny:不限制Group ID的范围,任何supplementalGroups的用户都可以运行。

(4)提升权限相关配置

1、AllowPrivilegeEscalation:用于设置容器内的子进程是否可以提升权限,通常在设置非Root用户(MustRunAsNonRoot)时进行设置。

2、DefaultAllowPrivilegeEscalation:设置AllowPrivilegeEscalation的默认值,设置为disallow时,管理员还可以显式设置 AllowPrivilegeEscalation来指定是否允许提升权限。

(5)Linux能力相关配置

1、AllowedCapabilities:设置容器使用的linux能力列表,设置为“*”表示允许使用Linux的所有能力(如NET_ADMIN、SYS_TIME等)。

2、RequiredDropCapabilities:设置不允许容器使用的linux能力列表

3、DefaultAddCapabilities:设置默认为容器添加的Linux能力列表,例如SYS_TIME等

(6)SELinux相关配置

seLinux:设置SELinux参数,可以将规则字段(rule)的值设置为MustRunAs或RunAsAny。

MustRunAs:要求设置seLinuxOptions,系统将对Pod的securityContext.seLinuxOptions设置的值进行校验。

RunAsAny:不限制seLinuxOptions的设置

(7)其它Linux相关配置

1、AllowedProcMountType:设置允许的PropMountTypes类型列表,可以设置allowedProcMountTypes或DefaultProcMount。

2、AppArmor:设置对容器可执行程序的访问控制权限,

3、Seccomp:设置允许容器使用的系统调用(System Calls)的profile

4、Sysctl:设置允许调整的内核参数,

(8)列举两种常用的PodSecurityPolicy安全策略配置

1、基本没有限制的安全策略,允许创建任意安全设置的Pod。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: privileged
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: "*"
spec:
privileged: true #不允许创建特权模式的Pod
allowPrivilegeEscalation: true #设置子进程是否可以提升权限,配置MustRunAsNonRoot
allowedCapabilities:
- '*'
volumes:
- '*'
hostNetwork: true
hostPorts:
- min: 0
max: 65535
hostIPC: true
hostPID: true
runAsUser:
rule: 'RunAsAny'
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'RunAsAny'
fsGroup:
rule: 'RunAsAny'

  

2、要求Pod运行用户为非特权用户;禁止提升权限;不允许使用宿主机网络、端口号、IPC等资源;限制可以使用的Volume类型,等等

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: retricted
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
seccomp.security.alpha.kubernetes.io/defaultProfileNames: 'docker/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
apparmor.security.beta.kubernetes.io/defaultProfileNames: 'runtime/default'
spec:
privileged: false
allowPrivilegeEscalation: false
requiredDropCapabilities:
- ALL
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
- 'persistentVolumeClaim'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
rule: 'MustRunAsNonRoot'
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAsRoot'
ranges:
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAsRoot'
ranges:
- min: 1
max: 65535
readOnlyRootFilesystem: false

  

Kubernetes建议使用RBAC授权机制来设置针对Pod安全策略的授权,通常应该对Pod的ServiceAccount进行授权。

例如,可以创建如下ClusterRole(也可以创建Role)并将其设置为允许使用PodSecurityPolicy:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: role-name
rules:
- apiGroups: ['policy']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames:
- #允许使用的PodSecurityPolicy列表

  

然后创建一个ClusterRoleBinding与用户和ServiceAccount进行绑定

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: bind-name
ruleRef:
kind: ClusterRole
name: role-name
apiGroup: rabc.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: serviceaccount
namespace:
- kind: User
name: username
apiGroup: rbac.authorization.k8s.io

  

也可以创建RoleBinding对与该RoleBinding相同的Namespace中的Pod进行授权,通常可以与某个系统级别的Group关联配置,例如:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: bind-name
namespace: namespace #该RoleBinding所属的namespace
roleRef:
kind: Role
name:
apiGroup: rabc.authorization.k8s.io
subjects:
#授权该Namespace中的全部ServiceAccount
- kind: Group
apiGroup: rabc.authorization.k8s.io
name: system:serviceaccounts
#授权该Namespace的全部用户
- kind: User
apiGroup: rabc.authorization.k8s.io
name: system:authenticated

  

Pod的安全设置详解

Pod和容器的安全策略可以在Pod或Container的securityContext字段中设置,如果在Pod和Container级别都设置了相同的安全类型字段,容器将使用Container级别的设置。

在Pod级别可以设置的安全措施如下:

◎ runAsUser:容器内运行程序的用户ID。

◎ runAsGroup:容器内运行程序的用户组ID。

◎ runAsNonRoot:是否必须以非root用户运行程序。◎ fsGroup:SELinux相关设置。

◎ seLinuxOptions:SELinux相关设置。

◎ supplementalGroups:允许容器使用的其他用户组ID。

◎ sysctls:设置允许调整的内核参数。

在Container级别可以设置的安全策略类型如下:

◎ runAsUser:容器内运行程序的用户ID。

◎ runAsGroup:容器内运行程序的用户组ID。

◎ runAsNonRoot:是否必须以非root用户运行程序。

◎ privileged:是否以特权模式运行。

◎ allowPrivilegeEscalation:是否允许提升权限。

◎ readOnlyRootFilesystem:根文件系统是否为只读属性。

◎ capabilities:Linux能力列表。

◎ seLinuxOptions:SELinux相关设置。

例如:Pod级别的安全设置,作用于该Pod内的全部容器

apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: nginx
volumeMounts:
- name: sec-ctx-demo
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: false

  

◎ runAsUser=1000:所有容器都将以User ID 1000运行程序,所有新生成文件的User ID也被设置为1000。

◎ runAsGroup=3000:所有容器都将以Group ID 3000运行程序,所有新生成文件的Group ID也被设置为3000。

◎ fsGroup=2000:挂载的卷“/data/demo”及其中创建的文件都将属于Group ID 2000。

Container级别的安全设置,作用于特定的容器。

apiVersion: v1
kind: Pod
metadata:
name: scd-2
spec:
securityContext:
runAsUser: 1000
containers:
- name: scd-2
image: nginx:latest
imagePullPolicy: IfNotPresent
securityContext:
runAsUser: 2000
allowPrivilegeEscalation: false

  

为Container设置可用的Linux能力,为容器设置允许使用的Linux能力包括NET_ADMIN和SYS_TIME。

apiVersion: v1
kind: Pod
metadata:
name: scd-3
spec:
containers:
- name: scd-3
image: nginx
securityContext:
capabilities:
add: ["NET_ADMIN","SYS_TIME"]

  

===============================

我是Liusy,一个喜欢健身的程序员。

获取更多干货以及最新消息,请关注公众号:上古伪神

如果对您有帮助,点个关注就是对我最大的支持!!!

一文读懂k8s之Pod安全策略的更多相关文章

  1. kubernetes基础——一文读懂k8s

    容器 容器与虚拟机对比图(左边为容器.右边为虚拟机)   容器技术是虚拟化技术的一种,以Docker为例,Docker利用Linux的LXC(LinuX Containers)技术.CGroup(Co ...

  2. 一文读懂k8s rbac 权限验证

    自我认为的k8s三大难点:权限验证,覆盖网络,各种证书. 今天就说一下我所理解的权限验证rbac. 咱不说rbac0,rbac1,rbac2,rbac3.咱就说怎么控制权限就行. 一.前言 1,反正R ...

  3. 一图读懂k8s informer client-go

    概述 为什么要有k8s informer 我们都知道可以使用k8s的Clientset来获取所有的原生资源对象,那么怎么能持续的获取集群的所有资源对象,或监听集群的资源对象数据的变化呢?这里不需要轮询 ...

  4. 一文读懂HTTP/2及HTTP/3特性

    摘要: 学习 HTTP/2 与 HTTP/3. 前言 HTTP/2 相比于 HTTP/1,可以说是大幅度提高了网页的性能,只需要升级到该协议就可以减少很多之前需要做的性能优化工作,当然兼容问题以及如何 ...

  5. 一文读懂AI简史:当年各国烧钱许下的愿,有些至今仍未实现

    一文读懂AI简史:当年各国烧钱许下的愿,有些至今仍未实现 导读:近日,马云.马化腾.李彦宏等互联网大佬纷纷亮相2018世界人工智能大会,并登台演讲.关于人工智能的现状与未来,他们提出了各自的观点,也引 ...

  6. 一文读懂高性能网络编程中的I/O模型

    1.前言 随着互联网的发展,面对海量用户高并发业务,传统的阻塞式的服务端架构模式已经无能为力.本文(和下篇<高性能网络编程(六):一文读懂高性能网络编程中的线程模型>)旨在为大家提供有用的 ...

  7. 从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

    本文原作者阮一峰,作者博客:ruanyifeng.com. 1.引言 HTTP 协议是最重要的互联网基础协议之一,它从最初的仅为浏览网页的目的进化到现在,已经是短连接通信的事实工业标准,最新版本 HT ...

  8. 一文读懂 深度强化学习算法 A3C (Actor-Critic Algorithm)

    一文读懂 深度强化学习算法 A3C (Actor-Critic Algorithm) 2017-12-25  16:29:19   对于 A3C 算法感觉自己总是一知半解,现将其梳理一下,记录在此,也 ...

  9. [转帖]MerkleDAG全面解析 一文读懂什么是默克尔有向无环图

    MerkleDAG全面解析 一文读懂什么是默克尔有向无环图 2018-08-16 15:58区块链/技术 MerkleDAG作为IPFS的核心数据结构,它融合了Merkle Tree和DAG的优点,今 ...

随机推荐

  1. IOS中使用.xib文件封装一个自定义View

    1.新建一个继承UIView的自定义view,假设类名叫做 MyAppVew #import <UIKit/UIKit.h> @class MyApp; @interface MyAppV ...

  2. MongoDB加索引DB崩溃的问题

    项目原因,最近在对MongoDB进行数据存储优化   原有问题: 日志数据量比较大,存到一张表,需要手工定时删除数据,且删除数据时间按天算 数据会定时打包到HDFS,查询时间很慢,需要优化 机器内存占 ...

  3. 3. 搞定收工,PropertyEditor就到这

    分享.成长,拒绝浅藏辄止.搜索公众号[BAT的乌托邦],回复关键字专栏有Spring技术栈.中间件等小而美的原创专栏供以免费学习.本文已被 https://www.yourbatman.cn 收录. ...

  4. rbd锁引起kvm虚拟机无法启动的故障

    前言 环境因为一些问题(网络,或者磁盘,或者其它各种异常),引起了集群的状态的一些变化,变化之后,集群的某些虚拟机正常某些虚拟机出现异常,异常现象就是无法启动 特别是win server2008 ,会 ...

  5. C#中RDLC报表判断某字段的值为null

    =iif(Isnothing(Fields!VerifyStateName.Value),"未上报",Fields!VerifyStateName.Value)   空值时赋予默认 ...

  6. CSS系列 (04):盒模型详解

    盒模型 CSS盒模型分成W3C标准盒模型和IE模型 W3C标准盒模型(默认):box-sizing: content-box padding和border都会撑开盒子,改变盒子的宽度高度 总宽度:wi ...

  7. postgre sql递归查询

    WITH  RECURSIVE  r  AS (SELECT * FROM [表] WHERE id = xxxunion ALLSELECT [表].* FROM [表], r WHERE [表]. ...

  8. Spring循环依赖解决方式源码解析

    1. 什么是循环依赖? 循环依赖其实就是循环引用,也就是两个或则两个以上的bean互相持有对方,最终形成闭环.比如A依赖于B,B依赖于A我们直接上代码 先创建一个类ServiceA依赖于Service ...

  9. Layui关闭弹出层对话框--刷新父界面

    在毕设的开发中,添加用户.添加权限等等一些地方需要类似于bootstrap中的模态框.然而开发用的却是layui 在layui中有弹出层可以实现其中的效果. 但是,一般用的时候都是提交后关闭窗口,刷新 ...

  10. linux零基础之--使用putty配置

    PuTTY是一个Telnet.SSH.rlogin.纯TCP以及串行接口连接软件.随着Linux在服务器端应用的普及,Linux系统管理越来越依赖于远程.在各种远程登录工具中,Putty是出色的工具之 ...