主持人 > 博客 > 管理 > 证书管理器 1.0 发布

证书管理器 1.0 发布

如果你问一位经验丰富、睿智的工程师他对 cert-manager 的看法以及为什么每个人都使用它，那么专家会叹息，自信地拥抱他并疲倦地说：“每个人都使用它，因为没有明智的选择。 我们的老鼠会哭、会刺，但会继续与这种仙人掌共存。 我们为什么爱？ 因为它有效。 我们为什么不爱？ 因为使用新功能的新版本不断出现。 而且你必须一遍又一遍地更新集群。 旧版本停止工作，因为有一个阴谋和一个伟大的神秘萨满教。

但开发商声称 证书管理器 1.0 一切都会改变。

相信吗？

证书管理器 1.0 发布

Cert-manager 是原生的 Kubernetes 证书管理控制器。 它可用于颁发来自各种来源的证书：Let's Encrypt、HashiCorp Vault、Venafi、签名和自签名密钥对。 它还允许您在过期日期之前使密钥保持最新，并尝试在证书过期前的指定时间自动续订证书。 Cert-manager 基于 kube-lego 并且还使用了其他类似项目（例如 kube-cert-manager）的一些技巧。

发行说明

在 1.0 版中，我们为 cert-manager 项目三年的开发打上了信任的标记。 在此期间，它在功能和稳定性方面取得了显着发展，但最重要的是在社区方面。 今天，我们看到许多人使用它来保护他们的 Kubernetes 集群并将其部署到生态系统的各个部分。 在最近的 16 个版本中修复了很多错误。 而该破的就破了。 使用 API 的几次访问改进了它与用户的交互。 我们已经解决了 GitHub 上的 1500 个问题以及来自 253 个社区成员的更多拉取请求。

随着1.0的发布，我们正式宣布cert-manager是一个成熟的项目。 我们还承诺保持我们的 API 兼容 v1.

非常感谢这三年来帮助我们制作 cert-manager 的每一个人！ 让 1.0 版成为许多重大事件中的第一个。

1.0 版是一个稳定的版本，有几个优先领域：

  • v1 API；

  • 团队 kubectl cert-manager status, 帮助分析问题；

  • 使用最新稳定的 Kubernetes API；

  • 改进的日志记录；

  • ACME 改进。

升级前一定要阅读升级说明。

API v1

版本 v0.16 使用 API v1beta1. 这增加了一些结构上的变化，也改进了 API 字段文档。 版本 1.0 在此基础上使用 API v1. 这个API是我们第一个稳定的API，同时我们已经给出了兼容性保证，但是随着API v1 我们承诺在未来几年保持兼容性。

所做的更改（注意：我们的转换工具会为您处理一切）：

证书：

  • emailSANs 现在叫 emailAddresses

  • uriSANs - uris

这些更改增加了与其他 SAN 的兼容性（主题替代名称， 约译者)，以及 Go API。 我们将从我们的 API 中删除该术语。

更新

如果您使用的是 Kubernetes 1.16+，转换 webhook 将允许您同时无缝地使用 API 版本 v1alpha2, v1alpha3, v1beta1 и v1. 有了这些，您将能够使用新版本的 API，而无需更改或重新部署您的旧资源。 我们强烈建议将您的清单升级到 API v1，因为以前的版本很快就会被弃用。 用户 legacy 证书管理器的版本仍然只能访问 v1，可以找到升级步骤 这里.

kubectl 证书管理器状态命令

随着我们对扩展的新改进 kubectl 调查与未颁发证书有关的问题变得更加容易。 kubectl cert-manager status 现在提供了有关证书的更多信息，还显示了证书颁发阶段。

安装扩展后，您可以运行 kubectl cert-manager status certificate <имя-сертификата>，如果使用来自 ACME 的证书，它将查找具有给定名称的证书和任何相关资源，例如 CertificateRequest、Secret、Issuer、Order 和 Challenges。

调试尚未准备好的证书的示例：

$ kubectl cert-manager status certificate acme-certificate

Name: acme-certificate
Namespace: default
Created at: 2020-08-21T16:44:13+02:00
Conditions:
  Ready: False, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
  Issuing: True, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
DNS Names:
- example.com
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    18m   cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  18m   cert-manager  Stored new private key in temporary Secret resource "acme-certificate-tr8b2"
  Normal  Requested  18m   cert-manager  Created new CertificateRequest resource "acme-certificate-qp5dm"
Issuer:
  Name: acme-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: ACMEAccountRegistered, Message: The ACME account was registered with the ACME server
error when finding Secret "acme-tls": secrets "acme-tls" not found
Not Before: <none>
Not After: <none>
Renewal Time: <none>
CertificateRequest:
  Name: acme-certificate-qp5dm
  Namespace: default
  Conditions:
    Ready: False, Reason: Pending, Message: Waiting on certificate issuance from order default/acme-certificate-qp5dm-1319513028: "pending"
  Events:
    Type    Reason        Age   From          Message
    ----    ------        ----  ----          -------
    Normal  OrderCreated  18m   cert-manager  Created Order resource default/acme-certificate-qp5dm-1319513028
