Linkerd 2.10 系列

Linkerd 2.10 中文手册持续修正更新中：

自动轮换控制平面 TLS 凭证

Linkerd 的自动 mTLS 功能使用一组 TLS 凭据(TLS credentials)为代理生成 TLS 证书(TLS certificates)：

信任锚(trust anchor)、颁发者证书(issuer certificate)和私钥(private key)。

虽然 Linkerd 每 24 小时自动轮换数据平面代理的 TLS 证书，

但它不会轮换用于颁发这些证书的 TLS 凭据。

在本文档中，我们将描述如何使用外部解决方案

自动轮换颁发者证书和私钥。

(请注意，Linkerd 的信任锚仍然必须在 long-lived 集群上手动轮换)

Cert manager

Cert-manager

是一个流行的项目，用于使来自外部来源的 TLS 凭证(TLS credentials)可用于 Kubernetes 集群。

第一步，在您的集群上安装

cert-manager。

如果您要安装 cert-manager >= 1.0，

则需要 kubernetes >= 1.16。

cert-manager 中用于 kubernetes <= 1.15

的传统自定义资源定义没有 keyAlgorithm 选项，

因此证书将使用 RSA 生成并且与 linkerd 不兼容。

有关版本要求的更多详细信息，请参阅 v0.16 到 v1.0 升

级说明。

Cert manager 作为集群上的证书颁发机构(CA)

在这种情况下，我们不会从外部来源(external source)获取凭据，

而是将其配置为集群上的

CA，

并让它定期重新颁发 Linkerd 的颁发者证书(issuer certificate)和私钥(private key)。

首先，创建 cert-manager 将用来存储其 Linkerd 相关资源的命名空间。

为简单起见，我们建议使用默认的 Linkerd 控制平面命名空间：

  1. kubectl create namespace linkerd

将签名密钥对(signing key pair)保存为 Secret

接下来，使用 step 工具，

创建一个签名密钥对(signing key pair)并将其存储在上面创建的

命名空间中的 Kubernetes Secret 中：

  1. step certificate create root.linkerd.cluster.local ca.crt ca.key \
  2.   --profile root-ca --no-password --insecure &&
  3.   kubectl create secret tls \
  4.     linkerd-trust-anchor \
  5.     --cert=ca.crt \
  6.     --key=ca.key \
  7.     --namespace=linkerd

对于寿命更长(longer-lived)的信任锚证书，将 --not-after 参数传递

给具有所需值(desired value)的 step 命令（例如 --not-after=87600h）。

创建引用密钥(referencing the secret)的颁发者(Issuer)

有了 Secret，我们可以创建一个引用它的 cert-manager "Issuer" 资源：

  1. cat <<EOF | kubectl apply -f -
  2. apiVersion: cert-manager.io/v1
  3. kind: Issuer
  4. metadata:
  5.   name: linkerd-trust-anchor
  6.   namespace: linkerd
  7. spec:
  8.   ca:
  9.     secretName: linkerd-trust-anchor
  10. EOF

颁发证书(Issuing certificates)并将它们写入一个 secret

最后，我们可以创建一个 cert-manager "Certificate" 资源，

它使用这个 Issuer 来生成所需的证书：

  1. cat <<EOF | kubectl apply -f -
  2. apiVersion: cert-manager.io/v1
  3. kind: Certificate
  4. metadata:
  5.   name: linkerd-identity-issuer
  6.   namespace: linkerd
  7. spec:
  8.   secretName: linkerd-identity-issuer
  9.   duration: 48h
  10.   renewBefore: 25h
  11.   issuerRef:
  12.     name: linkerd-trust-anchor
  13.     kind: Issuer
  14.   commonName: identity.linkerd.cluster.local
  15.   dnsNames:
  16.   - identity.linkerd.cluster.local
  17.   isCA: true
  18.   privateKey:
  19.     algorithm: ECDSA
  20.   usages:
  21.   - cert sign
  22.   - crl sign
  23.   - server auth
  24.   - client auth
  25. EOF

（在上面的 YAML 清单中，duration key 指示 cert-manager 将

证书视为有效 48 小时，而 renewBefore key 指示

cert-manager 将尝试在当前证书到期前 25 小时颁发新证书。

这些值可以根据您的喜好定制。）

此时，cert-manager 现在可以使用此证书资源(Certificate resource)

获取 TLS 凭据(TLS credentials)，

该凭据将存储在名为 linkerd-identity-issuer 的 secret 中。

