一、什么是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 资源。让我们逐条解释其中的一些关键点：
- **描述和来源：**
-
描述：该策略的目的是防止创建 `NodePort` 类型的 Service 资源。
-
作者：该策略由 Kubewarden 开发人员开发。
-
链接：提供了该策略的 GitHub 页面链接以及源代码链接。
-
许可：该策略采用 Apache-2.0 许可证。
- **注解：**
-
类别：指出该策略属于 Service 类别。
-
关键词：列出了与该策略相关的关键词。
-
显示名称：给出了该策略的显示名称。
-
严重程度：该策略的严重程度被标记为高。
-
OCI URL：提供了该策略在 OCI registry 中的 URL。
-
资源：指出该策略涉及的资源类型。
- **规则：**
-
该策略规定了针对 Service 资源的操作：
-
apiGroups：空字符串表示核心 API 组。
-
apiVersions：指定 Kubernetes API 的版本。
-
resources：指定操作的资源类型为 services。
-
operations：指定了允许的操作，即 CREATE（创建）和 UPDATE（更新）Service 资源。
- **用途：**
-
该策略的作用是检查 Service 资源的类型，并防止创建类型为 `NodePort` 的 Service。
-
对于 Kubernetes 网络策略而言，无法控制通过这种类型的 Service 暴露的内容。因此，通常更安全的选择是对创建这种类型的 Service 进行更严格的控制。
- **配置：**
- 该策略不需要任何配置值，意味着它可以直接使用而无需特定的配置。
总的来说，这个策略旨在增强 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.