![alt](https://img-blog.csdnimg.cn/img_convert/7f21ece889da6140b721635f4e408b1f.png)
MiniO KES(密钥加密服务)是 MinIO 开发的一项服务,旨在弥合在 Kubernetes 中运行的应用程序与集中式密钥管理服务 (KMS) 之间的差距。中央 KMS 服务器包含所有状态信息,而 KES 在需要执行与获取新密钥或更新现有密钥相关的任何操作时与 KMS 通信。一旦它获取了密钥,只要不需要更新或删除它,它就会缓存在 KES 中,因此后续调用会快得多。
那么,为什么要使用 KES 而不是直接使用 KMS?根据所使用的 KMS 及其需要处理的负载,有时 KMS 系统没有能力或支持来处理大型部署,在这些部署中,它必须来回管理数百甚至数千个密钥,而 Kubernetes 集群会给它们带来巨大的负载。在这些情况下,使用 KES 至关重要,因为它可以非常轻松地进行水平扩展,这与传统的 KMS 系统不同。
![alt](https://img-blog.csdnimg.cn/img_convert/f956615cb3c41866bb65ca65f92cf3fd.png)
应用程序 <-> KES 之间以及 KES <-> KMS 之间的所有 KES 操作都使用 mTLS 身份验证进行身份验证和授权功能。这是使用一对公钥/私钥和 X.509 证书完成的。证书的问题是它们有一个非常普遍的问题,它们往往会过期,当它们过期时,周围的服务都会以几乎没有韵律或理由的方式失败。这是什么意思?
![alt](https://img-blog.csdnimg.cn/img_convert/3b9e947477ea84d9207ae016baf9f626.png)
我们的意思是,一旦证书过期,您将开始在 KES 日志中看到此类错误
{"message":"2024/01/04 02:23:21 http: TLS handshake error from 10.244.2.9:32816: remote error: tls: bad certificate"}
{"message":"2024/01/04 02:23:28 http: TLS handshake error from 10.244.3.11:53456: remote error: tls: bad certificate"}
{"message":"2024/01/04 02:23:28 http: TLS handshake error from 10.244.1.9:56722: remote error: tls: bad certificate"}
{"message":"2024/01/04 02:23:28 http: TLS handshake error from 10.244.4.11:34152: remote error: tls: bad certificate"}
{"message":"2024/01/04 02:23:28 http: TLS handshake error from 10.244.2.9:55300: remote error: tls: bad certificate"}
{"message":"2024/01/04 02:23:28 http: TLS handshake error from 10.244.4.11:34160: remote error: tls: bad certificate"}
此外,当 MinIO 尝试执行定期 IAM 刷新时,这些刷新也会失败,并在 MinIO 日志中显示以下消息
Error: Failure in periodic refresh for IAM (took 0.03s): Post "https://kes-tenant-kes-hl-svc.default.svc.cluster.local:7373/v1/key/decrypt/my-minio-key": x509: certificate has expired or is not yet valid: current time 2024-01-04T02:27:31Z is after 2024-01-04T02:12:40Z (*errors.errorString)
如果幸运的话,您会看到一条明显的消息,例如 certificate has expired
.其他时候,它并不那么明显,在尝试创建或删除密钥时,您还可能会看到边缘情况问题以及许多其他问题。最快的解决方案是尽快使用新证书续订和更新 KES。在这篇文章中,我们将向您展示如何做到这一点。
如何续费
让我们首先创建一个新的私钥
openssl genrsa -out private.key 2048
创建一个名为 cert.cnf
的文件,该文件将用于 openssl
创建证书签名请求 (CSR)
[req]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[req_distinguished_name]
O = "system:nodes"
C = US
CN = "system:node:*.kes-tenant-kes-hl-svc.default.svc.cluster.local"
[req_ext]
subjectAltName = @alt_names
[alt_names]
DNS.1 = kes-tenant-kes-0.kes-tenant-kes-hl-svc.default.svc.cluster.local
DNS.2 = kes-tenant-kes-hl-svc.default.svc.cluster.local
请务必修改 Common Name CN 和 Subject Alternative Names SAN (在 下 [alt_names] ),以匹配 KES 节点的 FQDN。请务必使用正确的 FQDN,而不是 IP 地址。
使用以下命令创建 CSR
openssl req -new -config cert.cnf -key private.key -out kes.csr
将 CSR 转换为编码字符串,以便将其作为 CertificateSigningRequest 资源添加到 Kubernetes。
cat kes.csr | base64 | tr -d "\n"
使用以下内容创建一个文件 kes-csr.yaml ,并将上述编码的 CSR 粘贴到 request 字段中。证书已被截断,因此您可以看到整个 yaml。
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: kes-csr
spec:
expirationSeconds: 604800
groups:
- system:serviceaccounts
- system:serviceaccounts:minio-operator
- system:authenticated
- system:nodes
request: LS0tLS1CRUdJTiBDRV…FUVVFU1QtLS0tLQo=
signerName: kubernetes.io/kubelet-serving
usages:
- digital signature
- key encipherment
- server auth
username: system:serviceaccount:minio-operator:minio-operator
添加编码的 CSR 并设置其他设置后,应用 yaml。
kubectl apply -f kes-csr.yaml
请务必批准上面创建的 kes-csr CSR
kubectl certificate approve kes-csr
从 csr
资源获取公共证书
kubectl get csr kes-csr -o jsonpath='{.status.certificate}'| base64 -d > public.crt
将(从过程开始)和 private.key public.crt (从上一步开始)转换为编码字符串。
cat private.key | base64 | tr -d "\n"
cat public.crt | base64 | tr -d "\n"
使用上面的编码字符串,我们将更新现有的 Secret
kes-tenant-kes-tls
,为此,请按照以下步骤操作。
复制现有过期证书所在的现有密钥。
kubectl get secret kes-tenant-kes-tls -o yaml > kes-tls-secret.yaml
备份现有密钥后,将其删除
kubectl delete secret kes-tenant-kes-tls
使用过期的证书打开 kes-tls-secret.yaml
,并将以下两个字段替换为其各自的 base64 编码字符串。
data:
private.key: >-
LS0tLS1CRUd…ZLS0tLS0
public.crt: >-
LS0tLS1CRUdJTi…tLS0K
添加新证书后,应用 , Secret
这将重新创建 kes-tenant-kes-tls
kubectl apply -f kes-tls-secret.yaml
添加有效证书后,请务必重启 KES 服务,应看到如下所示的输出:
'http://vault.default.svc.cluster.local:8200' ...
Endpoint: https://127.0.0.1:7373 https://10.244.4.16:7373
Admin: _ [ disabled ]
Auth: off [ any client can connect but policies still apply ]
Keys: Hashicorp Vault: http://vault.default.svc.cluster.local:8200
CLI: export KES_SERVER=https://127.0.0.1:7373
export KES_CLIENT_KEY= // e.g. $HOME/root.key
export KES_CLIENT_CERT= // e.g. $HOME/root.cert
kes --help
MinIO 日志也应该是干净的,不应再显示任何 TLS 错误。
Waiting for all MinIO sub-systems to be initialized.. lock acquired
Automatically configured API requests per node based on available memory on the system: 221
All MinIO sub-systems initialized successfully in 15.44125ms
MinIO Object Storage Server
Copyright: 2015-2024 MinIO, Inc.
License: GNU AGPLv3
Version: RELEASE.2024-01-04T09-40-09Z (go1.19.4 linux/arm64)
Status: 4 Online, 0 Offline.
API: https://minio.default.svc.cluster.local
Console: https://10.244.3.12:9443 https://127.0.0.1:9443
Documentation: https://min.io/docs/minio/linux/index.html
最后的思考
在管理用于加密对象的密钥时,KES 是一个不可或缺的部分。以最快的方式对对象进行加密和解密非常重要,因为执行这些操作所需的每纳秒,最终用户获取对象的速度就会慢得多。是的,最终,低效和缓慢的 KMS 系统会降低集群的整体性能。因此,确保执行这些操作的服务快速、精简、高性能和可扩展至关重要。MinIO 的 KES 使任何 KMS 都成为高性能和可扩展的服务,而无需对现有 KMS 进行任何修改。按照上述步骤操作,您可以立即让 KES 恢复到拥有有效的未过期证书!