要验证您新颁发的证书，您可以运行：

  1. kubectl get secret linkerd-identity-issuer -o yaml -n linkerd

现在我们只需要通知 Linkerd 使用这些凭据。

由于 cert-manager 中的

bug，

如果您将 cert-manager 版本 0.15 与实验控制器(experimental controllers)一起使用，

则它颁发的证书与 Linkerd 版本 <= stable-2.8.1 不兼容。

您的 linkerd-identity pod 可能会因以下日志输出而崩溃：

  1. "Failed to initialize identity service: failed to read CA from disk:
  2. unsupported block type: 'PRIVATE KEY'"

解决此问题的一些可能方法是：

  • 将 Linkerd 升级到包含修复程序的边缘版本 >= edge-20.6.4。
  • 将 cert-manager 升级到版本 >= 0.16。（如何升级）
  • 关闭 cert-manager 实验控制器(experimental controllers)。(docs)

替代 CA 提供商

您可以将 Cert Manager 配置为依赖于许多其他解决方案，

例如 Vault，

而不是使用 Cert Manager 作为 CA。

可以在此处找到

有关如何设置现有证书管理器

以使用不同类型的颁发者的更多详细信息。

第三方证书管理解决方案

需要注意的是，Linkerd 提供的机制也可以在 cert-manager 之外使用。

Linkerd 将读取 linkerd-identity-issuer Secret，

如果它是 kubernetes.io/tls 类型，将使用内容作为其 TLS 凭证(TLS credentials)。

这意味着任何能够通过将 TLS 证书(certificates)写入此密钥

来轮换它们的解决方案都可用于提供动态 TLS 证书管理。

在 CLI 安装中使用这些凭据

对于 CLI 安装，Linkerd 控制平面应该

与 --identity-external-issuer 标志一起安装，

该标志指示 Linkerd 从 linkerd-identity-issuer secret 读取证书。

每当更新存储在 secret 中的 certificate 和 key 时，

identity 服务将自动检测此更改并重新加载新凭据。

瞧！我们已经设置了 Linkerd 控制平面 TLS 凭据的自动轮换。

如果你想监控更新过程，你可以检查服务发出的 IssuerUpdated 事件：

  1. kubectl get events --field-selector reason=IssuerUpdated -n linkerd

使用 Helm 安装

对于 Helm 安装，而不是运行 linkerd install，

将 identityTrustAnchorsPEM 设置为

linkerd-identity-issuer Secret 中 ca.crt 的值：

  1. helm install linkerd2 \
  2.   --set-file identityTrustAnchorsPEM=ca.crt \
  3.   --set identity.issuer.scheme=kubernetes.io/tls \
  4.   --set installNamespace=false \
  5.   linkerd/linkerd2 \
  6.   -n linkerd

对于低于 v3 的 Helm 版本，必须专门传递 --name 标志。

在 Helm v3 中，它已被弃用，并且是上面指定的第一个参数。

自动轮换 Webhook TLS 凭证

Linkerd 控制平面包含几个组件，称为 webhooks，

由 Kubernetes 本身直接调用。

从 Kubernetes 到 Linkerd webhooks 的流量使用 TLS 进行保护，

因此每个 webhooks 都需要一个包含 TLS 凭据的 secret。

这些证书与 Linkerd 代理用于保护 pod 到 pod 通信并

使用完全独立的信任链的证书不同。

默认情况下，当 Linkerd 与 Linkerd CLI 或 Linkerd Helm chart 一起安装时，

会自动为所有 webhook 生成 TLS 凭据。

如果这些证书过期或因任何原因需要重新生成，

执行 Linkerd upgrade（使用 Linkerd CLI 或使用 Helm）将重新生成它们。

此工作流程适用于大多数用户。

但是，如果您需要定期自动轮换这些 webhook 证书，

则可以使用 cert-manager 来自动管理它们。

安装 Cert manager

第一步，在

您的集群上安装 cert-manager

并创建 cert-manager 将用于存储其 webhook 相关资源的命名空间。

为简单起见，我们建议使用默认命名空间 linkerd 使用：

  1. # control plane core
  2. kubectl create namespace linkerd
  4. # viz (ignore if not using the viz extension)
  5. kubectl create namespace linkerd-viz
  7. # viz (ignore if not using the jaeger extension)
  8. kubectl create namespace linkerd-jaeger

将签名密钥对(signing key pair)保存为 Secret

接下来，我们将使用 step

