kubernetes-Pod安全策略psp实践

公众号: 云原生生态圈

发布于 2021-02-26 03:04:50

1.2K00

代码可运行

文章被收录于专栏：云原生生态圈云原生生态圈

运行总次数：0

代码可运行

K8s Pod Security Policy实践

这是关于如何加固kubernetes集群安全的文章[1]。在测试环境下使用默认的users和service accounts的默认授权创建pods并没有问题，但是在生产环境下，这可能会导致不可预料的灾难。Kubernetes提供pod security policy用来限制users和service account的权限。

概览

在minikube创建的集群中实践pod security policy前，在这里我将做一些理论基础的介绍。

实验条件

读者在实践pod security policy之前必须先要对下面这些名词的概念有充分的理解：

Minikube
Namespace
Pod
Replica Set
Service Account
Cluster Role
Cluster Role Binding

Pod Securities Policy

Pod Security Policies(Adminssion Controller)授予users和service accounts创建或更新pods使用资源的权限。这是一种集群级别的资源类型，用来限制pod对敏感资源的使用。

Adminssion Controller

Addmission controller会拦截发往Kubernetes API Server调用资源的请求，验证请求调用的users和service accout是否已经授权和认证使用被调用的资源对象。例如：Admission controller会验证请求者是否拥有使用hostNetwork等kubernetes资源的权限。

Policy

对授权资源使用权限的规则定义在YAML文件中。

Policy Definition Guidelines

规则有两种：一种是限制（restrictive）使用资源的规则，另一种是允许（permission）使用资源的规则。

Pod Security Policy应该遵循以下的规范：

如果要限制user和service account使用集群中的资源，需要对相应的用户绑定限制策略
如果要允许user和service account使用集群中的资源，需要对相应的用户绑定允许策略

例子

在这部分中我们将开始在集群中实践pod security policy。

Enabling Pod Security Policy

PSP(Pod Security Policy) 在默认情况下并不会开启。通过将PodSecurityPolicy关键词添加到 --enbale-admission-plugins 配置数组后，可以开启PSP权限认证功能。

# Example
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodSecurityPolicy

注意：开启PodSecurityPolicy功能后，即使没有使用任何安全策略，都会使得创建pods（包括调度任务重新创建pods）失败

Testing

通过下面的deployment yaml文件测试在没有PSP策略的情况下是否可以创建pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4

使用下面的命令创建deployment资源：

sudo kubectl apply -f nginx-deployment.yaml

使用下面的命令检查pod是否创建：

kubectl get pods,replicasets,deployments

资源查看

通过上图可见deployments和relicaset正在运行，由于缺少PSP policy，集群并没有创建相应的pods。

Defining Policies

下面将创建两个policies，

Restrictive Policy

下面是典型的限制资源使用的restrictive policy:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrictive
spec:
  privileged: false
  hostNetwork: false
  allowPrivilegeEscalation: false
  defaultAllowPrivilegeEscalation: false
  hostPID: false
  hostIPC: false
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - 'configMap'
  - 'downwardAPI'
  - 'emptyDir'
  - 'persistentVolumeClaim'
  - 'secret'
  - 'projected'
  allowedCapabilities:
  - '*'

Permissive Policy

下面是允许使用资源的permissive policy,多条permissive policy规则被用来设置相应user或者sevice account使用相关类型的资源。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: permissive
spec:
  privileged: true
  hostNetwork: true
  hostIPC: true
  hostPID: true
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  hostPorts:
  - min: 0
    max: 65535
  volumes:
  - '*'

上面两种poicies可以使用下面的命令创建对应的PSP资源：

kubectl apply -f default-restrict-psp.yaml

kubectl apply -f permissive-psp.yaml

核对psp是否创建成功与否：

sudo kubectl get psp

查看psp

下面将通过cluster role和cluster role binding在集群中使用刚才定义的安全策略(Pod Security Policy)。

