Secret私密凭据
上一节提刀Secret对象,Secret的主要作用是保管私密数据,比如密码、OAuth Tokens、 SSH Key等信息。将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全,也更便于使用和分发。
下面的例子用于创建一个Secret:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: dmFsdWUtMg0K
username: dmFsdWUtMQ0K
在上面的例子中,data域的各子域的值必须为BASE64编码值,其中password域和username域BASE64编码前的值分别为value-1和value-2。
一旦Secret被创建,就可以通过下面三种方式使用它。
(1)在创建Pod时,通过为Pod指定Service Account来自动使用该Secret。
(2)通过挂载该Secret到Pod来使用它。
(3)在Docker镜像下载时使用,通过指定Pod的spc.ImagePullSecrets来引用它。
第1种使用方式主要用在API Server鉴权方面,之前提到过。下面的例子展示了第2种使用方式:将一个Secret通过挂载的方式添加到Pod的Volume中:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mycontainer
image: tomcat
volumeMounts:
- name: foo1
mountPath: "/etc/foo1"
readOnly: true
volumes:
- name: foo1
secret:
secretName: mysecret
第3种使用方式的使用流程如下:
(1)执行login命令,登录私有Registry:
docker login localhost:8000
输入用户名和密码,如果是第1次登录系统,则会创建新用户,相关信息被会写入~/.dockercfg文件中。
(2)用BASE64编码dockercfg的内容:
cat ~/.dockercfg base64
(3)将上一步命令的输出结果作为Secret的data.dockercfg域的内容,由此来创建一个Secret:
# image-poll-secret.yaml:
apiVersion: v1
kind: Secret
metadata:
name: myregistrykey
data:
dockercfg: .......................................
type: kubernetes.io/dockercfg
kubectl create -f image-pull-secret.yaml
(4)在创建Pod时引用该Secret:
# pods.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod2
spec:
containers:
- name: foo
image: jaychou/tomcat:v1
imagePullSecrets:
- name: myregistrykey
kubectl create -f pods.yaml
在使用Mount方式挂载Secret时,Container中Secret的data域的各个域的Key值作为目录中的文件,Value值被BASE64编码后存储在相应的文件中。在前面的例子中创建的Secret,被挂载到一个叫作mycontainer的Container中,在该Container中可通过相应的查询命令查看所生成的文件和文件中的内容,如下所示:
通过上面的例子可以得出如下结论:我们可以通过Secret保管其他系统的敏感信息(比如数据库的用户名和密码),并以Mount的方式将Secret挂载到Container中,然后通过访问目录中文件的方式获取该敏感信息。当Pod被API Server创建时,API Server不会校验该Pod引用的Secret是否存在。一旦这个Pod被调度,则kubelet将试着获取Secret的值。如果Secret不存在或暂时无法连接到API Server,则kubelet按一定的时间间隔定期重试获取该Secret,并发送一个Event来解释Pod没有启动的原因。一旦Secret被Pod获取,则kubelet将创建并挂载包含Secret的Volume。只有所有Volume都挂载成功,Pod中的Container才会被启动。在kubelet启动Pod中的Container后,Container中和Secret相关的Volume将不会被改变,即使Secret本身被修改。为了使用更新后的Secret,必须删除旧Pod,并重新创建一个新Pod。
Pod的安全策略配置
为了更精细地控制Pod对资源的使用方式,Kubernetes从1.4版本开始引入了PodSecurityPolicy资源对象对Pod的安全策略进行管理,并在1.10版本中升级为Beta版,到1.14版本时趋于成熟。目前PodSecurityPolicy资源对象的API版本为extensions/v1beta1,从1.10版本开始更新为policy/v1beta1,并计划于1.16版本时弃用extensions/v1beta1。
1.PodSecurityPolicy的工作机制
若想启用PodSecurityPolicy机制,则需要在kube-apiserver服务的启动参数--enable-admission-plugins中进行设置:
如果是高可用,所有apiserver均需要修改
kubectl edit pod -n kube-system kube-apiserver-k8s-master1
--enable-admission-plugins=PodSecurityPolicy
在开启PodSecurityPolicy准入控制器后,Kubernetes默认不允许创建任何Pod,需要创建PodSecurityPolicy策略和相应的RBAC授权策略(Authorizing Policies),Pod才能创建成功。
例如,尝试创建如下Pod:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
使用Kubectl命令创建时,系统将提示“禁止创建”的报错信息。
接下来创建一个PodSecurityPolicy,配置文件psp-non-privileged.yaml的内容如下:
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:
- '*'
之后再次创建Pod既可成功。
上面的PodSecurityPolicy“psp-non-privileged”设置了privileged: false,表示不允许创建特权模式的Pod。在下面的YAML配置文件pod-privileged.yaml中为Pod设置了特权模式:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
securityContext:
privileged: true
创建Pod时,系统将提示“禁止创建特权模式的Pod”的报错信息.
2.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
◎ downwardAPI
◎ emptyDir
◎ persistentVolumeClaim
◎ secret
◎ projected
(6)AllowedHostPaths:允许Pod使用宿主机的hostPath路径名称,可以通过pathPrefix字段设置路径的前缀,并可以设置是否为只读属性,例子如下。
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: allow-hostpath-volumes
spec:
volumes:
- hostPath
allowedHostPaths:
- pathPrefix: "/foo"
readOnly: true
结果为允许Pod访问宿主机上以“/foo”为前缀的路径,包括“/foo”“/foo/”“/foo/bar”等,但不能访问“/fool”“/etc/foo”等路径,也不允许通过“/foo/../”表达式访问/foo的上层目录。
(7)FSGroup:设置允许访问某些Volume的Group ID范围,可以将规则(rule字段)设置为MustRunAs、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: allow-flex-volumes
spec:
volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs
3.用户和组相关配置
(1)RunAsUser:设置运行容器的用户ID(User 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等,Docker建议默认设置的Linux能力请查看https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities。
6.SELinux相关配置
seLinux:设置SELinux参数,可以将规则字段(rule)的值设置为MustRunAs或RunAsAny。
◎ MustRunAs:要求设置seLinuxOptions,系统将对Pod的securityContext.seLinuxOptions设置的值进行校验。
◎ RunAsAny:不限制seLinuxOptions的设置。
7.其他Linux相关配置
(1)AllowedProcMountTypes:设置允许的ProcMountTypes类型列表,可以设置allowedProcMountTypes或DefaultProcMount。
(2)AppArmor:设置对容器可执行程序的访问控制权限,详情请参考https://kubernetes.io/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations
notations。
(3)Seccomp:设置允许容器使用的系统调用(System Calls)的profile。
(4)Sysctl:设置允许调整的内核参数,详情请参考https://kubernetes.io/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy
下面列举两种常用的PodSecurityPolicy安全策略配置。
例1:基本没有限制的安全策略,允许创建任意安全设置的Pod。
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: privileged
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
privileged: true
allowPrivilegeEscalation: true
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: restricted
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default'
apparmor.security.beta.kubernetes.io/dafaultProfileName: '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: 'MustRunAs'
ranges:
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
readOnlyRootFilesystem: false
此外,Kubernetes建议使用RBAC授权机制来设置针对Pod安全策略的授权,通常应该对Pod的ServiceAccount进行授权。
例如,可以创建如下ClusterRole(也可以创建Role)并将其设置为允许使用PodSecurityPolicy:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: <role name>
rules:
- apiGroup: ['policy']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames:
- <list of policies to authorize> # 允许使用的PodSecurityPolicy列表
然后创建一个ClusterRoleBinding与用户和ServiceAccount进行绑定:
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: <binding name>
roleRef:
kind: ClusterRole
name: <roke name> # 之前创建的ClusterRole名称
apiGroup: rbac.authorization.k8s.io
subjects:
# 对特定Namespace中的ServiceAccount进行授权
- kind: ServiceAccount
name: <authorized servie account name> # ServiceAccount 的名称
namespace: <authorized pod namespace> # Namespace的名称
# 对特定用户进行授权(不推荐)
- kind: User
apiGroup: rbac.authorization.k8s.io
name: <authorized user name> # 用户名
也可以创建RoleBinding对与该RoleBinding相同的Namespace中的Pod进行授权,通常可以与某个系统级别的Group关联配置,例如:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: <binding name>
namespace: <binding namespace> # 该RoleBinding 所属的Namespace
roleRef:
kind: Role
name: <role name>
apiGroup: rbac.authorization.k8s.io
subjects:
# 授权该Namespace中的全部ServiceAccount
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: system:serviceaccounts
# 授权该Namespace中的全部哦用户
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: system:authenticated
Pod的安全设置详解
在系统管理员对Kubernetes集群中设置了PodSecurityPolicy策略之后,系统将对Pod和Container级别的安全设置进行校验,对于不满足PodSecurityPolicy安全策略的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相关设置。
例1: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: tomcat
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: false
在spec.securityContext中设置了如下参数。
◎ runAsUser=1000:所有容器都将以User ID 1000运行程序,所有新生成文件的User ID也被设置为1000。
◎ runAsGroup=3000:所有容器都将以Group ID 3000运行程序,所有新生成文件的Group ID也被设置为3000。
◎ fsGroup=2000:挂载的卷“/data/demo”及其中创建的文件都将属于Group ID 2000。
创建该Pod之后进入容器环境,查看到运行进程的用户ID为1000:
查看从Volume挂载到容器的/data/demo目录,其Group ID为2000
在该目录下创建一个新文件,可见其用户ID为1000,组ID为2000:
例2:Container级别的安全设置,作用于特定的容器。
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-2
spec:
securityContext:
runAsUser: 1000
containers:
- name: sec-ctx-demo-2
image: tomcat
securityContext:
runAsUser: 2000
allowPrivilegeEscalation: false
创建该Pod之后进入容器环境,查看到运行进程的用户ID为2000:
例3:为Container设置可用的Linux能力,为容器设置允许使用的Linux能力包括NET_ADMIN和SYS_TIME。
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-3
spec:
containers:
- name: sec-ctx-3
image: tomcat
securityContext:
capabilities:
add: ["NET_ADMIN","SYS_TIME"]
创建该Pod之后进入容器环境,查看1号进程的Linux能力设置:
小结:
本节内容到此结束,明天开始,开始讲解k8s的网络原理。
谢谢大家的支持!