工具创建一个签名密钥对(signing key pair)，用于对每个 webhook 证书进行签名：

  1. step certificate create webhook.linkerd.cluster.local ca.crt ca.key \
  2.   --profile root-ca --no-password --insecure --san webhook.linkerd.cluster.local
  4. kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd
  6. # ignore if not using the viz extension
  7. kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd-viz
  9. # ignore if not using the jaeger extension
  10. kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd-jaeger

创建引用 secrets 的发行者(Issuers)

有了 Secrets，我们就可以创建引用它们的 cert-manager "Issuer" 资源：

  1. cat <<EOF | kubectl apply -f -
  2. apiVersion: cert-manager.io/v1
  3. kind: Issuer
  4. metadata:
  5.   name: webhook-issuer
  6.   namespace: linkerd
  7. spec:
  8.   ca:
  9.     secretName: webhook-issuer-tls
  10. ---
  11. # ignore if not using the viz extension
  12. apiVersion: cert-manager.io/v1
  13. kind: Issuer
  14. metadata:
  15.   name: webhook-issuer
  16.   namespace: linkerd-viz
  17. spec:
  18.   ca:
  19.     secretName: webhook-issuer-tls
  20. ---
  21. # ignore if not using the jaeger extension
  22. apiVersion: cert-manager.io/v1
  23. kind: Issuer
  24. metadata:
  25.   name: webhook-issuer
  26.   namespace: linkerd-jaeger
  27. spec:
  28.   ca:
  29.     secretName: webhook-issuer-tls
  30. EOF

颁发证书并将其写入 secrets

最后，我们可以创建 cert-manager "Certificate" 资源，

它使用颁发者(Issuers)来生成所需的证书：

  1. cat <<EOF | kubectl apply -f -
  2. apiVersion: cert-manager.io/v1
  3. kind: Certificate
  4. metadata:
  5.   name: linkerd-proxy-injector
  6.   namespace: linkerd
  7. spec:
  8.   secretName: linkerd-proxy-injector-k8s-tls
  9.   duration: 24h
  10.   renewBefore: 1h
  11.   issuerRef:
  12.     name: webhook-issuer
  13.     kind: Issuer
  14.   commonName: linkerd-proxy-injector.linkerd.svc
  15.   dnsNames:
  16.   - linkerd-proxy-injector.linkerd.svc
  17.   isCA: false
  18.   privateKey:
  19.     algorithm: ECDSA
  20.   usages:
  21.   - server auth
  22. ---
  23. apiVersion: cert-manager.io/v1
  24. kind: Certificate
  25. metadata:
  26.   name: linkerd-sp-validator
  27.   namespace: linkerd
  28. spec:
  29.   secretName: linkerd-sp-validator-k8s-tls
  30.   duration: 24h
  31.   renewBefore: 1h
  32.   issuerRef:
  33.     name: webhook-issuer
  34.     kind: Issuer
  35.   commonName: linkerd-sp-validator.linkerd.svc
  36.   dnsNames:
  37.   - linkerd-sp-validator.linkerd.svc
  38.   isCA: false
  39.   privateKey:
  40.     algorithm: ECDSA
  41.   usages:
  42.   - server auth
  43. ---
  44. # ignore if not using the viz extension
  45. apiVersion: cert-manager.io/v1
  46. kind: Certificate
  47. metadata:
  48.   name: tap
  49.   namespace: linkerd-viz
  50. spec:
  51.   secretName: tap-k8s-tls
  52.   duration: 24h
  53.   renewBefore: 1h
  54.   issuerRef:
  55.     name: webhook-issuer
  56.     kind: Issuer
  57.   commonName: tap.linkerd-viz.svc
  58.   dnsNames:
  59.   - tap.linkerd-viz.svc
  60.   isCA: false
  61.   privateKey:
  62.     algorithm: ECDSA
  63.   usages:
  64.   - server auth
  65. ---
  66. # ignore if not using the viz extension
  67. apiVersion: cert-manager.io/v1
  68. kind: Certificate
  69. metadata:
  70.   name: linkerd-tap-injector
  71.   namespace: linkerd-viz
  72. spec:
  73.   secretName: tap-injector-k8s-tls
  74.   duration: 24h
  75.   renewBefore: 1h
  76.   issuerRef:
  77.     name: webhook-issuer
  78.     kind: Issuer
  79.   commonName: tap-injector.linkerd-viz.svc
  80.   dnsNames:
  81.   - tap-injector.linkerd-viz.svc
  82.   isCA: false
  83.   privateKey:
  84.     algorithm: ECDSA
  85.   usages:
  86.   - server auth
  87. ---
  88. # ignore if not using the jaeger extension
  89. apiVersion: cert-manager.io/v1
  90. kind: Certificate
  91. metadata:
  92.   name: jaeger-injector
  93.   namespace: linkerd-jaeger
  94. spec:
  95.   secretName: jaeger-injector-k8s-tls
  96.   duration: 24h
  97.   renewBefore: 1h
  98.   issuerRef:
  99.     name: webhook-issuer
  100.     kind: Issuer
  101.   commonName: jaeger-injector.linkerd.svc
  102.   dnsNames:
  103.   - jaeger-injector.linkerd.svc
  104.   isCA: false
  105.   privateKey:
  106.     algorithm: ECDSA
  107.   usages:
  108.   - server auth
  109. EOF

