這篇文章主要介紹了如何使用cert-manager簽發(fā)免費(fèi)證書的相關(guān)知識,內(nèi)容詳細(xì)易懂,操作簡單快捷,具有一定借鑒價值,相信大家閱讀完這篇如何使用cert-manager簽發(fā)免費(fèi)證書文章都會有所收獲,下面我們一起來看看吧。
丹棱ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景,ssl證書未來市場廣闊!成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道,可以享受市場價格4-6折優(yōu)惠!如果有意向歡迎電話聯(lián)系或者加微信:18980820575(備注:SSL證書合作)期待與您的合作!
隨著 HTTPS 不斷普及,越來越多的網(wǎng)站都在從 HTTP 升級到 HTTPS,使用 HTTPS 就需要向權(quán)威機(jī)構(gòu)申請證書,需要付出一定的成本,如果需求數(shù)量多,也是一筆不小的開支。cert-manager 是 Kubernetes 上的全能證書管理工具,如果對安全級別和證書功能要求不高,可以利用 cert-manager 基于 ACME 協(xié)議與 Let's Encrypt 來簽發(fā)免費(fèi)證書并自動續(xù)期,實現(xiàn)永久免費(fèi)使用證書。
cert-manager 部署到 Kubernetes 集群后,它會 watch 它所支持的 CRD 資源,我們通過創(chuàng)建 CRD 資源來指示 cert-manager 為我們簽發(fā)證書并自動續(xù)期:
解釋下幾個關(guān)鍵的資源:
Issuer/ClusterIssuer: 用于指示 cert-manager 用什么方式簽發(fā)證書,本文主要講解簽發(fā)免費(fèi)證書的 ACME 方式。ClusterIssuer 與 Issuer 的唯一區(qū)別就是 Issuer 只能用來簽發(fā)自己所在 namespace 下的證書,ClusterIssuer 可以簽發(fā)任意 namespace 下的證書。
Certificate: 用于告訴 cert-manager 我們想要什么域名的證書以及簽發(fā)證書所需要的一些配置,包括對 Issuer/ClusterIssuer 的引用。
Let’s Encrypt 利用 ACME 協(xié)議來校驗域名是否真的屬于你,校驗成功后就可以自動頒發(fā)免費(fèi)證書,證書有效期只有 90 天,在到期前需要再校驗一次來實現(xiàn)續(xù)期,幸運(yùn)的是 cert-manager 可以自動續(xù)期,這樣就可以使用永久免費(fèi)的證書了。如何校驗這個域名是否屬于你呢?主流的兩種校驗方式是 HTTP-01 和 DNS-01,詳細(xì)校驗原理可參考 Let's Encrypt 的運(yùn)作方式,下面將簡單描述下。
HTTP-01 的校驗原理是給你域名指向的 HTTP 服務(wù)增加一個臨時 location ,Let’s Encrypt 會發(fā)送 http 請求到 http:///.well-known/acme-challenge/
,YOUR_DOMAIN
就是被校驗的域名,TOKEN
是 ACME 協(xié)議的客戶端負(fù)責(zé)放置的文件,在這里 ACME 客戶端就是 cert-manager,它通過修改或創(chuàng)建 Ingress 規(guī)則來增加這個臨時校驗路徑并指向提供 TOKEN
的服務(wù)。Let’s Encrypt 會對比 TOKEN
是否符合預(yù)期,校驗成功后就會頒發(fā)證書。此方法僅適用于給使用 Ingress 暴露流量的服務(wù)頒發(fā)證書,并且不支持泛域名證書。
DNS-01 的校驗原理是利用 DNS 提供商的 API Key 拿到你的 DNS 控制權(quán)限, 在 Let’s Encrypt 為 ACME 客戶端提供令牌后,ACME 客戶端 (cert-manager) 將創(chuàng)建從該令牌和您的帳戶密鑰派生的 TXT 記錄,并將該記錄放在 _acme-challenge.
。 然后 Let’s Encrypt 將向 DNS 系統(tǒng)查詢該記錄,如果找到匹配項,就可以頒發(fā)證書。此方法不需要你的服務(wù)使用 Ingress,并且支持泛域名證書。
HTTP-01 的校驗方式的優(yōu)點(diǎn)是: 配置簡單通用,不管使用哪個 DNS 提供商都可以使用相同的配置方法;缺點(diǎn)是:需要依賴 Ingress,如果你的服務(wù)不是用 Ingress 暴露流量的就不適用,而且不支持泛域名證書。
DNS-01 的校驗方式的優(yōu)點(diǎn)是沒有 HTTP-01 校驗方式缺點(diǎn),不依賴 Ingress,也支持泛域名;缺點(diǎn)就是不同 DNS 提供商的配置方式不一樣,而且 DNS 提供商有很多,cert-manager 的 Issuer 不可能每個都去支持,不過有一些可以通過部署實現(xiàn)了 cert-manager 的 Webhook 的服務(wù)來擴(kuò)展 Issuer 進(jìn)行支持,比如 DNSPod 和 阿里 DNS,詳細(xì) Webhook 列表請參考: https://cert-manager.io/docs/configuration/acme/dns01/#webhook
選擇哪種方式呢?條件允許的話,建議是盡量用 DNS-01
的方式,限制更少,功能更全。
通常直接使用 yaml 方式一鍵安裝 cert-manager 到集群,參考官網(wǎng)文檔 Installing with regular manifests。
cert-manager 官方使用的鏡像在 quay.io
,國內(nèi)拉取可能比較慢,也可以使用下面命令一鍵安裝(使用同步到國內(nèi) CCR 的鏡像):
kubectl apply --validate=false -f https://raw.githubusercontent.com/TencentCloudContainerTeam/manifest/master/cert-manager/cert-manager.yaml
! 以上命令安裝方式要求集群版本不低于 1.16。
登錄你的 DNS 提供商后臺,配置域名的 DNS A 記錄,指向你需要證書的后端服務(wù)對外暴露的 IP 地址,以 cloudflare 為例:
如果使用 HTTP-01 的校驗方式,需要用到 Ingress 來配合校驗。cert-manager 會通過自動修改 Ingress 規(guī)則或自動新增 Ingress 來實現(xiàn)對外暴露校驗所需的臨時 HTTP 路徑,這個就是在給 Issuer 配置 http01 校驗,指定 Ingress 的 name
或 class
的區(qū)別 (見下面的示例)。
TKE 自帶的 Ingress 是每個 Ingress 資源都會對應(yīng)一個 CLB,如果你使用 TKE 自帶的 Ingress 暴露服務(wù),并且使用 HTTP-01 方式校驗,那么只能使用自動修改 Ingress 的方式,不能自動新增 Ingress,因為自動新增出來的 Ingress 會自動創(chuàng)建其它 CLB,對外的 IP 地址就與我們后端服務(wù)的 Ingress 不一致,Let's Encrypt 校驗時就無法從我們服務(wù)的 Ingress 找到校驗所需的臨時路徑,從而導(dǎo)致校驗失敗,無法簽發(fā)證書。如果使用自建 Ingress,比如 在 TKE 上部署 Nginx Ingress,同一個 Ingress class 的 Ingress 共享同一個 CLB,這樣就可以使用自動新增 Ingress 的方式。
下面給出一些示例。
如果你的服務(wù)使用 TKE 自帶的 Ingress 暴露服務(wù),不太適合用 cert-manager 簽發(fā)管理免費(fèi)證書,因為證書是要上傳到 證書管理 來引用的,不在 K8S 中管理。
假設(shè)是 在 TKE 上部署 Nginx Ingress,且后端服務(wù)的 Ingress 是 prod/web
,創(chuàng)建 Issuer 示例:
apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: letsencrypt-http01 namespace: prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-http01-account-key solvers: - http01: ingress: name: web # 指定被自動修改的 Ingress 名稱
使用上面的 Issuer 簽發(fā)證書,cert-manager 會自動修改 prod/web
這個 Ingress 資源,以暴露校驗所需的臨時路徑,這是自動修改 Ingress 的方式,你可以使用自動新增 Ingress 的 方式,示例:
apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: letsencrypt-http01 namespace: prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-http01-account-key solvers: - http01: ingress: class: nginx # 指定自動創(chuàng)建的 Ingress 的 ingress class
使用上面的 Issuer 簽發(fā)證書,cert-manager 會自動創(chuàng)建 Ingress 資源,以暴露校驗所需的臨時路徑。
有了 Issuer,接下來就可以創(chuàng)建 Certificate 并引用 Issuer 進(jìn)行簽發(fā)了,示例:
apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: test-mydomain-com namespace: prod spec: dnsNames: - test.mydomain.com # 要簽發(fā)證書的域名 issuerRef: kind: Issuer name: letsencrypt-http01 # 引用 Issuer,指示采用 http01 方式進(jìn)行校驗 secretName: test-mydomain-com-tls # 最終簽發(fā)出來的證書會保存在這個 Secret 里面
如果使用 DNS-01 的校驗方式,就需要看你使用的哪個 DNS 提供商了,cert-manager 內(nèi)置了一些 DNS 提供商的支持,詳細(xì)列表和用法請參考 Supported DNS01 providers,不過 cert-manager 不可能去支持所有的 DNS 提供商,如果沒有你所使用的 DNS 提供商怎么辦呢?有兩種方案:
方案一:設(shè)置 Custom Nameserver。在你的 DNS 提供商后臺設(shè)置 custom nameserver,指向像 cloudflare 這種可以管理其它 DNS 提供商域名的 nameserver 地址,具體地址可登錄 cloudflare 后臺查看:
下面是 namecheap 設(shè)置 custom nameserver 的示例:
最后配置 Issuer 指定 DNS-01 驗證時,加上 cloudflare 的一些信息即可(見下文示例)。
方案二:使用 Webhook。使用 cert-manager 的 Webhook 來擴(kuò)展 cert-manager 的 DNS-01 驗證所支持的 DNS 提供商,已經(jīng)有許多第三方實現(xiàn),包括國內(nèi)常用的 DNSPod 與阿里 DNS,詳細(xì)列表參考: Webhook。
下面以 cloudflare 為例來簽發(fā)證書:
登錄 cloudflare,點(diǎn)到 My Profile > API Tokens > Create Token
來創(chuàng)建 Token:
復(fù)制 Token 并妥善保管:
將 Token 保存到 Secret 中:
apiVersion: v1 kind: Secret metadata: name: cloudflare-api-token-secret namespace: cert-manager type: Opaque stringData: api-token:# 粘貼 Token 到這里,不需要 base64 加密。
! 如果是要創(chuàng)建 ClusterIssuer,Secret 需要創(chuàng)建在 cert-manager 所在命名空間中,如果是 Issuer,那就創(chuàng)建在 Issuer 所在命名空間中。
創(chuàng)建 ClusterIssuer:
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-dns01 spec: acme: privateKeySecretRef: name: letsencrypt-dns01 server: https://acme-v02.api.letsencrypt.org/directory solvers: - dns01: cloudflare: email: my-cloudflare-acc@example.com # 替換成你的 cloudflare 郵箱賬號,API Token 方式認(rèn)證非必需,API Keys 認(rèn)證是必需 apiTokenSecretRef: key: api-token name: cloudflare-api-token-secret # 引用保存 cloudflare 認(rèn)證信息的 Secret
創(chuàng)建 Certificate:
apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: test-mydomain-com namespace: default spec: dnsNames: - test.mydomain.com # 要簽發(fā)證書的域名 issuerRef: kind: ClusterIssuer name: letsencrypt-dns01 # 引用 ClusterIssuer,指示采用 dns01 方式進(jìn)行校驗 secretName: test-mydomain-com-tls # 最終簽發(fā)出來的證書會保存在這個 Secret 里面
創(chuàng)建好 Certificate 后,等一小會兒,我們可以 kubectl 查看是否簽發(fā)成功:
$ kubectl get certificate -n prod NAME READY SECRET AGE test-mydomain-com True test-mydomain-com-tls 1m
如果 READY
為 False
表示失敗,可以通過 describe 查看 event 來排查失敗原因:
$ kubectl describe certificate test-mydomain-com -n prod
如果為 True
表示簽發(fā)成功,證書就保存在我們所指定的 Secret 中 (上面的例子是 default/test-mydomain-com-tls
),可以通過 kubectl 查看:
$ kubectl get secret test-mydomain-com-tls -n default ... data: tls.crt:tls.key:
其中 tls.crt
就是證書,tls.key
是密鑰。
你可以將它們掛載到你需要證書的應(yīng)用中,或者使用自建的 Ingress,可以直接在 Ingress 中引用 secret,示例:
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: test-ingress annotations: kubernetes.io/Ingress.class: nginx spec: rules: - host: test.mydomain.com http: paths: - path: /web backend: serviceName: web servicePort: 80 tls: hosts: - test.mydomain.com secretName: test-mydomain-com-tls
關(guān)于“如何使用cert-manager簽發(fā)免費(fèi)證書”這篇文章的內(nèi)容就介紹到這里,感謝各位的閱讀!相信大家對“如何使用cert-manager簽發(fā)免費(fèi)證書”知識都有一定的了解,大家如果還想學(xué)習(xí)更多知識,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。