作者:scwang18,首要担任技术架构,在容器云方向颇有研究。
前语
KubeSphere 集群默许装置的证书是自签发证书,浏览器拜访拜访会宣布安全提示。本文记载了运用 let's encrytp
泛域名证书完成 Kubernetes 集群外部服务主动证书装备和证书到期主动更新,支撑 HTTPS 拜访。咱们还部署了证书主动分发组件,完成证书文件主动分发到其他 namespace 。
架构
在 KubeSphere 集群中运用 HTTPS 协议,需求一个证书办理器、一个证书主动签发服务
cert-manager 是一个云原生证书办理开源项目,用于在 KubeSphere 集群中提供 HTTPS 证书并主动续期,支撑 Let’s Encrypt
, HashiCorp Vault
这些免费证书的签发。在 KubeSphere 集群中,咱们能够经过 Kubernetes Ingress 和 Let’s Encrypt
完成外部服务的主动化 HTTPS。
Issuers/ClusterIssuers:界说运用什么证书颁布组织 (CA) 往来不断颁布证书,Issuers 和 ClusterIssuers 区别是: issuers 是一个称号空间等级的资源,只能用来签发自己地点 namespace 下的证书,ClusterIssuer 是个集群等级的资源 能够签发任意 namespace 下的证书
Certificate:界说所需的 X.509 证书,该证书将更新并坚持最新。Certificate 是一个命名空间资源,当 Certificate 被创立时,它会去创立相应的 CertificateRequest 资源往来不断请求证书。
装置证书办理器
装置证书办理器比较简单,直接履行以下脚本就能够了。
$ kubectl create ns cert-manager
$ helm uninstall cert-manager -n cert-manager
$ helm install cert-manager jetstack/cert-manager \
-n cert-manager \
--version v1.8.0 \
--set installCRDs=true \
--set prometheus.enabled=false \
--set 'extraArgs={--dns01-recursive-nameservers-only,--dns01-recursive-nameservers=119.29.29.29:53\,8.8.8.8:53}'
挑选证书颁布者
cert-manager 支撑以下几种证书颁布者:
- SelfSigned
- CA
- Vault
- Venafi
- External
- ACME
咱们挑选运用 ACME 来颁布证书。
挑选证书校验办法
常用的校验办法有 HTTP-01 、DNS-01 。
DNS-01 校验原理
DNS-01 的校验原理是运用 DNS 提供商的 API Key 拿到 DNS 操控权限, 在 Let’s Encrypt 为 ACME 客户端提供令牌后,ACME 客户端 (cert-manager) 将创立从该令牌和我的帐户密钥派生的 TXT 记载,并将该记载放在 _acme-challenge。 然后 Let’s Encrypt 将向 DNS 系统查询该记载,假如找到匹配项,就能够颁布证书。此办法支撑泛域名证书。
HTTP-01 校验原理
HTTP-01 的校验原理是给域名指向的 HTTP 服务增加一个暂时 location ,Let’s Encrypt 会发送 HTTP 请求到 http:///.well-known/acme-challenge/,参数中 YOUR_DOMAIN 便是被校验的域名,TOKEN 是 ACME 协议的客户端担任放置的文件,ACME 客户端便是 cert-manager,它经过修正或创立 Ingress 规则来增加这个暂时校验途径并指向提供 TOKEN 的服务。Let’s Encrypt 会比照 TOKEN 是否契合预期,校验成功后就会颁布证书。此办法仅适用于给运用 Ingress 暴露流量的服务颁布证书,不支撑泛域名证书。
优劣比照
HTTP-01 的校验办法的优点是: 装备简单通用,不管运用哪个 DNS 提供商都能够运用相同的装备办法;缺陷是:需求依靠 Ingress,假如服务不是经过 Ingress 暴露的就不适用,并且不支撑泛域名证书。
DNS-01 的校验办法的优点是没有 HTTP-01 校验办法缺陷,不依靠 Ingress,也支撑泛域名;缺陷便是不同 DNS 提供商的装备办法不一样,并且只有 cert-manager 支撑的 DNS 提供商才干够挑选这种办法。
Cert-manager 支撑运用外部 webhook 的接入 DNS 提供商,正好公司运用腾讯云的 DNSPOD 归于支撑的队伍。咱们能够挑选 DNS-01 。
HTTP-01 装备示例
这个装备示例仅供参阅,运用这种办法,有多少的 Ingress 服务,就需求请求多少张证书,比较麻烦,可是装备较为简单,不依靠 DNS 服务商。
1. 创立 CA 群集证书颁布者
证书办理器需求 Issuer 或 ClusterIssuer 资源,才干颁布证书。 这两种 Kubernetes 资源的功能完全相同,区别在于 Issuer 适用于单一命名空间,而 ClusterIssuer 适用于一切命名空间。
# ClusterIssuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt
spec:
acme:
email: scwang18@xxx.xxx
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: issuer-account-key
solvers:
- http01:
ingress:
class: nginx
阐明:
- metadata.name: 是咱们创立的签发组织的称号,后面咱们创立证书的时分会引用它;
- spec.acme.email: 是你自己的邮箱,证书快过期的时分会有邮件提示,不过 cert-manager 会运用 acme 协议主动给咱们重新颁布证书来续期;
- spec.acme.server: 是 acme 协议的服务端,咱们运用 Let’s Encrypt;
- spec.acme.privateKeySecretRef: 指示此签发组织的私钥即将存储到哪个 Secret 对象中;
- spec.acme.solvers: 这里指示签发组织校验办法,有 http01 和 dns01 两种,该字段下装备的 class 和 name 只能同时存在一个, class 指定运用的 Ingress class 称号, name 比较少用,一般用于 Kubernetes 的 Ingress。
$ kubectl apply -f ClusterIssuer.yaml -n cert-manager
履行成功后,会将请求的证书文件放置在 issuer-account-key 这个 Secret 中。
检查证书是否主动创立成功:
$ kubectl -n infra get certificate
2. 在 Ingress 中运用上步请求到的 SSL 证书
# ingreess-wikijs.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: letsencrypt
nginx.ingress.kubernetes.io/proxy-body-size: "0"
name: ingress-wikijs
spec:
ingressClassName: nginx
rules:
- host: wiki.xxx.xxx
http:
paths:
- backend:
service:
name: wikijs
port:
number: 3000
path: /
pathType: Prefix
tls:
- hosts:
- wikijs.xxx.xxx
secretName: ingress-wikijs-tls
注意:在 annotations 里 设置
cert-manager.io/cluster-issuer
为签名创立的集群证书颁布者letsencrypt
。
运用 yaml 文件创立 ingress 后,就能够运用该 Ingress 对外提供 HTTPS 服务了。
# 履行创立 ingress
kubectl apply -f ingress-wikijs.yaml -n infra
DNS01 装备示例
运用这种办法需求 DNS 服务商支撑经过 API 创立 DNS 记载,正好我的 DNS 服务商是腾讯云 dnspod 支撑,因此在咱们的及群里,最终采用了这种办法。
这个办法的装备会比较麻烦,踩了好久的坑,首要是因为我的集群启用了本地 DNS 服务器,默许 cert-manager 会经过本地 DNS 服务器去验证经过 API 创立的 DNS txt 记载,会一向检查不到新增的 txt 记载,形成在 challenge 阶段就一向 pendding。解决方案附后。
1. 在 dnspod 创立 API ID 和 API Token
参阅腾讯云官方文档(support.dnspod.cn/Kb/showarti…) 记载下创立的 API ID 和 API Token (加码处理,需求自行获取自己的 API ID 和 API Token)。
AKIDVt3z4uVss11xjIdmddgMmHXXssssHp9D2buxrWR8
SekbG2gqdflQs5xxxviGagX8TYO
2. 装置 cert-manager-webhook-dnspod
运用 helm 装置 roc/cert-manager-webhook-dnspod。
$ helm repo add roc https://charts.imroc.cc
$ helm uninstall cert-manager-webhook-dnspod -n cert-manager
$ helm install cert-manager-webhook-dnspod roc/cert-manager-webhook-dnspod \
-n cert-manager \
--set clusterIssuer.secretId=AKIDVt3z4uVss11xjIdmddgMmHXXssssHp9D2buxrWR8 \
--set clusterIssuer.secretKey=SekbG2gqdflQs5xxxviGagX8TYO \
--set clusterIssuer.email=xxx@xxx.xxx
3. 创立泛域名证书
# ipincloud-crt.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: ipincloud-crt
spec:
secretName: ipincloud-crt
issuerRef:
name: dnspod
kind: ClusterIssuer
group: cert-manager.io
dnsNames:
- "*.xxx.xxx"
创立集群证书颁布者:
$ kubectl apply -f ipincloud-crt.yaml -n infra
4. 验证证书
检查证书是否创立成功:
$ kubectl get Certificate -n cert-manager
NAME READY SECRET AGE
cert-manager-webhook-dnspod-ca True cert-manager-webhook-dnspod-ca 18m
cert-manager-webhook-dnspod-webhook-tls True cert-manager-webhook-dnspod-webhook-tls 18m
ipincloud-crt True ipincloud-crt 3m12s
以上能够看出 ipincloud-crt 现已创立成功, READY 状态也是 True。
检查证书对应的域名:
$ kubectl describe Certificate ipincloud-crt -n cert-manager
Name: ipincloud-crt
Namespace: cert-manager
Labels: <none>
Annotations: <none>
API Version: cert-manager.io/v1
Kind: Certificate
Metadata:
Creation Timestamp: 2022-05-07T14:19:07Z
...
Spec:
Dns Names:
*.xxx.xxx
Issuer Ref:
Group: cert-manager.io
Kind: ClusterIssuer
Name: dnspod
Secret Name: ipincloud-crt
Status:
Conditions:
Last Transition Time: 2022-05-07T14:19:14Z
Message: Certificate is up to date and has not expired
Observed Generation: 1
Reason: Ready
Status: True
Type: Ready
Not After: 2022-08-05T13:19:11Z
Not Before: 2022-05-07T13:19:12Z
Renewal Time: 2022-07-06T13:19:11Z
Revision: 1
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Issuing 4m35s cert-manager-certificates-trigger Issuing certificate as Secret does not exist
Normal Generated 4m35s cert-manager-certificates-key-manager Stored new private key in temporary Secret resource "ipincloud-crt-4ml59"
Normal Requested 4m35s cert-manager-certificates-request-manager Created new CertificateRequest resource "ipincloud-crt-r76wp"
Normal Issuing 4m28s cert-manager-certificates-issuing The certificate has been successfully issued
从 Certificate 的描述信息能够看到,这个证书是对应一切 *.xxx.xxx
的泛域名。
检查证书内容:
$ kubectl describe secret ipincloud-crt -n cert-manager
Name: ipincloud-crt
Namespace: cert-manager
Labels: <none>
Annotations: cert-manager.io/alt-names: *.xxx.xxx
cert-manager.io/certificate-name: ipincloud-crt
cert-manager.io/common-name: *.xxx.xxx
cert-manager.io/ip-sans:
cert-manager.io/issuer-group: cert-manager.io
cert-manager.io/issuer-kind: ClusterIssuer
cert-manager.io/issuer-name: dnspod
cert-manager.io/uri-sans:
Type: kubernetes.io/tls
Data
====
tls.crt: 5587 bytes
tls.key: 1675 bytes
TLS 证书保存在 cert-manager 命名空间里的 ipincloud-crt secret。能够供一切 “*.xxx.xxx` 的服务运用。
其他
这个过程中,遇到最大的坑是:我的集群运用了自建的 DNS 服务器,默许 cert-manager 会运用这个集群的自建 DNS SERVER 进行证书发行的验证,尽管经过调用 dnspod 的 webook 在 腾讯云 DNS 服务器上创立的 _acme-challenge 握手数据,可是在我的自建 DNS 里是查不到的,所以会一向卡 pending 状态。
$ kubectl get challenge -A
NAMESPACE NAME STATE DOMAIN AGE
cert-manager ipincloud-crt-f9kp6-381578565-136350475 pending xxx.xxx 24s
检查原因是:
Waiting for DNS-01 challenge propagation: DNS record for "xxx.xxx" not yet
$ kubectl -n cert-manager describe challenge ipincloud-crt-f9kp6-381578565-136350475
Name: ipincloud-crt-f9kp6-381578565-136350475
Namespace: cert-manager
Labels: <none>
Annotations: <none>
API Version: acme.cert-manager.io/v1
Kind: Challenge
---
中心略
---
Status:
Presented: true
Processing: true
Reason: Waiting for DNS-01 challenge propagation: DNS record for "xxx.xxx" not yet propagated
State: pending
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Started 41s cert-manager-challenges Challenge scheduled for processing
Normal Presented 39s cert-manager-challenges Presented challenge using DNS-01 challenge mechanism
查了许多材料,在官网上找到解决方案。办法是让 cert-manager 强制运用指定的 DNS 服务器进行握手验证。
我是用的是 helm 装置 cert-manager,所以增加一下 set 参数。
--set 'extraArgs={--dns01-recursive-nameservers-only,--dns01-recursive-nameservers=119.29.29.29:53\,8.8.8.8:53}'
参阅文档:cert-manager.io/docs/config…
装备证书仿制到其他 namespace
装置 kubed
$ helm repo add appscode https://charts.appscode.com/stable/
$ helm repo update
$ helm install kubed appscode/kubed \
--version v0.13.2 \
--namespace cert-manager
修正 Certificated 文件
为 certificated 对象设置 secretTemplate, 设置需求同步到哪些 namespace。
# ipincloud-crt.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: ipincloud-crt
spec:
secretName: ipincloud-crt
issuerRef:
name: dnspod
kind: ClusterIssuer
group: cert-manager.io
dnsNames:
- "*.xxx.xxx"
secretTemplate:
annotations:
kubed.appscode.com/sync: "cert-manager-tls=ipincloud-crt"
给需求同步的方针 namespace 打 label
上一步的 secretTemplate 里指定了同步的方针 namespace 的 label 过滤条件 cert-manager-tls=ipincloud-crt
, 因此,咱们需求对接收同步 secret 的 namespace 打上相应的 label。
$ kubectl label ns default cert-manager-tls=ipincloud-crt
$ kubectl label ns app cert-manager-tls=ipincloud-crt
$ kubectl label ns dev-app cert-manager-tls=ipincloud-crt
$ kubectl label ns dev-infra cert-manager-tls=ipincloud-crt
$ kubectl label ns dev-wly cert-manager-tls=ipincloud-crt
$ kubectl label ns infra cert-manager-tls=ipincloud-crt
$ kubectl label ns istio-system cert-manager-tls=ipincloud-crt
$ kubectl label ns uat-app cert-manager-tls=ipincloud-crt
$ kubectl label ns uat-wly cert-manager-tls=ipincloud-crt
$ kubectl label ns wly cert-manager-tls=ipincloud-crt
$ kubectl label ns kubesphere-controls-system cert-manager-tls=ipincloud-crt
检查是否仿制成功
检查方针 namespace 是否仿制 secret 成功。
$ kubectl get secret ipincloud-crt
NAME TYPE DATA AGE
ipincloud-crt kubernetes.io/tls 2 18m
检查仿制的 secret ,能够看到 label 信息中记载了证书来历信息。
$ kubectl describe secret ipincloud-crt
Name: ipincloud-crt
Namespace: default
Labels: kubed.appscode.com/origin.cluster=unicorn
kubed.appscode.com/origin.name=ipincloud-crt
kubed.appscode.com/origin.namespace=cert-manager
Annotations: cert-manager.io/alt-names: *.xxx.xxx
cert-manager.io/certificate-name: ipincloud-crt
cert-manager.io/common-name: *.xxx.xxx
cert-manager.io/ip-sans:
cert-manager.io/issuer-group: cert-manager.io
cert-manager.io/issuer-kind: ClusterIssuer
cert-manager.io/issuer-name: dnspod
cert-manager.io/uri-sans:
kubed.appscode.com/origin:
{"namespace":"cert-manager","name":"ipincloud-crt","uid":"b4713633-731e-4151-844f-0f6d9cf6352c","resourceVersion":"12531075"}
Type: kubernetes.io/tls
Data
====
tls.crt: 5587 bytes
tls.key: 1675 bytes
运用 TLS 证书装备 Ingress
设置 Ingress
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
name: wikijs
namespace: infra
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: '0'
spec:
ingressClassName: nginx
tls:
- hosts:
- wiki.xxx.xxx
secretName: ipincloud-crt
rules:
- host: wiki.xxx.xxx
http:
paths:
- path: /
pathType: ImplementationSpecific
backend:
service:
name: wikijs
port:
number: 3000
测验
以上装备完成后,就能够运用 HTTPS 来拜访新的 wiki.js 服务了。
$ curl -I https://wiki.xxx.xxx
HTTP/1.1 302 Found
Date: Sat, 07 May 2022 14:52:39 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 28
Connection: keep-alive
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-UA-Compatible: IE=edge
Referrer-Policy: same-origin
Content-Language: zh
Set-Cookie: loginRedirect=%2F; Max-Age=900; Path=/; Expires=Sat, 07 May 2022 15:07:39 GMT
Location: /login
Vary: Accept, Accept-Encoding
Strict-Transport-Security: max-age=15724800; includeSubDomains
如上所示,便是成功启动了 HTTPS 。
参阅
- artifacthub.io/packages/he…
- www.1nth.com/post/k8s-ce…
- cert-manager.io/docs/config…
本文由博客一文多发渠道 OpenWrite 发布!