此时 cert-manager 现在可以使用这些 Certificate resources 来获取 TLS 凭证，

这些凭证分别存储在 linkerd-proxy-injector-k8s-tls、linkerd-sp-validator-k8s-tls、tap- k8s-tls、tap-injector-k8s-tls 和 jaeger-injector-k8s-tls 这些 secrets 中。

现在我们只需要通知 Linkerd 使用这些凭据。

在 CLI 安装中使用这些凭据

要将 Linkerd 配置为使用来自 cert-manager 的凭据而不是生成自己的凭据，

我们生成了一个补充配置文件：

  1. CA=$(awk '{ print "    " $0 }' ca.crt)
  3. cat > config.yml <<EOF
  4. proxyInjector:
  5.   externalSecret: true
  6.   caBundle: |
  7. $CA
  8. profileValidator:
  9.   externalSecret: true
  10.   caBundle: |
  11. $CA
  12. EOF
  14. # ignore if not using the viz extension
  15. cat > config-viz.yml <<EOF
  16. tap:
  17.   externalSecret: true
  18.   caBundle: |
  19. $CA
  20. tapInjector:
  21.   externalSecret: true
  22.   caBundle: |
  23. $CA
  24. EOF
  26. # ignore if not using the jaeger extension
  27. cat > config-jaeger.yml <<EOF
  28. webhook:
  29.   externalSecret: true
  30.   caBundle: |
  31. $CA
  32. EOF

现在我们可以使用这些配置文件安装 Linkerd：

  1. linkerd install --values=config.yml | kubectl apply -f -
  3. # ignore if not using the viz extension
  4. linkerd viz install --values=config-viz.yml | kubectl apply -f -
  6. # ignore if not using the jaeger extension
  7. linkerd jaeger install --values=config-jaeger.yml | kubectl apply -f -

使用 Helm 安装

对于 Helm 安装，我们可以直接配置 Helm 值：

  1. helm install linkerd2 \
  2.   --set installNamespace=false \
  3.   --set proxyInjector.externalSecret=true \
  4.   --set-file proxyInjector.caBundle=ca.crt \
  5.   --set profileValidator.externalSecret=true \
  6.   --set-file profileValidator.caBundle=ca.crt \
  7.   linkerd/linkerd2 \
  8.   -n linkerd
  10. # ignore if not using the viz extension
  11. helm install linkerd-viz \
  12.   --set installNamespace=false \
  13.   --set tap.externalSecret=true \
  14.   --set-file tap.caBundle=ca.crt \
  15.   --set tapInjector.externalSecret=true \
  16.   --set-file tapInjector.caBundle=ca.crt \
  17.   linkerd/linkerd-viz \
  18.   -n linkerd-viz
  20. # ignore if not using the jaeger extension
  21. helm install linkerd-jaeger \
  22.   --set installNamespace=false \
  23.   --set webhook.externalSecret=true \
  24.   --set-file webhook.caBundle=ca.crt \
  25.   linkerd/linkerd-jaeger \
  26.   -n linkerd-jaeger

使用 Helm 安装 Linkerd 时，

您还必须提供颁发者信任根(issuer trust root)和颁发者凭据(issuer credentials)，

如使用 Helm 安装 Linkerd 中所述。

对于低于 v3 的 Helm 版本，必须专门传递 --name 标志。

在 Helm v3 中，它已被弃用，并且是上面指定的第一个参数。

  1. 我是为少
  2. 微信：uuhells123
  3. 公众号：黑客下午茶
  4. 加我微信（互相学习交流），关注公众号（获取更多学习资料~）