Order:
  Name: acme-certificate-qp5dm-1319513028
  State: pending, Reason:
  Authorizations:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial State: pending, Wildcard: false
Challenges:
- Name: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Key: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, State: pending, Reason: error getting clouddns service account: secret "clouddns-accoun" not found, Processing: true, Presented: false

该命令还可以帮助您详细了解证书的内容。 Letsencrypt 颁发的证书的详细示例：

$ kubectl cert-manager status certificate example
Name: example
[...]
Secret:
  Name: example
  Issuer Country: US
  Issuer Organisation: Let's Encrypt
  Issuer Common Name: Let's Encrypt Authority X3
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usages: Server Authentication, Client Authentication
  Public Key Algorithm: RSA
  Signature Algorithm: SHA256-RSA
  Subject Key ID: 65081d98a9870764590829b88c53240571997862
  Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Events:  <none>
Not Before: 2020-06-02T04:29:56+02:00
Not After: 2020-08-31T04:29:56+02:00
Renewal Time: 2020-08-01T04:29:56+02:00
[...]

使用最新稳定的 Kubernetes API

Cert-manager 是最早实施 Kubernetes CRD 的公司之一。 这一点，以及我们对 Kubernetes 1.11 版本的支持，意味着我们需要支持遗留的 apiextensions.k8s.io/v1beta1 也适用于我们的 CRD admissionregistration.k8s.io/v1beta1 对于我们的网络挂钩。 它们现在已被弃用，并将在 Kubernetes 1.22 版本中删除。 在我们的 1.0 版本中，我们现在提供全面支持 apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 对于 Kubernetes 1.16（添加它们的地方）和更新版本。 对于之前版本的用户，我们继续提供支持 v1beta1 在我们的 legacy 版本。

改进的日志记录

在此版本中，我们将日志库更新为 klog/v2，用于 Kubernetes 1.19。 我们还会审查我们撰写的每份期刊，以确保它被分配了适当的级别。 我们以此为指导 来自 Kubernetes 的指导. 有五个（实际上是六个， 约译者) 日志级别从 Error （0 级），它只打印重要错误，并以 Trace （第 5 级）这将帮助您准确了解正在发生的事情。 通过此更改，如果您在运行 cert-manager 时不需要调试信息，我们会减少日志数量。

提示：cert-manager 默认运行在 level 2 (Info), 你可以使用 global.logLevel 在头盔图中。

注意：查看日志是进行故障排除时的最后手段。 有关更多信息，请查看我们的 方向.

编者注：要了解更多关于 Kubernetes 的工作原理，从实践教师那里获得宝贵的建议，以及优质的技术支持帮助，您可以参加在线强化 Kubernetes 基地，将于 28 月 30 日至 XNUMX 日举行，以及 Kubernetes Mega将于 14 月 16 日至 XNUMX 日举行。

ACME 改进

cert-manager 最常见的用途可能与使用 ACME 从 Let's Encrypt 颁发证书有关。 1.0 版以使用社区反馈为我们的 ACME 发行者添加两个小但重要的改进而著称。

禁用帐户密钥生成

如果您大量使用 ACME 证书，您很可能在多个集群上使用同一个帐户，因此您的证书颁发限制将适用于所有这些。 在复制中指定的秘密时，这在 cert-manager 中已经是可能的 privateKeySecretRef. 这个用例有很多问题，因为 cert-manager 试图提供帮助，如果找不到的话，它会很高兴地创建一个新的帐户密钥。 这就是为什么我们添加 disableAccountKeyGeneration如果您将此选项设置为 true - cert-manager 不会生成密钥并会警告您它没有提供帐户密钥。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    privateKeySecretRef:
      name: example-issuer-account-key
    disableAccountKeyGeneration: false

优选链

29 月 XNUMX 日让我们加密 会过去 到您自己的根 CA ISRG Root. 交叉签名证书将被替换为 Identrust. 此更改不需要更改证书管理器设置，在此日期之后颁发的所有更新或新证书都将使用新的根 CA。

Let's Encrypt 已经使用此 CA 签署了证书，并通过 ACME 将它们作为“备用证书链”提供。 在此版本的证书管理器中，可以在颁发者设置中设置对这些链的访问。 在参数 preferredChain 您可以指定正在使用的 CA 的名称，证书将通过该名称颁发。 如果与请求匹配的 CA 证书可用，它将向您颁发证书。 请注意，这是首选选项，如果未找到任何内容，将颁发默认证书。 这将确保您在删除 ACME 颁发者端的备用链后仍会续订证书。

今天您已经可以收到由 ISRG Root， 所以：

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

如果你喜欢离开链条 IdenTrust - 将此选项设置为 DST Root CA X3:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "DST Root CA X3"

请注意，此根 CA 将很快被弃用，Let's Encrypt 将使此链保持活动状态，直到 29 年 2021 月 XNUMX 日。

来源： habr.com

添加评论