Rancher-Kubewarden-保姆级教学-含Demo测试

一、什么是Kubewarden？

What is Kubewarden? | Kubewarden

        1、就是容器集群的准入策略引擎。

                1、使用的策略其实就是k8s原生的security context.

        2、使用WebAssembly来编写策略。

                1、WebAssembly，可以使用擅长的开发语言来编写策略。（下面的Demo）

                2、支持写的语言参考：I want to… - WebAssembly

        3、编写WebAssembly可以集成在CI/CD的管道中。

二、Kubewarden的安全策略怎么写？

        1、首先这个集群的安全交给开发来管，怕是不现实，而我们运维人员最最常用的语言几乎都是Python，那么来写这个安全策略呢？

        2、Kubewarden官网有一个ctl工具来帮助生成和管理策略。

kwctl

GitHub - kubewarden/kwctl: Go-to CLI tool for Kubewarden users

        3、编写策略的首选语言是（开发人员自己写）

rust

Install Rust - Rust Programming Language

 三、Kubewarden的重要组件

                1、kubewarden-controller

        它与k8s集群的api-server通信，并会监视api-server执行pod “create update ”等动作时，把执行的行为交给policy-server评估，是否符合我们策略的要求。policy-server会返回符合或者不符合。

                2、policy-server

        负责具体的策略评估，并且支持一个集群部署多个policy-server。

                3、ClusterAdmissionPolicy or AdmissionPolicy

        具体的策略，顾名思义一个是集群级别的一个是命名空间级别的。

四、Demo演示

        1、下载kwctl

wget -o https://github.com/kubewarden/kwctl/releases/download/v1.12.0/kwctl-linux-x86_64.zip

        *这是 x86平台的，其余平台请参考项目的Releases · kubewarden/kwctl · GitHub。 

        2、改名并传递到环境遍历的路径下

mv kwctl-linux-x86_64 kwctl
chmod +x kwctl
cp kwctl /usr/bin

        3、安装Kubewarden

                1、前提

                        1、有helm

                        2、有cert-manager

                2、安装

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.5.3/cert-manager.yaml
$ helm repo add kubewarden https://charts.kubewarden.io
$ helm install --create-namespace -n kubewarden kubewarden-crds kubewarden/kubewarden-crds
$ helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller
$ helm install --wait -n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults

           3、验证

        4、官网有一个测试的策略也可以自己来玩。

kubectl apply -f - <<EOF
---
apiVersion: policies.kubewarden.io/v1alpha2
kind: ClusterAdmissionPolicy
metadata:
  name: privileged-pods
spec:
  policyServer: default
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.1.9
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
        - CREATE
        - UPDATE
  mutating: false
EOF

*就是不允许创建特权容器的策略。

        5、那么作为运维人员怎么找合适的策略呢？

https://artifacthub.io/packages/search?kind=13&sort=relevance&page=1

*这个页面有很多官网写好的策略可以直接使用。

例如：

*不允许创建service 类型为NodePort。

        2、怎么下载？

                1、还记得我们下载安装的kwctl工具吗？现在就可以用了。         

                2、使用kwctl 拉取策略

验证：

kwctl policies

 检查你拉去策略，是否符合你的想法：

kwctl inspect registry://ghcr.io/kubewarden/policies/disallow-service-nodeport:v0.1.7

因为是要部署到环境中的，我们使用Chart-Gpt逐行来解释：

这条规则是一个 Kubernetes 策略，名为 "disallow-service-nodeport"。它的作用是防止创建类型为 `NodePort` 的 Service 资源。让我们逐条解释其中的一些关键点：

1. **描述和来源：**
   - 描述：该策略的目的是防止创建 `NodePort` 类型的 Service 资源。
   - 作者：该策略由 Kubewarden 开发人员开发。
   - 链接：提供了该策略的 GitHub 页面链接以及源代码链接。
   - 许可：该策略采用 Apache-2.0 许可证。

2. **注解：**
   - 类别：指出该策略属于 Service 类别。
   - 关键词：列出了与该策略相关的关键词。
   - 显示名称：给出了该策略的显示名称。
   - 严重程度：该策略的严重程度被标记为高。
   - OCI URL：提供了该策略在 OCI registry 中的 URL。
   - 资源：指出该策略涉及的资源类型。

3. **规则：**
   - 该策略规定了针对 Service 资源的操作：
     - apiGroups：空字符串表示核心 API 组。
     - apiVersions：指定 Kubernetes API 的版本。
     - resources：指定操作的资源类型为 services。
     - operations：指定了允许的操作，即 CREATE（创建）和 UPDATE（更新）Service 资源。