Linkerd 2.10(Step by Step)—3. 自动轮换控制平面 TLS &Webhook TLS 凭证的更多相关文章

  1. Linkerd 2.10(Step by Step)—4. 如何配置外部 Prometheus 实例

    Linkerd 2.10 系列 快速上手 Linkerd v2 Service Mesh(服务网格) 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traefik2 ...

  2. Linkerd 2.10(Step by Step)—使用 Kustomize 自定义 Linkerd 的配置

    Linkerd 2.10 系列 快速上手 Linkerd v2 Service Mesh(服务网格) 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traefik2 ...

  3. Linkerd 2.10(Step by Step)—多集群通信

    Linkerd 2.10 系列 快速上手 Linkerd v2.10 Service Mesh(服务网格) 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traef ...

  4. Linkerd 2.10(Step by Step)—将 GitOps 与 Linkerd 和 Argo CD 结合使用

    Linkerd 2.10 系列 快速上手 Linkerd v2.10 Service Mesh(服务网格) 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traef ...

  5. Linkerd 2.10(Step by Step)—控制平面调试端点

    Linkerd 2.10 系列 快速上手 Linkerd v2 Service Mesh(服务网格) 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traefik2 ...

  6. Linkerd 2.10(Step by Step)—配置超时

    Linkerd 2.10 系列 快速上手 Linkerd v2 Service Mesh(服务网格) 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traefik2 ...

  7. Linkerd 2.10(Step by Step)—配置重试

    Linkerd 2.10 系列 快速上手 Linkerd v2 Service Mesh(服务网格) 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traefik2 ...

  8. Linkerd 2.10(Step by Step)—配置代理并发

    Linkerd 2.10 系列 快速上手 Linkerd v2 Service Mesh(服务网格) 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traefik2 ...

  9. Linkerd 2.10(Step by Step)—使用 Debug Sidecar，注入调试容器来捕获网络数据包

    Linkerd 2.10 系列 快速上手 Linkerd v2.10 Service Mesh 腾讯云 K8S 集群实战 Service Mesh-Linkerd2 & Traefik2 部署 ...

随机推荐

  1. erase

    erase详细解释及原理 我们先定义一个字符串string string.erase(iterator) iterator表示要删除元素的迭代器. string.erase(it_begin,it_e ...

  2. python里面的多进程实例

    python执行多任务方式:python语言中实现多任务的方式有三种:线程,进程和协程 一.python多进程: multiprocessing         概念:Python提供了非常好用的多进 ...

  3. Qt Creator内qmake配置静态编译

    起因 利用QT Creator编写一些纯C/C++应用,默认配置下是动态编译 解决 解决起来很简单,这里只是附上配置备忘;-) msvc: { QMAKE_CFLAGS_RELEASE += /MT ...

  4. edraw mindmaster pro 8.1.0安装破解教程

    Edraw MindMaster Pro 8.1.0是一款思维导图(脑图)设计软件,头脑风暴.思维整理.项目策划.团队协作,多场景提升您的效率,功能齐全,个人觉得比xmind好用上手,文章手把手教你安 ...

  5. switch-case例题

    根据订单的状态码打印对应的汉字状态(使用switch-case)1-等待付款 2-等待发货 3-运输中 4-已签收 5-已取消 其它-无法追踪 var n='2' switch(n){ case 1: ...

  6. 计算机网络笔记Part1 概述

    总目录 1.计算机网络的功能.组成.分类 1.1功能 数据通信 资源共享 分布式处理 提高可靠性 负载均衡 1.2组成部分 硬件 软件 协议 1.3分类 按分布范围 广域网 WAN 城域网 MAN 局 ...

  7. Java流程控制01——用户交互Scanner

    用户交互Scanner sacnner对象 之前的语法并没有实现程序与人的交互.java.util.Scanner是Java5的新特征,我们可以通过Scanner类来获取用户的输入. 基本语法:  S ...

  8. Windows协议 LDAP篇 - 域权限

    windows 访问控制模型 也就是大名鼎鼎的ACM,access control mode 由两部分组成的. 访问令牌(access tokens) 其中包含有关登录用户的信息(User SID,G ...

  9. 走心的中级Android工程师跳槽经验分享

    这些经验是我最近四个月,从准备面试到找到合适工作的汗水和泪水,希望对你们能有帮助! define 跳槽 跳槽前要思考的问题 钱不到位怎么办 心委屈怎么办 离职前的思考 确定要走时需要做的准备 行情怎么 ...

  10. 接口的调用Client测试

    先占坑,明天记录 看了个寂寞,哈哈哈