Cluster Role

关于restrictive policy的restrictive cluster role

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-restrictive
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - restrictive
  verbs:
  - use

关于permissive policy的permissive cluster role

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-permissive
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - permissive
  verbs:
  - use

通过下面命令创建相应的cluster role资源：

kubectl apply -f psp-restrictive-cluster-roleyaml

kubectl apply -f psp-permissive-cluster-roleyaml

Cluster Role Bindings

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-default
subjects:
- kind: Group
  name: system:serviceaccounts
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: psp-restrictive
  apiGroup: rbac.authorization.k8s.io

上面的role binding会将restrictive cluster role绑定到所有的system service account。

使用下面的命令生成role binding资源：

kubectl apply -f psp-restrictive-cluster-role-binding.yaml

Testing

已经定义了restrictive policy并且将对应的psp绑定到对应的service account，我将通过重新生成开篇的deployment资源来验证pods是否可以创建。

首先，删除已经存在的deployment资源。

kubectl delete deploy nginx-deployment

kubectl get po,rs,deploy

资源查看

重新创建deployment：

kubectl apply -f nginx-deployment.yaml

kubectl get po,rs,deploy

资源查看

注意：通过图可见在policies创建后，可以创建pod资源。

Breaking Policy Rules

在这部分，我将在deployment中使用已经在restrictive policy中禁止的“hostNetwork”。

首先，清楚前面创建的deployment资源。

kubectl delete deploy ninx-deployment

kubectl get po.rs,deploy

img

使用下面的命令和yaml文件重新创建相应资源:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hostnetwork-deployment
  namespace: kube-system
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
      hostNetwork: true

kubectl apply -f   nginx-host-network-deployment.yaml

kubectl get po,rs,deploy

可见replica set controller并没有创建相对应的pod，原因如下：

Warning FailedCreate 2m38s (x17 over 8m5s) replicaset-controller Error creating: pods "nginx-hostnetwork-deployment-fd75d78b-" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used]

注意：

上面的错误显示在创建deployment时试图获取已经被限制的资源，k8s集群不允许这样的行为。

Creating deployment with privileged access

在这部分，我将通过对一些controllers(deamon-set-controller,replicaset-controller,job-controller)的调用user和service account授予一些特殊权限。

首先，我先创建role binding。

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: psp-permissive
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp-permissive
subjects:
- kind: ServiceAccount
  name: daemon-set-controller
  namespace: kube-system
- kind: ServiceAccount
  name: replicaset-controller
  namespace: kube-system
- kind: ServiceAccount
  name: job-controller
  namespace: kube-system

使用以下命令创建role binding：

kubectl apply -f psp-permissive-cluster-role-binding.yaml

接下来我将重新创建deployment并在pod中使用被restrictive policy限制使用的资源。当前deployment与前面deployment的区别在于现在在kube-system命名空间中创建deployment，以前则是在default命名空间中，这主要是由于刚刚对kube-system授予permissive policy权限。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hostnetwork-deployment
  namespace: kube-system
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
      hostNetwork: true

使用下面命令，重新创建deployment资源：

kubectl apply -f nginx-host-network-deployment-kube-system.yaml

使用下面命令，验证pod是否正常运行：

kubectl get po,rs,deploy -n kube-system | grep hostnetwork

注意：由于已经对kube-system命名空间的user和service account授权使用hostNetwork，可见nginx-hostnetwork-deployment pod已经部署在kube-system命名空间。

总结

上面的内容演示了如何通过使用PSP授权使用特殊资源，在k8s集群中实现Pod Security Policy安全策略。

参考资料

[1]

参考掘金: https://juejin.cn/post/6844903910344228878

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2021-02-18，如有侵权请联系 cloudcommunity@tencent.com 删除

tcp/ip

kubernetes

本文分享自云原生生态圈微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

tcp/ip

kubernetes

登录后参与评论

0 条评论

热度