“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

实例演示:如何简化生产中的 Pod 安全策略?

  • 2020-05-25
  • 本文字数:6062 字

    阅读完需:约 20 分钟

实例演示:如何简化生产中的Pod安全策略?

之前的文章中,我们演示了如何使用受限的 PSP 策略作为默认值在 Rancher 中启用 PSP。我们还展示了如何防止特权 Pod 被接纳到集群中。



启用 Pod 安全策略的功能


我们有意省略了有关基于角色的访问控制(RBAC)以及如何将 Pod 与特定 PSP 连接的具体细节。那么,这篇文章让我们继续深入研究 PSP。

将 Pod 与 Pod 安全策略匹配

你可能已经注意到,PSP 模式没有与任何 Kubernetes 命名空间、Service Account 或 Pod 相关联。实际上,PSP 是集群范围的资源。那么,我们如何指定哪些 Pod 应该由哪些 PSP 来管理呢?下图显示了所有参与组件、资源以及准入流程的工作方式。



也许一开始听起来很复杂。现在,我们来详细介绍一下。


部署 Pod 时,准入控制将根据请求 deployment 的对象来应用策略。


Pod 本身没有任何关联的策略——执行该 Deployment 的是 service account。在上图中,Jorge 使用 webapp-sa service account 部署了 pod。


RoleBinding 将 service account 与 Roles(或 ClusterRoles)相关联,Role 是指定可以使用 PSP 的资源。在该图中,webapp-sa 与 webapp-role 关联,后者为特定的 PSP 资源提供使用许可。部署 Pod 时,将根据 webapp-sa PSP 对 Pod 进行检查。实际上,一个 service account 可以使用多个 PSP,并且其中一个可以验证 Pod 就足够了。你可以在官方文档中查看详细信息:


https://kubernetes.io/docs/concepts/policy/pod-security-policy/#policy-order


然后,准入控制将决定 Pod 是否符合其中任何一个 PSP。如果 Pod 符合要求,准入控制将调度 Pod;如果 Pod 不符合规定,则会阻止部署。


以上内容可以总结为以下几点:


  • Pod 身份由其 service account 确定


如果规范中未声明任何 service account,则将使用默认账户


  • 你需要允许使用声明 Role 或 ClusterRole

  • 最后,需要有一个 RoleBinding,它将 Role(从而允许访问使用 PSP)与 Pod 规范中声明的 Servcie Account 相关联。


让我们用一些例子来说明。

RBAC 的真实示例

假设你已经有一个启用了PSP的集群,这是采用 PSP 创建限制性 PSP 的常用方法,该 PSP 可以被任意 Pod 使用。然后你将添加更为特定的 PSP,该 PSP 有绑定到特定 service account 的其他特权。拥有默认、安全且严格的策略有助于集群的管理,因为大多数 Pod 不需要特殊的特权或功能,并且在默认情况下即可运行。然后,如果你的某些工作负载需要其他特权,我们可以创建一个自定义 PSP 并将该工作负载的特定 service account 绑定到限制较少的 PSP。


但是,如何将 Pod 绑定到特定的 PSP 而不是默认的受限 PSP?以及如何使用不自动添加 RoleBindings 的普通 Kubernetes 集群来做到这一点?


让我们看一个完整的示例,在该示例中,我们定义一些安全的默认值(集群中任何 service account 都可以使用的受限 PSP),然后为需要该服务的特定 deployment 向单个 service account 提供其他特权。


首先,我们手动创建一个新的命名空间。它不会由 Rancher 管理,所以不会自动创建 RoleBindings。然后我们在该命名空间中尝试部署一个受限的 Pod:


$ kubectl create ns psp-test$ cat deploy-not-privileged.yamlapiVersion: apps/v1kind: Deploymentmetadata: labels:   app: not-privileged-deploy name: not-privileged-deployspec: replicas: 1 selector:   matchLabels:     app: not-privileged-deploy template:   metadata:     labels:       app: not-privileged-deploy   spec:     containers:     - image: alpine       name: alpine       stdin: true       tty: true       securityContext:         runAsUser: 1000         runAsGroup: 1000$ kubectl -n psp-test apply -f deploy-not-privileged.yaml$ kubectl -n psp-test describe rs...  Warning  FailedCreate  4s (x12 over 15s)  replicaset-controller  Error creating: pods "not-privileged-
复制代码


