一、什么是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.