kubernetes 集群默认安装的证书是自签发证书,浏览器访问会发出安全提醒。
本文记录了利用 dnspod 、 cert-manager 、let’s encrytp 等开源组件,实现泛域名证书的自动生成、续期管理,为现有kubernetes 集群应用启动 HTTPS,提高系统安全性。
在 Kubernetes 集群中使用 HTTPS 协议,需要一个证书管理器、一个证书自动签发服务
cert-manager 是一个云原生证书管理开源项目,用于在 Kubernetes 集群中提供 HTTPS 证书并自动续期,支持 Let’s Encrypt, HashiCorp Vault 这些免费证书的签发。在Kubernetes集群中,我们可以通过 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支持以下几种证书颁发者
常用的校验方式有 HTTP-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 服务增加一个临时 location ,Let’s Encrypt 会发送 http 请求,参数中 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 。
这个配置示例仅供参考,使用这种方式,有多少的 ingress 服务,就需要申请多少张证书 ,比较麻烦,但是配置较为简单,不依赖 DNS 服务商。
证书管理器需要 Issuer 或 ClusterIssuer 资源,才能颁发证书。 这两种 Kubernetes 资源的功能完全相同,区别在于 Issuer 适用于单一命名空间,而 ClusterIssuer 适用于所有命名空间。
ClusterIssuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt
spec:
acme:
email: [email protected]
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: issuer-account-key
solvers:
- http01:
ingress:
class: nginx
说明:
kubectl apply -f ClusterIssuer.yaml -n cert-manager
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.xyz.cn
http:
paths:
- backend:
service:
name: wikijs
port:
number: 3000
path: /
pathType: Prefix
tls:
- hosts:
- wikijs.xyz.cn
secretName: ingress-wikijs-tls
注意:
在 annotations 里 设置cert-manager.io/cluster-issuer
为签名创建的集群证书颁发者 letsencrypt
使用 yaml 文件创建 ingress 后,就可以使用该 ingress 对外提供 https 服务了。
# 创建 ingress
kubectl apply -f ingress-wikijs.yaml -n infra
# 查看证书是否自动创建成功
kubectl -n infra get certificate
使用这种方式需要 DNS 服务商支持通过 API 创建 DNS 记录,正好我的 DNS 服务商是 dnspod 支持,因此在我们的及群里,最终采用了这种方式。
这个方式的配置会比较麻烦,踩了很久的坑,主要是因为我的集群启用了本地 DNS 服务器,默认 cert-manager 会通过本地 DNS 服务器去验证通过 API 创建的 DNS txt记录,会一直检查不到新增的 txt 记录,造成在 challenge 阶段就一直 pendding。解决方案附后。
参考dnspod 云官方文档
记录下创建的 API ID 和 API Token 。
使用 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= \
--set clusterIssuer.secretKey= \
--set [email protected]
xyz-crt.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: xyz-crt
spec:
secretName: xyz-crt
issuerRef:
name: dnspod
kind: ClusterIssuer
group: cert-manager.io
dnsNames:
- "*.xyz.cn"
创建集群证书颁发者
k apply -f xyz-crt.yaml -n infra
查看证书是否创建成功
[root@ks-master infra]# 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
xyz-crt True xyz-crt 3m12s
以上可以看出 xyz-crt 已经创建成功, READY 状态也是 True。
查看证书对应的域名
[root@ks-master infra]# kubectl describe Certificate xyz-crt -n cert-manager
Name: xyz-crt
Namespace: cert-manager
Labels:
Annotations:
API Version: cert-manager.io/v1
Kind: Certificate
Metadata:
Creation Timestamp: 2022-05-07T14:19:07Z
Generation: 1
Managed Fields:
API Version: cert-manager.io/v1
Fields Type: FieldsV1
fieldsV1:
f:status:
.:
f:conditions:
Manager: cert-manager-certificates-trigger
Operation: Update
Subresource: status
Time: 2022-05-07T14:19:07Z
API Version: cert-manager.io/v1
Fields Type: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.:
f:kubectl.kubernetes.io/last-applied-configuration:
f:spec:
.:
f:dnsNames:
f:issuerRef:
.:
f:group:
f:kind:
f:name:
f:secretName:
Manager: kubectl-client-side-apply
Operation: Update
Time: 2022-05-07T14:19:07Z
API Version: cert-manager.io/v1
Fields Type: FieldsV1
fieldsV1:
f:status:
f:revision:
Manager: cert-manager-certificates-issuing
Operation: Update
Subresource: status
Time: 2022-05-07T14:19:14Z
API Version: cert-manager.io/v1
Fields Type: FieldsV1
fieldsV1:
f:status:
f:conditions:
k:{"type":"Ready"}:
.:
f:lastTransitionTime:
f:message:
f:observedGeneration:
f:reason:
f:status:
f:type:
f:notAfter:
f:notBefore:
f:renewalTime:
Manager: cert-manager-certificates-readiness
Operation: Update
Subresource: status
Time: 2022-05-07T14:19:14Z
Resource Version: 4784901
UID: f2c9be82-f4cb-4243-b2c3-19f64242cc91
Spec:
Dns Names:
*.xyz.cn
Issuer Ref:
Group: cert-manager.io
Kind: ClusterIssuer
Name: dnspod
Secret Name: xyz-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 "xyz-crt-4ml59"
Normal Requested 4m35s cert-manager-certificates-request-manager Created new CertificateRequest resource "xyz-crt-r76wp"
Normal Issuing 4m28s cert-manager-certificates-issuing The certificate has been successfully issued
[root@ks-master infra]#
从 Certificate 的描述信息可以看到,这个证书是对应所有 *.xyz.cn 的泛域名。所以可以直接用在集群的任何地方。
查看证书内容
[root@ks-master infra]# kubectl describe secret xyz-crt -n cert-manager
Name: xyz-crt
Namespace: cert-manager
Labels:
Annotations: cert-manager.io/alt-names: *.xyz.cn
cert-manager.io/certificate-name: xyz-crt
cert-manager.io/common-name: *.xyz.cn
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 命名空间里的 xyz-crt secret。可以供所有 *.xyz.cn 的服务使用。
这个过程中,最大的坑是,我的集群使用了自建的 DNS 服务器,默认 cert-manager 会使用这个集群的自建 DNS SERVER 进行证书发行的验证,虽然通过调用 dnspod 的 webook 在 腾讯云 DNS 服务器上创建的 _acme-challenge 握手数据,但是在我的 自建 DNS 里是查不到的,所以会一直卡 pending 状态,
[root@ks-master infra]# kubectl get challenge -A
NAMESPACE NAME STATE DOMAIN AGE
cert-manager xyz-crt-f9kp6-381578565-136350475 pending xyz.cn 24s
查看原因是:
Waiting for DNS-01 challenge propagation: DNS record for "xyz.cn" not yet
[root@ks-master infra]# kcm describe challenge xyz-crt-f9kp6-381578565-136350475
Name: xyz-crt-f9kp6-381578565-136350475
Namespace: cert-manager
Labels:
Annotations:
API Version: acme.cert-manager.io/v1
Kind: Challenge
---
中间略
---
Status:
Presented: true
Processing: true
Reason: Waiting for DNS-01 challenge propagation: DNS record for "xyz.cn" 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}'
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.xyz.cn
secretName: xyz-crt
rules:
- host: wiki.xyz.cn
http:
paths:
- path: /
pathType: ImplementationSpecific
backend:
service:
name: wikijs
port:
number: 3000
以上配置完成后,就可以使用 https 来访问新的 wiki.js 服务了。