由于命名空间 psp-test 中没有 RoleBinding,且该命名空间绑定到允许使用任何 PSP 的角色,因此无法创建 pod。我们将通过创建集群范围的 ClusterRole 和 ClusterRoleBinding 来解决此问题,以允许任何 Service Account 默认使用受限的 PSP。之前的文章中启用 PSP 时,Rancher 创建了受限 PSP。


  resourceNames:  - restricted-psp---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: restricted-role-bindroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: use-restricted-pspsubjects:- apiGroup: rbac.authorization.k8s.io  kind: Group  name: system:serviceaccounts$ kubectl apply -f clusterrole-use-restricted.yaml
复制代码


我们应用这些更改之后,非特权 deployment 应正常工作。


但是,如果我们需要部署特权 Pod,则不会被现有策略允许:


$ cat deploy-privileged.yamlapiVersion: v1kind: ServiceAccountmetadata:  name: privileged-sa  namespace: psp-test---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: privileged-deploy  name: privileged-deploy  namespace: psp-testspec:  replicas: 1  selector:    matchLabels:      app: privileged-deploy  template:    metadata:      labels:        app: privileged-deploy    spec:      containers:      - image: alpine        name: alpine        stdin: true        tty: true        securityContext:          privileged: true      hostPID: true      hostNetwork: true      serviceAccountName: privileged-sa
$ kubectl -n psp-test apply -f deploy-privileged.yaml$ kubectl -n psp-test describe rs privileged-deploy-7569b9969dName: privileged-deploy-7569b9969dNamespace: defaultSelector: app=privileged-deploy,pod-template-hash=7569b9969dLabels: app=privileged-deploy...Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedCreate 4s (x14 over 45s) replicaset-controller Error creating: pods "privileged-deploy-7569b9969d-" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used spec.securityContext.hostPID: Invalid value: true: Host PID is not allowed to be used spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

复制代码


在这种情况下,由于我们创建了 ClusterRoleBinding,所以 Pod 可以使用 PSP,但是 restricted-psp 不会验证 Pod,因为它需要 privileged 、hostNetwork 等参数。


我们已经在前文中看到了 restricted-psp 策略。让我们检查一下 default-psp 的细节,这是由 Rancher 在启用 PSP 允许这些特权时创建的:


$ kubectl get psp default-psp -o yaml
apiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' creationTimestamp: "2020-03-10T08:45:08Z" name: default-psp resourceVersion: "144774" selfLink: /apis/policy/v1beta1/podsecuritypolicies/default-psp uid: 1f83b803-bbee-483c-8f66-bfa65feaef56spec: allowPrivilegeEscalation: true allowedCapabilities: - '*' fsGroup: rule: RunAsAny hostIPC: true hostNetwork: true hostPID: true hostPorts: - max: 65535 min: 0 privileged: true runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - '*'
复制代码


你可以看到这是一个非常宽松的策略,特别是我们允许 privileged、hostNetwork、hostPID、hostIPC、hostPorts 以及以 root 身份运行以及其他功能。


我们只需要明确允许该 Pod 使用 PSP。我们通过创建类似于现有 restricted-clusterrole 的 ClusterRole,但允许使用 default-psp 资源,然后为我们的 psp-test 命名空间创建 RoleBinding 来将 privileged-sa ServiceAccount 绑定到该 ClusterRole:


$ cat clusterrole-use-privileged.yaml---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  name: use-privileged-psprules:- apiGroups: ['policy']  resources: ['podsecuritypolicies']  verbs:     ['use']  resourceNames:  - default-psp---  apiVersion: rbac.authorization.k8s.io/v1  kind: RoleBinding  metadata:    name: privileged-role-bind    namespace: psp-test  roleRef:    apiGroup: rbac.authorization.k8s.io    kind: ClusterRole    name: use-privileged-psp  subjects:  - kind: ServiceAccount    name: privileged-sa$ kubectl -n psp-test apply -f clusterrole-use-privileged.yaml
复制代码


一会儿之后,特权 Pod 将会被创建。然后你会注意到 restricted-psp 和 default-psp 现在已经可以直接使用。接下来,我们来详细介绍一下它们。

在 Rancher 上默认的 PSP

在 Rancher 中通过编辑集群设置来启用 PSP 准入控制,并选择其中一个已经定义好的 PSP 作为默认选项:



Rancher 将在集群中创建一对 PSP 资源:


  • restricted-psp:如果你选择“受限(restricted)”作为默认的 PSP

  • default-psp:默认的 PSP,允许创建特权 Pod。


