黄山建设网站公司电话,wap网站制作app,发免费广告电话号码,佛山企业网站设计MiniO KES#xff08;密钥加密服务#xff09;是 MinIO 开发的一项服务#xff0c;旨在弥合在 Kubernetes 中运行的应用程序与集中式密钥管理服务 #xff08;KMS#xff09; 之间的差距。中央 KMS 服务器包含所有状态信息#xff0c;而 KES 在需要执行与获取新密钥或更新… MiniO KES密钥加密服务是 MinIO 开发的一项服务旨在弥合在 Kubernetes 中运行的应用程序与集中式密钥管理服务 KMS 之间的差距。中央 KMS 服务器包含所有状态信息而 KES 在需要执行与获取新密钥或更新现有密钥相关的任何操作时与 KMS 通信。一旦它获取了密钥只要不需要更新或删除它它就会缓存在 KES 中因此后续调用会快得多。 那么为什么要使用 KES 而不是直接使用 KMS根据所使用的 KMS 及其需要处理的负载有时 KMS 系统没有能力或支持来处理大型部署在这些部署中它必须来回管理数百甚至数千个密钥而 Kubernetes 集群会给它们带来巨大的负载。在这些情况下使用 KES 至关重要因为它可以非常轻松地进行水平扩展这与传统的 KMS 系统不同。 应用程序 - KES 之间以及 KES - KMS 之间的所有 KES 操作都使用 mTLS 身份验证进行身份验证和授权功能。这是使用一对公钥/私钥和 X.509 证书完成的。证书的问题是它们有一个非常普遍的问题它们往往会过期当它们过期时周围的服务都会以几乎没有韵律或理由的方式失败。这是什么意思 我们的意思是一旦证书过期您将开始在 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_namereq_extensions req_extprompt no[req_distinguished_name]O system:nodesC USCN 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.localDNS.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/v1kind: CertificateSigningRequestmetadata: name: kes-csrspec: 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:8200CLI: export KES_SERVERhttps://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 acquiredAutomatically configured API requests per node based on available memory on the system: 221All MinIO sub-systems initialized successfully in 15.44125msMinIO Object Storage ServerCopyright: 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.localConsole: 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 恢复到拥有有效的未过期证书
