🥇Cert-manager 1.0 がリリースされました

経験豊富で賢明なエンジニアに、cert-manager についてどう思うか、なぜみんながそれを使っているのか尋ねると、その専門家はため息をつき、自信満々に彼を抱きしめ、疲れた様子でこう言うでしょう。私たちのネズミは鳴いたり、刺したりしながらも、このサボテンとともに生き続けます。なぜ私たちは愛するのでしょうか？効果があるからです。なぜ私たちは愛さないのですか？新しい機能を使用する新しいバージョンが常に登場するためです。また、クラスターを何度も更新する必要があります。そして、陰謀と偉大な神秘的なシャーマニズムがあるため、古いバージョンは機能しなくなります。

しかし、開発者は次のように主張しています 証明書マネージャー 1.0 すべてが変わります。

信じられますか？

Cert-manager は、ネイティブの Kubernetes 証明書管理コントローラーです。これを使用して、Let's Encrypt、HashiCorp Vault、Venafi、署名キーペア、自己署名キーペアなど、さまざまなソースから証明書を発行できます。また、有効期限までにキーを最新の状態に保つことができ、有効期限が切れる前の指定された時間に証明書を自動的に更新しようとします。 Cert-manager は kube-lego に基づいており、kube-cert-manager などの他の同様のプロジェクトのいくつかのトリックも使用しています。

リリースノート

バージョン 1.0 では、16 年間の cert-manager プロジェクトの開発に対する信頼の印が付けられました。この間、機能と安定性が大幅に進化しましたが、最も重要なのはコミュニティです。現在、多くの人々が Kubernetes クラスターを保護するためにこれを使用しているだけでなく、エコシステムのさまざまな部分にデプロイしているのを目にします。過去 1500 回のリリースで多くのバグが修正されました。そして壊すべきものは壊れた。 API を使用するために何度かアクセスすることで、ユーザーとの対話が改善されました。 253 人のコミュニティメンバーからの追加のプルリクエストにより、GitHub 上の XNUMX 件の問題を解決しました。

1.0 のリリースにより、cert-manager が成熟したプロジェクトであることを正式に宣言します。また、API の互換性を維持することも約束します v1.

この 1.0 年間、cert-manager の作成に協力してくれた皆さんに感謝します。バージョン XNUMX を、これから起こる多くの大きなことの最初のものにしましょう。

リリース 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 cert-manager のバージョンは引き続きアクセス権のみを持ちます。 v1、アップグレード手順が見つかります。ここで.

kubectl cert-manager ステータスコマンド

拡張機能の新たな改善により、 kubectl 証明書の不発行に伴う問題の調査が容易になりました。 kubectl cert-manager status 証明書で何が起こっているのかについてさらに多くの情報が提供され、証明書の発行段階も表示されるようになりました。

拡張機能をインストールした後、実行できます kubectl cert-manager status certificate <имя-сертификата>これにより、指定された名前の証明書と、ACME の証明書を使用している場合は CertificateRequest、Secret、Issuer、Order and 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
[...]

ログ記録の改善

このリリースでは、ロギングライブラリを次のように更新しました。 klog/v2、Kubernetes 1.19 で使用されます。また、執筆する各ジャーナルをレビューして、適切なレベルが割り当てられていることを確認します。私たちはこれに導かれました Kubernetes からのガイダンス。 XNUMXつあります（実際にはXNUMXつですが、 約。翻訳者) から始まるログレベル Error (レベル 0)、重要なエラーのみを出力し、次で終わります。 Trace (レベル 5) 何が起こっているかを正確に知るのに役立ちます。この変更により、cert-manager の実行時にデバッグ情報が必要ない場合のログの数が減りました。

ヒント: cert-manager はデフォルトでレベル 2 で実行されます (Info)、次を使用してこれをオーバーライドできます global.logLevel ヘルムチャートで。

注: ログの表示は、トラブルシューティングの最後の手段です。詳細については、こちらをご覧くださいリーダーシップ.

編集者注記: Kubernetes の内部ですべてがどのように機能するかについて詳しく学び、実践的な教師から貴重なアドバイスや質の高い技術サポートを得るには、オンライン集中講義に参加できます。 Kubernetes ベース、28月30日からXNUMX日まで開催されます。 Kubernetes メガ14月16日からXNUMX日まで開催されます。

ACMEの改善

cert-manager の最も一般的な使用法は、おそらく ACME を使用した Let's Encrypt からの証明書の発行に関連したものです。バージョン 1.0 は、コミュニティからのフィードバックを利用して、ACME 発行者に XNUMX つの小さいながらも重要な改善を加えたことで注目に値します。

アカウントキーの生成を無効にする

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。この変更には、cert-manager 設定を変更する必要はありません。この日以降に発行されたすべての更新された証明書または新しい証明書は、新しいルート CA を使用します。

Let's Encrypt はすでにこの CA で証明書に署名しており、それらを ACME 経由で「代替証明書チェーン」として提供しています。このバージョンの cert-manager では、発行者の設定でこれらのチェーンへのアクセスを設定できます。パラメータ内 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

cert-manager 1.0 がリリースされました

リリースノート

API v1

アップデート

kubectl cert-manager ステータスコマンド

最新の安定した Kubernetes API の使用

ログ記録の改善

ACMEの改善

アカウントキーの生成を無効にする

優先チェーン

コメントを追加します返信をキャンセル

cert-manager 1.0 がリリースされました

リリースノート

API v1

アップデート

kubectl cert-manager ステータス コマンド

最新の安定した Kubernetes API の使用

ログ記録の改善

ACMEの改善

アカウントキーの生成を無効にする

優先チェーン

コメントを追加します 返信をキャンセル

kubectl cert-manager ステータスコマンド

コメントを追加します返信をキャンセル