除了 restricted-psp 和 default-psp,Rancher 还会创建名为 restricted-clusterrole 的 ClusterRole:


  annotations:    serviceaccount.cluster.cattle.io/pod-security: restricted  creationTimestamp: "2020-03-10T08:44:39Z"  labels:    cattle.io/creator: norman  name: restricted-clusterrolerules:- apiGroups:  - extensions  resourceNames:  - restricted-psp  resources:  - podsecuritypolicies  verbs:  - use
复制代码


此 ClusterRole 允许使用 restricted-psp 策略。那么 Binding 在何处才可以允许授权使用 pod ServiceAccount 呢?


对于属于 Rancher 中项目的命名空间,它还在其中为你设置 RoleBinding 配置:


$ kubectl -n default get rolebinding default-default-default-restricted-clusterrole-binding -o yamlapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  annotations:    podsecuritypolicy.rbac.user.cattle.io/psptpb-role-binding: "true"    serviceaccount.cluster.cattle.io/pod-security: restricted  labels:    cattle.io/creator: norman  name: default-default-default-restricted-clusterrole-binding  namespace: default...roleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: restricted-clusterrolesubjects:- kind: ServiceAccount  name: default  namespace: default
复制代码


资源名称(default-default-default-restricted-clusterrole-binding)可能会令人感到困惑,实际上它的构成为:


default- serviceaccountname-namespace -restricted-clusterrole-binding


并且如果你创建一个类似 myserviceaccount 的新的 service account,那么将会自动创建一个新的角色绑定:


$ kubectl create sa myserviceaccountserviceaccount/myserviceaccount created$ kubectl get rolebindingNAME                                                              AGE---default-default-default-restricted-clusterrole-binding            13mdefault-myserviceaccount-default-restricted-clusterrole-binding   4s
复制代码


借助这种神奇的功能,你无需为不需要任何提升特权的安全 pod 配置 RBAC。

在 Rancher 中创建你的 PSP

PSP 是一个标准的 Kubernetes 资源,全程是 Pod 安全策略,所以你可以通过 Kubernetes API 或 kubectl CLI 来使用它。


