Nếu bạn hỏi một kỹ sư khôn ngoan, giàu kinh nghiệm rằng anh ta nghĩ gì về trình quản lý chứng chỉ và tại sao mọi người lại sử dụng nó, chuyên gia sẽ thở dài, ôm anh ta một cách tâm sự và mệt mỏi nói: “Mọi người đều sử dụng nó, vì không có lựa chọn thay thế lành mạnh nào. Những con chuột của chúng tôi kêu gào, tự chích mình nhưng vẫn tiếp tục sống với cây xương rồng này. Tại sao chúng ta yêu? Bởi vì nó hoạt động. Tại sao chúng ta không yêu? Bởi vì các phiên bản mới liên tục được ra mắt sử dụng những tính năng mới. Và bạn phải cập nhật cụm nhiều lần. Và các phiên bản cũ ngừng hoạt động vì có một âm mưu và một tà giáo bí ẩn lớn lao.”
Nhưng các nhà phát triển khẳng định rằng với trình quản lý chứng chỉ 1.0 Mọi thứ sẽ thay đổi.
Chúng ta sẽ tin chứ?
Trình quản lý chứng chỉ là bộ điều khiển quản lý chứng chỉ Kubernetes gốc. Nó có thể được sử dụng để cấp chứng chỉ từ nhiều nguồn khác nhau: Let's Encrypt, HashiCorp Vault, Venafi, các cặp khóa ký và tự ký. Nó cũng cho phép bạn cập nhật khóa và cố gắng tự động gia hạn chứng chỉ vào một thời điểm nhất định trước khi chúng hết hạn. Trình quản lý chứng chỉ dựa trên kube-lego và cũng sử dụng một số kỹ thuật từ các dự án tương tự khác, chẳng hạn như kube-cert-manager.
Ghi chú phát hành
Với phiên bản 1.0, chúng tôi đặt dấu ấn niềm tin vào ba năm phát triển của dự án người quản lý chứng chỉ. Trong thời gian này, nó đã phát triển đáng kể về chức năng và tính ổn định, nhưng trên hết là trong cộng đồng. Ngày nay, chúng tôi thấy nhiều người sử dụng nó để bảo mật cụm Kubernetes của họ, cũng như triển khai nó vào nhiều phần khác nhau của hệ sinh thái. Một loạt lỗi đã được sửa trong 16 bản phát hành gần đây nhất. Và những gì đáng lẽ phải bị phá vỡ đã bị phá vỡ. Một số lượt truy cập vào API đã cải thiện khả năng tương tác của nó với người dùng. Chúng tôi đã giải quyết được 1500 vấn đề trên GitHub, thậm chí còn có nhiều yêu cầu kéo hơn từ 253 thành viên cộng đồng.
Bằng việc phát hành phiên bản 1.0, chúng tôi chính thức tuyên bố rằng trình quản lý chứng chỉ là một dự án trưởng thành. Chúng tôi cũng hứa sẽ giữ cho API của chúng tôi tương thích v1.
Xin chân thành cảm ơn tất cả những người đã giúp chúng tôi tạo ra trình quản lý chứng chỉ trong suốt ba năm qua! Hãy để phiên bản 1.0 là phiên bản đầu tiên trong số nhiều điều tuyệt vời sắp tới.
Phiên bản 1.0 là phiên bản ổn định với một số lĩnh vực ưu tiên:
v1CHÁY;Đội
kubectl cert-manager status, để giúp phân tích vấn đề;Sử dụng API Kubernetes ổn định mới nhất;
Cải thiện việc ghi nhật ký;
Cải tiến ACME.
Hãy chắc chắn đọc ghi chú cập nhật trước khi nâng cấp.
API v1
Phiên bản v0.16 hoạt động với API v1beta1. Điều này đã bổ sung một số thay đổi về cấu trúc và cũng cải thiện tài liệu trường API. Phiên bản 1.0 được xây dựng dựa trên tất cả điều này với API v1. API này là API ổn định đầu tiên của chúng tôi, đồng thời chúng tôi đã đưa ra các đảm bảo về khả năng tương thích, nhưng với API v1 Chúng tôi hứa sẽ duy trì khả năng tương thích trong nhiều năm tới.
Những thay đổi đã thực hiện (lưu ý: các công cụ chuyển đổi của chúng tôi sẽ đảm nhiệm mọi việc cho bạn):
Giấy chứng nhận:
emailSANsđang gọiemailAddressesuriSANs-uris
Những thay đổi này bổ sung khả năng tương thích với các SAN khác (tên thay thế chủ đề, khoảng người phiên dịch), cũng như với API Go. Chúng tôi đang xóa thuật ngữ này khỏi API của mình.
Cập nhật
Nếu bạn đang sử dụng Kubernetes 1.16+ - webhook chuyển đổi sẽ cho phép bạn làm việc đồng thời và liền mạch với các phiên bản API v1alpha2, v1alpha3, v1beta1 и v1. Với chúng, bạn có thể sử dụng phiên bản API mới mà không cần thay đổi hoặc triển khai lại tài nguyên cũ của mình. Chúng tôi thực sự khuyên bạn nên nâng cấp tệp kê khai của mình lên API v1, vì các phiên bản trước đó sẽ sớm không còn được dùng nữa. Người dùng legacy phiên bản của trình quản lý chứng chỉ sẽ vẫn chỉ có quyền truy cập vào v1, có thể tìm thấy các bước cập nhật .
lệnh trạng thái kubectl cert-manager
Với những cải tiến mới trong phần mở rộng của chúng tôi đối với kubectl Việc điều tra các vấn đề liên quan đến việc không cấp chứng chỉ đã trở nên dễ dàng hơn. kubectl cert-manager status hiện cung cấp nhiều thông tin hơn về những gì đang xảy ra với chứng chỉ và cũng hiển thị giai đoạn chứng chỉ được cấp.
Sau khi cài đặt tiện ích mở rộng, bạn có thể chạy kubectl cert-manager status certificate <имя-сертификата>, sẽ tìm kiếm chứng chỉ có tên được chỉ định và mọi tài nguyên liên quan, chẳng hạn như Yêu cầu chứng chỉ, Bí mật, Nhà phát hành, Đơn đặt hàng và Thử thách trong trường hợp chứng chỉ từ ACME.
Một ví dụ về gỡ lỗi chứng chỉ chưa sẵn sàng:
$ 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
Nhóm cũng có thể giúp bạn tìm hiểu thêm về nội dung của chứng chỉ. Chi tiết ví dụ về chứng chỉ do Letsencrypt cấp:
$ 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
[...]
Tận dụng API Kubernetes ổn định mới nhất
Người quản lý chứng chỉ là một trong những người đầu tiên triển khai CRD Kubernetes. Điều này, cùng với sự hỗ trợ của chúng tôi dành cho các phiên bản Kubernetes lên tới 1.11, có nghĩa là chúng tôi cần hỗ trợ các phiên bản cũ apiextensions.k8s.io/v1beta1 cho CRD của chúng tôi nữa admissionregistration.k8s.io/v1beta1 cho webhooks của chúng tôi. Những tính năng này hiện không được dùng nữa và sẽ bị xóa trong Kubernetes kể từ phiên bản 1.22. Với phiên bản 1.0 của chúng tôi, chúng tôi hiện cung cấp hỗ trợ đầy đủ apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 dành cho Kubernetes 1.16 (nơi chúng được thêm vào) trở lên. Đối với người dùng các phiên bản trước, chúng tôi tiếp tục cung cấp hỗ trợ v1beta1 trong của chúng tôi legacy các phiên bản.
Ghi nhật ký được cải thiện
Trong phiên bản này, chúng tôi đã cập nhật thư viện ghi nhật ký thành klog/v2, được sử dụng trong Kubernetes 1.19. Chúng tôi cũng xem xét mọi tạp chí chúng tôi viết để đảm bảo nó được xếp ở cấp độ phù hợp. Chúng tôi đã được hướng dẫn bởi điều này . Có năm (thực tế - sáu, khoảng người phiên dịch) mức ghi nhật ký bắt đầu từ Error (cấp 0), chỉ in các lỗi quan trọng và kết thúc bằng Trace (cấp 5), điều này sẽ giúp bạn tìm hiểu chính xác điều gì đang xảy ra. Với thay đổi này, chúng tôi đã giảm số lượng nhật ký nếu bạn không cần thông tin gỡ lỗi khi chạy trình quản lý chứng chỉ.
Mẹo: theo mặc định, trình quản lý chứng chỉ chạy ở cấp 2 (Info), bạn có thể ghi đè lên điều này bằng cách sử dụng global.logLevel trong biểu đồ Helm.
Lưu ý: Xem lại nhật ký là biện pháp cuối cùng của bạn khi khắc phục sự cố. Để biết thêm thông tin hãy xem của chúng tôi .
NB của biên tập viên: Để tìm hiểu thêm về cách thức hoạt động của Kubernetes, nhận lời khuyên có giá trị từ các giáo viên thực hành cũng như hỗ trợ kỹ thuật chất lượng cao, bạn có thể tham gia các khóa học chuyên sâu trực tuyến , sẽ diễn ra từ ngày 28 đến ngày 30 tháng XNUMX và , sẽ diễn ra từ ngày 14 đến ngày 16 tháng XNUMX.
Cải tiến ACME
Việc sử dụng trình quản lý chứng chỉ phổ biến nhất có lẽ liên quan đến việc cấp chứng chỉ từ Let's Encrypt bằng ACME. Phiên bản 1.0 đáng chú ý vì sử dụng phản hồi của cộng đồng để bổ sung hai cải tiến nhỏ nhưng quan trọng cho nhà phát hành ACME của chúng tôi.
Vô hiệu hóa việc tạo khóa tài khoản
Nếu bạn sử dụng chứng chỉ ACME với số lượng lớn, có thể bạn đang sử dụng cùng một tài khoản trên nhiều cụm, do đó, các hạn chế cấp chứng chỉ của bạn sẽ áp dụng cho tất cả các cụm đó. Điều này đã có thể thực hiện được trong trình quản lý chứng chỉ khi sao chép bí mật được chỉ định trong privateKeySecretRef. Trường hợp sử dụng này khá có lỗi vì người quản lý chứng chỉ đã cố gắng tỏ ra hữu ích và vui vẻ tạo khóa tài khoản mới nếu không tìm thấy khóa. Đó là lý do tại sao chúng tôi đã thêm disableAccountKeyGenerationđể bảo vệ bạn khỏi hành vi này bằng cách đặt tùy chọn này thành true - cert-manager sẽ không tạo khóa và sẽ cảnh báo bạn rằng nó không được cấp khóa tài khoản.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
privateKeySecretRef:
name: example-issuer-account-key
disableAccountKeyGeneration: false
Chuỗi ưa thích
Ngày 29 tháng XNUMX Hãy mã hóa tới cơ quan cấp chứng chỉ gốc của riêng bạn ISRG Root. Chứng chỉ có chữ ký chéo sẽ được thay thế bằng Identrust. Thay đổi này không yêu cầu thay đổi cài đặt trình quản lý chứng chỉ; tất cả các chứng chỉ được cập nhật hoặc mới được cấp sau ngày này sẽ sử dụng CA gốc mới.
Let's Encrypt đã ký chứng chỉ với CA này và cung cấp chúng dưới dạng "chuỗi chứng chỉ thay thế" thông qua ACME. Phiên bản trình quản lý chứng chỉ này có khả năng thiết lập quyền truy cập vào các chuỗi này trong cài đặt của nhà phát hành. Trong tham số preferredChain Bạn có thể chỉ định tên của CA được sử dụng để cấp chứng chỉ. Nếu có chứng chỉ CA phù hợp với yêu cầu, nó sẽ cấp cho bạn chứng chỉ. Xin lưu ý rằng đây là tùy chọn ưu tiên; nếu không tìm thấy gì, chứng chỉ mặc định sẽ được cấp. Điều này sẽ đảm bảo rằng bạn vẫn sẽ gia hạn chứng chỉ của mình sau khi xóa chuỗi thay thế ở phía nhà phát hành ACME.
Hôm nay bạn có thể nhận được chứng chỉ đã ký ISRG Root, Cho nên:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "ISRG Root X1"
Nếu bạn muốn rời khỏi chuỗi IdenTrust - đặt tham số này thành 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"
Xin lưu ý rằng CA gốc này sẽ sớm không còn được dùng nữa, Let's Encrypt sẽ duy trì chuỗi này hoạt động cho đến ngày 29 tháng 2021 năm XNUMX.
Nguồn: www.habr.com