4. **用途：**
   - 该策略的作用是检查 Service 资源的类型，并防止创建类型为 `NodePort` 的 Service。
   - 对于 Kubernetes 网络策略而言，无法控制通过这种类型的 Service 暴露的内容。因此，通常更安全的选择是对创建这种类型的 Service 进行更严格的控制。

5. **配置：**
   - 该策略不需要任何配置值，意味着它可以直接使用而无需特定的配置。

总的来说，这个策略旨在增强 Kubernetes 的安全性，通过阻止创建 `NodePort` 类型的 Service，从而避免了潜在的安全风险。

*那么现在很清晰了，但你要创建、更新service资源的时候不允许type 为 NodePort.

        3、上面是作者的策略自述，我们部署到生产或者测试环境，是肯定要先评估测试的。接下来我们进行Demo评估.

                1、评估命令格式： 

命令：kwctl run -r <"Kubernetes Admission request" file path> -s <"JSON document" file path> <policy URI>

kwctl run registry://ghcr.io/kubewarden/policies/disallow-service-nodeport:v0.1.7 -r disallow-service-nodeport.json

        *-r ：disallow-service-nodeport.json 

解释一下：1、你的规则是创建或者更新 service的时候不允许类型为NodePort.

                   2、那么你就要模拟你创建的动作为创建NodePort的service的准入动作。

kube-apiserver Admission (v1) | Kubernetes

                        *上面为参考文档，了解即可，具体的json文件可以用Chart-Gpt生成。

                3、下面为我们测试的json例子,保存为disallow-service-nodeport.json.

{
  "kind": "AdmissionReview",
  "apiVersion": "admission.k8s.io/v1",
  "request": {
    "uid": "12345678-1234-1234-1234-1234567890ab",
    "kind": {
      "group": "",
      "version": "v1",
      "kind": "Service"
    },
    "resource": {
      "group": "",
      "version": "v1",
      "resource": "services"
    },
    "namespace": "default",
    "operation": "CREATE",
    "userInfo": {
      "username": "user",
      "groups": ["system:masters"]
    },
    "object": {
      "kind": "Service",
      "apiVersion": "v1",
      "metadata": {
        "name": "my-service",
        "namespace": "default"
      },
      "spec": {
        "type": "NodePort",
        "ports": [
          {
            "port": 80,
            "targetPort": 80,
            "protocol": "TCP"
          }
        ]
      }
    },
    "oldObject": null
  }
}

        4、测试

rke2-01:~/rust # kwctl run registry://ghcr.io/kubewarden/policies/disallow-service-nodeport:v0.1.7 -r disallow-service-nodeport.json
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
{"uid":"12345678-1234-1234-1234-1234567890ab","allowed":false,"status":{"message":"Service of type NodePort are not allowed"},"auditAnnotations":null,"warnings":null}

*策略给拦截了，因为我们创建的是一个类型为NodePort的Service。

*接下来我们把这条规则部署到k8s集群中测试。

        5、编写 ClusterAdmissionPolicy or AdmissionPolicy ，我们使用AdmissionPolicy在default命名空间下测试。

vim no_Node_Port_svc.yaml

*不写policy_server字段默认为 default. 的policy-server. 

apiVersion: policies.kubewarden.io/v1alpha2
kind: AdmissionPolicy
metadata:
  name: privileged-pods
  namespace: default
spec:
  module: "registry://ghcr.io/kubewarden/policies/disallow-service-nodeport:v0.1.7"
  settings: {}
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - services
      operations:
        - CREATE
        - UPDATE
  mutating: false

部署策略。 

kubectl apply -f no_Node_Port_svc.yaml

查看验证：
 

kubectl get admissionpolicy -A

*状态为active则生效，下面开始测试。

        5、测试yaml,在default空间下，类型为NodePort

vim demo_svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
  namespace: default
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30000  # NodePort的端口号
  type: NodePort

 部署测试：

kubectl apply -f demo_svc.yaml

 被策略阻止了，测试成功。

清理： 

kubectl delete -f no_Node_Port_svc.yaml

kubectl get admissionpolicy -A

rke2-01:~/rust # kubectl delete -f no_Node_Port_svc.yaml
admissionpolicy.policies.kubewarden.io "privileged-pods" deleted
rke2-01:~/rust # kubectl get admissionpolicy -A
No resources found

 清理完毕后就可以创建了，确认为策略阻止了：

总结：

        1、Rancher的项目依旧能打。

        2、对于不想在pod中写security context的运维同行是福音。

        3、控制器和policy-server 分离部署，方便扩展好评。

        4、运维人员写不了策略差评，希望后期能给个python的sdk.