你可以通过在 YAML 文件中定义它们来创建你的自定义 PSP,然后使用 kubectl 在集群中创建资源。查看官方文档即可了解所有可用控件(https://kubernetes.io/docs/concepts/policy/pod-security-policy/)。在 YAML 中定义了控件集之后,你可以运行:


$ kubectl create psp my-custom-psp
复制代码


以创建 PSP 资源。


使用 Rancher,你可以从 UI 中直接查看或添加新的策略:


PSP 十分强大,但也十分复杂

配置 Pod 安全策略是一个十分乏味的过程。你在 Kubernetes 集群中启用 PSP 之后,你想要部署的任意 Pod 都必须经由其中一个 PSP 允许。实施强大的安全策略可能十分耗时,而且为每个应用程序的每个 deployment 生成一个策略也是一种负担。如果你的策略十分宽松,那么不强制执行最小特权访问方法;然而,如果它存在很多限制,你可能会破坏你的应用程序,因为 Pod 无法在 Kubernetes 中成功运行。


能够以最少的访问要求集自动生成 Pod 安全策略,将帮助你更轻松地安装 PSP。并且你不能只在生产环境中部署它们,而不验证你的应用程序是否可以正常工作,而且进行手动测试既繁琐又效率低下。如果你可以针对 Kubernetes 工作负载的运行时行为验证 PSP 呢?

如何简化生产环境中 PSP 的使用?

Kubernetes Pod 安全策略 Advisor(又名 kube-psp-advisor)是一个 Sysdig 的开源工具。kube-psp-advisor 会从 Kubernetes 资源(如 deployment、daemonset、replicaset 等)中扫描现有的安全上下文,将其作为我们想要执行的 reference 模型,然后在整个集群中为所有资源自动生成 Pod 安全策略。kube-psp-advisor 通过查看不同的属性以创建推荐的 Pod 安全策略:


  • allowPrivilegeEscalation

  • allowedCapabilities

  • allowedHostPaths

  • hostIPC

  • hostNetwork

  • hostPID

  • Privileged

  • readOnlyRootFilesystem

  • runAsUser

  • Volume


查看 kube-psp-advisor 教程,以获取有关其工作原理的更多详细信息:


https://sysdig.com/blog/enable-kubernetes-pod-security-policy/

使用 Sysdig Secure 自动生成 PSP

Sysdig Secure Kubernetes Policy Advisor 可以帮助用户创建和验证 Pod 安全策略。


第一步是设置新的 PSP 模拟环境。你可以针对不同范围内的不同策略(例如 Kubernetes 命名空间)进行多种模拟。


Sysdig 在你的 Deployment 定义中分析 Pod 规范的要求,并为你的应用程序创建权限最小的 PSP。这可以控制是否允许特权 Pod,用户将其作为容器、volume 等运行。Ni 可以微调 PSP 并针对你将要运行的模拟环境定义命名空间:



左侧的策略会破坏应用程序,因为 nginx Deployment 是特权 Pod,并且具有主机网络访问权限。你必须决定是扩大 PSP 以允许这种行为,还是选择减少 Deployment 的特权以适应该策略。无论如何,你在应用 PSP 之前都会检测到此情况,这会阻止 Pod 运行并在应用程序部署上造成破坏。

结论

如这些示例所示,通过授予或拒绝对特定资源的访问,PSP 使你可以对在 Kubernetes 中运行的 Pod 和容器进行精细控制。这些策略相对来说容易创建和部署,并且应该是任何 Kubernetes 安全策略的有用组件。


2020-05-25 16:41586

评论

发布
暂无评论
发现更多内容

三位阿里P8大牛精心整理的笔记《并发编程核心讲义》37个知识点全析,4个经典实战案例剖析,归纳总结。

Java架构师迁哥

Linux内核的进程负载均衡机制

赖猫

Linux Linux内核 linux学习

带你厘清事务一致性(中篇)

小舰

4月日更

React 学习总结

pydata

Vue 大前端 低代码 React

架构训练营模块 1 作业 - 张动动

张大彪

架构训练营

Jenkins教程:使用Jenkins进行持续集成

码语者

DevOps jenkins

自定义 Grafana Home 页面

耳东@Erdong

Grafana 4月日更

重装变态的微信

箭上有毒

生活 4月日更

智能小车系列-树莓派UPS-X750电源

波叽波叽啵😮一口盐汽水喷死你

树莓派 nodejs X750 树莓派UPS I2C

不是吧,都2021年了你还不知道有面试全真宝典这个东西吧!

Java架构师迁哥

翻译:《实用的Python编程》08_02_Logging

codists

Python

华仔架构训练营作业(模块一)

不听不听王八念晶

js数组和函数

赫鲁小夫

4月日更

面试官常考的 21 条 Linux 命令

xcbeyond

Linux 面试 4月日更

黄金圈法则 - 识别真伪需求的神器

石云升

思维模型 28天写作 职场经验 4月日更

不懂源码可以去面试?阿里P7:Spring源码解析整套笔记分享

Java架构师迁哥

Spring Boot Admin 2.1.0 全攻略

学Java关注我

Java 程序员 架构 互联网 技术宅

Javascript词法结构你懂吗?

前端树洞

JavaScript ecmascript 大前端 4月日更

Java运算符

ベ布小禅

4月日更

企业签频繁掉签,何处是出路?

风翱

ios 4月日更 企业签 超级签

微服务网关:Spring Cloud Config-配置中心

程序员架构进阶

Spring Cloud 源码解析 配置中心 28天写作 4月日更

年轻人不要老熬夜

小天同学

健康 个人感悟 4月日更 熬夜

瞬间爆炸,凭借阿里P9的Java 核心技能精讲,直接让我在三月斩获了21个offer

Java架构师迁哥

推荐一本新书《Software Design for Flexibility: How to Avoid Programming Yourself Into a Corner》

顿晓

推荐书籍 4月日更 SICP flexibility

我们帮助 IoTeX 实现万物可信互联,用区块链连接世界 | 精选案例

亚马逊云科技 (Amazon Web Services)

大神,膜拜!SpringMVC高能笔记分享,从头到尾,都是精华

Java架构师迁哥

有点东西,《阿里内部Redis学习笔记》这本笔记还融入了大量高并发系统的设计、开发及运维调优经验

Java架构师迁哥

自考答题卡识别初级解决方案,基于 Python OpenCV

梦想橡皮擦

Python OpenCV 4月日更

Let's Go 100

escray

学习 Go 语言 4月日更 Go100

微服务中台技术解析之网关(dubbo-rest)实践

小江

dubbo 架构设计 api 网关

浅论变量的作用域与变量的生存周期

Integer

c

实例演示:如何简化生产中的Pod安全策略?_文化 & 方法_Rancher_InfoQ精选文章