作者: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.yamlapiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:  name: letsencryptspec:  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.yamlapiVersion: networking.k8s.io/v1kind: Ingressmetadata:  annotations:    cert-manager.io/cluster-issuer: letsencrypt    nginx.ingress.kubernetes.io/proxy-body-size: "0"  name: ingress-wikijsspec:  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 服务了。

# 执行创立 ingresskubectl 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

参考腾讯云官网文档(https://support.dnspod.cn/Kb/...)
记录下创立的 API ID 和 API Token (加码解决,须要自行获取本人的 API ID 和 API Token)。

AKIDVt3z4uVss11xjIdmddgMmHXXssssHp9D2buxrWR8SekbG2gqdflQs5xxxviGagX8TYO

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.yamlapiVersion: cert-manager.io/v1kind: Certificatemetadata:  name: ipincloud-crtspec:  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-managerNAME                                      READY   SECRET                                    AGEcert-manager-webhook-dnspod-ca            True    cert-manager-webhook-dnspod-ca            18mcert-manager-webhook-dnspod-webhook-tls   True    cert-manager-webhook-dnspod-webhook-tls   18mipincloud-crt                             True    ipincloud-crt                             3m12s

以上能够看出 ipincloud-crt 曾经创立胜利, READY 状态也是 True。

查看证书对应的域名:

$ kubectl describe Certificate ipincloud-crt -n cert-managerName:         ipincloud-crtNamespace:    cert-managerLabels:       <none>Annotations:  <none>API Version:  cert-manager.io/v1Kind:         CertificateMetadata:  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-crtStatus:  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:                1Events:  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-managerName:         ipincloud-crtNamespace:    cert-managerLabels:       <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/tlsData====tls.crt:  5587 bytestls.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 -ANAMESPACE      NAME                                       STATE     DOMAIN         AGEcert-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-136350475Name:         ipincloud-crt-f9kp6-381578565-136350475Namespace:    cert-managerLabels:       <none>Annotations:  <none>API Version:  acme.cert-manager.io/v1Kind:         Challenge---两头略---Status:  Presented:   true  Processing:  true  Reason:      Waiting for DNS-01 challenge propagation: DNS record for "xxx.xxx" not yet propagated  State:       pendingEvents:  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}'    

参考文档:https://cert-manager.io/docs/...

配置证书复制到其余 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.yamlapiVersion: cert-manager.io/v1kind: Certificatemetadata:  name: ipincloud-crtspec:  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-crtNAME            TYPE                DATA   AGEipincloud-crt   kubernetes.io/tls   2      18m

查看复制的 secret ,能够看到 label 信息中记录了证书起源信息。

$ kubectl describe secret ipincloud-crtName:         ipincloud-crtNamespace:    defaultLabels:       kubed.appscode.com/origin.cluster=unicorn              kubed.appscode.com/origin.name=ipincloud-crt              kubed.appscode.com/origin.namespace=cert-managerAnnotations:  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/tlsData====tls.crt:  5587 bytestls.key:  1675 bytes

应用 TLS 证书配置 Ingress

设置 Ingress

kind: IngressapiVersion: networking.k8s.io/v1metadata:  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.xxxHTTP/1.1 302 FoundDate: Sat, 07 May 2022 14:52:39 GMTContent-Type: text/plain; charset=utf-8Content-Length: 28Connection: keep-aliveX-Frame-Options: denyX-XSS-Protection: 1; mode=blockX-Content-Type-Options: nosniffX-UA-Compatible: IE=edgeReferrer-Policy: same-originContent-Language: zhSet-Cookie: loginRedirect=%2F; Max-Age=900; Path=/; Expires=Sat, 07 May 2022 15:07:39 GMTLocation: /loginVary: Accept, Accept-EncodingStrict-Transport-Security: max-age=15724800; includeSubDomains

如上所示,就是胜利启动了 HTTPS 。

参考

  • https://artifacthub.io/packag...
  • https://www.1nth.com/post/k8s...
  • https://cert-manager.io/docs/...

    本文由博客一文多发平台 OpenWrite 公布!