上节课,我们发现配置清单仓库中secret
默认采用base64
加密,非常容易逆向解密。本期视频,我们来解决部署清单仓库中secret
数据加密的问题。
ArgoCD
官方推荐了差不多十种解决方案,同时也提醒说,没有一种是可以解决所有问题的。既然都不完美,那咱们就瘸子里挑将军,找个相对好的研究研究。
sealed secrets
是 bitnami
实验室推出的Secrets
单向加密工具。它被设计为两部分,一部分作为kubernetes
资源控制器,运行在kubernetes
集群中,该控制器始终监控 SealedSecret
这个资源类型,并将它解密为Kubernetes
可以识别的Secret
;另外一部分被设计为客户端工具,由用户操作将Secret
类型加密为SealedSecret
类型。
$ kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.16.0/controller.yaml
默认会在 kube-system 命名空间下创建 sealed-secrets-controller
控制器,当控制器启动时,会自动检查当前命名空间下是否有存在解密 SealedSecrets 的私钥对;如果没有则自动创建,同时把公钥打印在控制器的日志中。
# Mac OSX
brew install kubeseal
# Linux
wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.10.0/kubeseal-linux-amd64 -O kubeseal
虽然我们可以从 sealed-secrets-controller
的日志中获取自动生成的公钥信息,但复制时经常会出现格式错误。可以通过如下命令,在服务器端获取公钥信息,再通过 lrzsz 等工具拷贝到本地;
# kubeseal 自动连接 k8s 集群获取公钥
kubeseal --fetch-cert > public-cert.pem
通过如下命令讲Secret
类型加密为 SealedSecret 类型。
# 可以写到 Makefile 中供快捷使用
kubeseal --format=yaml --cert .public-cert.pem < secret.yaml > secret-sealed.yaml
此时,Secret
类型的配置清单就不需要啦,直接把SealedSecret
类型的配置清单提交到仓库中,ArgoCD
将其应用到kubernates
中,最终由 sealed-secrets-controller
控制器把配置解密为 Secret
类型的资源。
Secret
类型的配置清单已经不需要啦,但不建议删除。因为 sealed secrets
想要解密SealedSerects
类型的文件,所需的私钥还在kubernates
集群中,保密程度更高,不方便共享给开发团队。建议使用如下方式解决:
secret
文件到 .gitignore
中,防止误提交;public-cert.pem
公钥非常重要,务必谨慎保存。# 导出私钥并保存到安全位置
kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml >master.key
# 保存公钥并保存到安全位置
kubeseal --fetch-cert > public-cert.pem
当集群从灾难中恢复时,可以导入私钥,并重新创建 sealed-secrets-controller
控制器。
kubectl apply -f master.key
kubectl delete pod -n kube-system -l name=sealed-secrets-controller
到这里,我们总算对Secret
有个相对不错的处理方案,不过如各位所见,仍然有其瑕疵。官方还推荐了其他方案,感兴趣的同学可以自行研究研究,欢迎大家把研究结果共享,让更多的人少走弯路。
下期视频,咱们来聊聊多集群管理的问题。
sealed secrets[1]
[1]
sealed secrets: https://aws.amazon.com/cn/blogs/china/managing-secrets-deployment-in-kubernetes-using-sealed-secrets/?nc1=b_nrp