Khi triển khai một dự án web, việc triển khai   là một thách thức phổ biến mà mọi kỹ sư đều có thể gặp phải – và tôi cũng không ngoại lệ. chứng chỉ SSL  Thông thường, các công ty khởi nghiệp chọn chứng chỉ miễn phí như chứng chỉ từ Let's Encrypt. Tuy nhiên, những điều này đi kèm với những hạn chế và sự bất tiện cần xem xét, được trình bày chi tiết trên   . trang web của nhà cung cấp chứng chỉ   Hãy cùng xem xét kỹ hơn các vấn đề mà cá nhân tôi đã gặp phải với các chứng chỉ miễn phí:  Đầu tiên và quan trọng nhất, chúng yêu cầu cấp lại thường xuyên và chỉ có giá trị trong tối đa ba tháng.  Trong trường hợp của Kubernetes, các chứng chỉ cần được lưu trữ và thường xuyên tạo lại trong nền tảng.  Chứng chỉ ký tự đại diện và việc gia hạn của chúng gây ra một số khó khăn.  Các giao thức và thuật toán mã hóa cũng có những đặc thù riêng.  Thường xuyên phải đối mặt với những vấn đề này, tôi đã phát triển một cấu hình giải pháp tùy chỉnh sử dụng chứng chỉ Let's Encrypt. Trong bài viết này, tôi sẽ chia sẻ những phát hiện của mình và những bài học tôi đã học được trong quá trình thực hiện.  Gần đây, tôi đang tập trung vào một nhóm công nghệ cụ thể và muốn thảo luận về giải pháp cơ sở hạ tầng dựa trên cụm   trong ngữ cảnh của nhà cung cấp đám mây Azure. Mặc dù trình quản lý chứng chỉ là một giải pháp phổ biến trong lĩnh vực này, nhưng tôi thích cài đặt nó qua Helm hơn để thuận tiện hơn. Kubernetes     Vì vậy, không cần phải quảng cáo thêm, hãy đi sâu vào:     helm repo update                          helm repo add jetstack https: //charts.jetstack.io 
 kubectl apply -f https: //github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.crds.yaml 
 helm install cert-manager jetstack/cert-manager -- namespace   cert - manager  -- create - namespace  -- version   v1 . 6 . 1  Sau đó, chúng ta có thể tạo một ClusterIssuer bằng tệp YAML sau:    apiVersion:   cert-manager.io/v1 
 kind:   ClusterIssuer 
 metadata: 
    name:   letsencrypt-cluster-issuer 
 spec: 
    acme: 
      server:   https://acme-v02.api.letsencrypt.org/directory 
      email:   p….@gmail.com     #your e-mail 
      privateKeySecretRef: 
        name:   letsencrypt-cluster-issuer 
      solvers: 
        -   http01: 
            ingress: 
              class:   nginx  Trong tương lai, có hai tùy chọn để triển khai chứng chỉ:  Tạo chứng chỉ bằng cách thêm "loại: Chứng chỉ";  Quản lý chứng chỉ thông qua sự xâm nhập của bạn.  Hãy khám phá cả hai lựa chọn.     Trong kịch bản đầu tiên, các tệp YAML của tôi trông như thế này:    kind: Certificate metadata: name: myservice2                                                       apiVersion: cert-manager.io/v1    namespace : test 
 Spec :    duration : 2160h 
    renewBefore : 72h 
    dnsNames :  - myservice2 . mydomain . org  # you   resources 
    secretName : myservice2 - tls 
    issuerRef :      name : letsencrypt - cluster - issuer 
      kind : ClusterIssuer  Đáng chú ý là chỉ có "SecretName: myservice2-tls" được đề cập trong phần đầu vào trong phần TLS cho một dịch vụ cụ thể.  Nhân tiện, tệp YAML chứa một số tham số hữu ích, chẳng hạn như:    – cho biết thời lượng của chứng chỉ tính bằng giờ thời lượng: 48h    – chỉ định bao nhiêu giờ trước khi chứng chỉ hết hạn, bạn có thể thử gia hạn chứng chỉ hiện có gia hạn trước: 24h  Nếu bạn cảm thấy thoải mái hơn khi làm việc với bảng điều khiển, hãy để tôi cung cấp cho bạn một cái nhìn toàn diện về chứng chỉ làm ví dụ.              kubectl describe  certificates <cert name > -n <namespace name >   Vì vậy, những gì chúng ta có cuối cùng?    – ngày hết hạn của chứng chỉ; Not After    – ngày tạo chứng chỉ (trừ khi được chỉ định rõ ràng trong trường Tài nguyên YAML của chứng chỉ); Not Before    – dấu thời gian trước khi chứng chỉ hết hạn. Thời gian gia hạn  Cá nhân tôi thấy việc quản lý chứng chỉ Let's Encrypt thông qua Ingress đáng tin cậy và thuận tiện hơn, đó là lý do tại sao tôi đã sử dụng nó gần đây. Với phương pháp này, ngoài secretName và hostname trong phần TLS, bạn chỉ cần chỉ định các chú thích trong tệp YAML đầu vào.          annotations :  cert-manager .io/cluster-issuer: "letsencrypt-cluster-issuer"  cert-manager .io/renew-before: 72h  Và ở đó bạn có nó, sự kỳ diệu của tất cả! Chứng chỉ hiện được cấp lại tự động, với khoảng thời gian đệm là ba ngày trước khi chúng hết hạn trong ví dụ này. Cần lưu ý rằng, trong trường hợp của Let's Encrypt, khoảng thời gian mặc định là 90 ngày.  Tuy nhiên, do những hạn chế của chứng chỉ miễn phí từ Let's Encrypt, nhóm của chúng tôi cuối cùng đã dự tính nhu cầu về chứng chỉ toàn diện có thể bảo vệ không chỉ miền của chúng tôi mà cả các miền phụ. Khi chúng tôi tiếp tục phát triển dự án của mình trên Azure, chúng tôi nhận thấy rằng Azure Key Vault cung cấp một vị trí thuận tiện để lưu trữ các chứng chỉ đó. Chúng tôi đã và đang sử dụng tiện ích akv2k8s trong cụm Kubernetes của mình. Nếu bạn quan tâm, tôi khuyến khích bạn tìm   . hiểu thêm về nó  Azure Key Vault là gì  Sau khi bạn đã nhận được chứng chỉ trong Azure, bước tiếp theo là thêm chứng chỉ đó vào Azure Key Vault (AKV). Mặc dù quy trình này tương đối đơn giản nhưng việc xác minh quyền sở hữu miền có thể hơi phức tạp. Tuy nhiên, sau khi tất cả các bước xác nhận được hoàn tất thành công, chứng chỉ sẽ xuất hiện trong phần "Bí mật" của kho khóa.  Một trong những lợi ích chính của phương pháp này là tự động gia hạn chứng chỉ. Chứng chỉ sẽ được cấp lại và cập nhật trong AKV sau một năm và nó sẽ tự động đồng bộ hóa với Secret trong Kubernetes.   Để cụm Kubernetes sử dụng chứng chỉ đã mua, bạn cần cấp cho nó một số quyền và quyền truy cập.  Để thực hiện việc này, trước tiên bạn cần có được idityProfile.kubeletidentity.objectId của cụm. Bạn có thể làm như vậy bằng cách sử dụng lệnh sau:                az aks show -g < RG >  -n < AKS_name >  Nhóm tài nguyên (RG) là vị trí lưu trữ cụm và AKS_name là tên cụm của bạn.  Sau khi có được idityProfile.kubeletidentity.objectId, bạn cần sao chép nó. Tiếp theo, thêm giá trị vào lệnh cấp quyền truy cập bí mật:                az   keyvault   set-policy   --name  < name   AKV > --object-id  < get   from   first   step   value > --secret-permissions   get  Tiếp theo, bạn có thể tiến hành cài đặt akv2k8s, có thể thực hiện thông qua Helm hoặc các phương pháp ưa thích khác, như được mô tả trong   . hướng dẫn cài đặt  Theo   , sau đó bạn có thể đồng bộ hóa chứng chỉ Azure Key Vault của mình với Secret trong một không gian tên Kubernetes cụ thể. Đây là tệp YAML của tôi:  tài liệu chính thức    kind: AzureKeyVaultSecret metadata: name: wildcard-cert #any name                                                             apiVersion: spv.no/v1    namespace : default 
 spec :    vault :      name : SandboxKeyVault  # name   you   keyvault   in   Azure 
      object :        name : name_object_id  # name   object   id   from   Azure   AKV   this   cert 
        type : secret 
    output :      secret :        name : wildcard - cert  # any   name   for   secret   in   your   namespace 
        type : kubernetes . io / tls 
        chainOrder : ensureserverfirst  # very   important   values !!!  Hãy để tôi nhấn mạnh tầm quan trọng của dòng cuối cùng, vì nó đóng một vai trò quan trọng trong việc giải quyết vấn đề mà tôi gặp phải. Ban đầu, tôi có thể tải chứng chỉ lên Kubernetes thành công, nhưng nó không hoạt động như dự kiến. Phải mất một thời gian để chẩn đoán vấn đề.  Hóa ra, khi xuất chứng chỉ PFX từ Key Vault, chứng chỉ máy chủ đôi khi được định vị ở cuối chuỗi thay vì ở đầu chuỗi. Điều này có thể gây ra sự cố khi được sử dụng với các tham số như ingress-nginx, vì chứng chỉ không tải được và mặc định trở về giá trị ban đầu. Tuy nhiên, bằng cách đặt chainOrder thành ensureserverfirst, chứng chỉ máy chủ sẽ được đặt đầu tiên trong chuỗi.  Khi kiểm tra kỹ hơn chứng chỉ, tôi phát hiện ra rằng chuỗi được sắp xếp theo trình tự sau:  Trung cấp  Nguồn gốc  Máy chủ   Sau khi đã thảo luận về các khía cạnh kỹ thuật và cấu hình, hãy quay lại tìm hiểu các đặc thù của chứng chỉ Azure.  Azure cung cấp hai tùy chọn để yêu cầu chứng chỉ, cả hai đều do GoDaddy cung cấp:  chứng chỉ cho một tên miền hoặc tên miền phụ cụ thể;  một chứng chỉ ký tự đại diện.  Chúng tôi đã chọn cái sau, hy vọng nó sẽ bảo vệ tất cả các ứng dụng và dịch vụ của chúng tôi. Tuy nhiên, có một vài sắc thái.  Chứng chỉ Azure Wildcard chỉ bảo vệ các tên miền phụ cấp một. Chẳng hạn, nếu chúng tôi có một miền có tên   , chứng chỉ sẽ chỉ bao gồm các miền phụ cấp một ở dạng   . mydomain.com .mydomain.com  Do đó, chứng chỉ sẽ hoạt động đối với các tài nguyên như   nhưng sẽ không áp dụng cho   hoặc   . service1.mydomain.com, service2.mydomain.com, service3.mydomain.com service1.test.mydomain.com mail.service1.mydomain.com  Chúng ta có những lựa chọn nào sau đó?  Mua chứng chỉ Wildcard riêng cho tất cả các tên miền phụ cần thiết;  Thêm bản ghi SAN       vào chứng chỉ. ( Subject Alternative Name )  Tùy chọn đầu tiên không khả thi vì số lượng tên miền phụ, đặc biệt là những tên miền ở cấp độ thứ hai, có thể rất lớn. Do đó, trả tiền để có được chứng chỉ ký tự đại diện cho mỗi tên miền phụ (   ) không phải là giải pháp hợp lý nhất. .service1.mydomain.com, *.dev.mydomain.com…  Đối với tùy chọn thứ hai, tôi đã có một cuộc trò chuyện dài với nhóm hỗ trợ Azure về vấn đề này, trải qua tất cả các giai đoạn từ chối, thất vọng và tức giận, chỉ để cuối cùng nhận ra rằng khả năng SAN cho các chứng chỉ vẫn chưa được triển khai.  Cho đến cuối cùng, tôi đã hy vọng rằng sự cố như vậy sẽ không bao giờ xảy ra trên Azure. Ngược lại, đối thủ cạnh tranh của họ, AWS Amazon, cung cấp chứng chỉ thông qua Trình quản lý chứng chỉ AWS (ACM) hỗ trợ tối đa 10 tên chủ đề thay thế, bao gồm cả ký tự đại diện. Nó cho phép bạn tạo 10 miền phụ với ký tự đại diện (*) và thậm chí yêu cầu tăng hạn ngạch trên AWS lên tới 100k.  Để kết thúc, tôi sẽ chia sẻ cách bạn có thể sử dụng chứng chỉ với dịch vụ Cửa trước trên Azure.  Tìm hiểu Azure Front Door (AFD)  Đối với tôi, Azure Front Door (AFD) là một cổng toàn cầu và có thể mở rộng, tận dụng mạng biên toàn cầu của Microsoft để hướng lưu lượng truy cập đến các điểm cuối thích hợp, có thể là các ứng dụng hoặc dịch vụ web. Hoạt động ở lớp HTTP/HTTPS (lớp 7), Front Door định tuyến các yêu cầu của máy khách đến một máy chủ ứng dụng khả dụng từ nhóm.   của ứng dụng có thể là bất kỳ dịch vụ nào có thể truy cập Internet, cho dù dịch vụ đó được lưu trữ bên trong hay bên ngoài Azure.  Phía máy chủ     Một ví dụ từ trang web tài liệu https://docs.microsoft.com/   Azure Front Door là một công cụ tiện lợi cho phép bạn cân bằng và ủy quyền lưu lượng truy cập đến truy cập vào các ứng dụng và dịch vụ được phân phối trên toàn thế giới. Nó cung cấp một loạt các tính năng bao gồm khả năng liên kết các quy tắc khác nhau bằng cách định cấu hình trình xử lý quy tắc, tham gia chính sách và cài đặt tường lửa. Tôi sẽ không đi sâu vào các chi tiết cụ thể của dịch vụ AFD trong bài viết này mà sẽ tập trung vào các đặc thù dịch vụ của chứng chỉ.  Như bạn có thể mong đợi, lưu lượng truy cập đến Azure Front Door có thể là   hoặc   . Nếu chọn   , bạn có ba tùy chọn: tạo chứng chỉ trên chính dịch vụ Azure Front Door, tải chứng chỉ của riêng bạn lên hoặc đồng bộ hóa chứng chỉ hiện có của bạn với Azure Key Vault. Để cho phép dịch vụ Cửa trước truy cập Kho lưu trữ khóa, bạn cần định cấu hình các quyền cần thiết. http https https  Tôi khuyên bạn nên sử dụng tùy chọn cuối cùng và chọn phiên bản mới nhất của chứng chỉ để tránh phải gia hạn hoặc tạo lại thủ công. Bằng cách kết nối chứng chỉ từ AKV, mọi thứ sẽ tự động cập nhật.     Thiết lập này sẽ cung cấp cho bạn kết quả như sau:  Đây là một điểm đặc biệt khác trong khi điều hướng lưu lượng truy cập từ Azure Front Door đến AKS.  Xử lý lưu lượng truy cập   không phải là vấn đề, nhưng có một chi tiết tinh tế cần lưu ý khi thiết lập nhóm tài nguyên và chỉ định địa chỉ IP bên ngoài của cụm AKS. Đảm bảo để trống trường "tiêu đề nút thành phần máy chủ" để đảm bảo rằng trường này được tự động điền các giá trị được nhập vào trường "IP hoặc tên nút".  http  Giả sử bạn có chứng chỉ ký tự đại diện tên miền được đính kèm thông qua AKV, chứng chỉ này được sử dụng bởi cả dịch vụ Cửa trước và được đưa vào cụm AKS thông qua akv2k8s. Tên máy chủ giao diện (và bản ghi CNAME trong DNS) cho tất cả các ứng dụng và dịch vụ của bạn có thể truy cập thông qua Front Door sẽ như sau:  *.mydomain.com – với trường "tiêu đề nút thành phần máy chủ" để trống;  Địa chỉ IP AKS bên ngoài của bạn sẽ có quy tắc chuyển hướng http mặc định tới /.  Điều này sẽ cho phép tất cả các dịch vụ ở định dạng   hoạt động bình thường. Khi bạn đã hoàn thành cấu hình này, bạn đã hoàn tất.  *.mydomain.com  Trong một số trường hợp nhất định, việc chuyển hướng lưu lượng truy cập từ Azure Front Door sang AKS thông qua https có thể thuận lợi hơn. Để đảm bảo Azure Front Door hoạt động chính xác trong cài đặt nhóm máy chủ, điều quan trọng là phải chỉ định   , có liên quan đến SNI và kiểm tra tình trạng. Nếu không, thiết lập sẽ không hoạt động. tên DNS tương ứng với cụm AKS của bạn  Trong trường hợp của tôi, không có tên nào được gán cho cụm AKS của tôi, tôi chỉ có các dịch vụ trước đây hoạt động trực tiếp nhưng phải hoạt động thông qua Azure Front Door. Để giải quyết vấn đề này, tôi phải tạo một tên DNS riêng cho cụm AKS, định cấu hình DNS và thiết lập một dịch vụ riêng có chứng chỉ được đính kèm với mục nhập. Chỉ sau đó, tôi mới có thể chuyển hướng lưu lượng truy cập   đến các cụm AKS và đảm bảo rằng nó hoạt động chính xác cho tất cả các dịch vụ có sẵn. https  Điều quan trọng là phải xem xét các biện pháp bảo mật trong khi thiết lập quyền kết nối cho AKS. Để đảm bảo kết nối an toàn, bạn có thể giới hạn quyền kết nối với AKS chỉ từ các địa chỉ IP Azure Front Door trong Nhóm bảo mật mạng cho AKS (như minh họa trong hình bên dưới).   Ngoài ra, bạn có thể thiết lập lối vào AKS để chỉ chấp nhận các kết nối từ tiêu đề Azure Front Door của bạn theo ID bằng cách sử dụng   . tham số X-Azure-FDID  Lưu ý cuối cùng và một lời khuyên  1. Azure không cung cấp thông tin đầy đủ về các tính năng và nhược điểm của chứng chỉ của họ. Tuy nhiên, điều đáng nói là họ đã nhanh chóng hoàn trả cho chúng tôi chứng chỉ đã mua.  2. Trong quá trình phát triển, chúng tôi tiếp tục sử dụng Let's Encrypt. Mặc dù nó có những hạn chế, nhưng nó không phải là sự lựa chọn tồi tệ nhất hiện có.  3. Nếu dự án của bạn yêu cầu nhiều tên miền phụ với các mức tài nguyên khác nhau, bạn có thể muốn xem xét chứng chỉ "Ký tự đại diện (còn được gọi là Đa miền) có SAN" của nhà cung cấp bên thứ ba. Các chứng chỉ này có thể được nhập vào Azure và sử dụng hết tiềm năng của chúng.  4. Khi được định cấu hình chính xác, Azure Front Door là một dịch vụ xuất sắc. Tôi khuyên bạn nên nó.  Viết bởi Pavel Shapurau, Trưởng nhóm kỹ sư DevOps, Social Discovery Group

See how we create Social Life 3.0 👉

Social Discovery Group Earns the Great Place To Work® Certification in the USA!

Swipe Away Loneliness: 2024 Dating Trends Forecast

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

Khám phá chứng chỉ SSL của Azure: Hành trình của chúng tôi với Let's Encrypt

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

287 Stories To Learn About Blockchain Development

128 Stories To Learn About Charles Dickens

309 Stories To Learn About Smart Contracts

223 Stories To Learn About Science

287 Stories To Learn About Blockchain Development

128 Stories To Learn About Charles Dickens

309 Stories To Learn About Smart Contracts

223 Stories To Learn About Science

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps