• 延长自签名证书的寿命
    • 方案
    • 根转换过程
    • 问题排查
      • 为何工作负载无法获得新的证书?
      • 为何 Pilot 无法工作并输出 “handshake error” 日志?
      • 如何判断 Pilot 有 sidecar?
      • 为何我无法用 sidecar-injector 部署新的工作负载?
    • 相关内容

    延长自签名证书的寿命

    Istio 自签名证书历来具有 1 年的默认寿命。如果您使用 Istio 自签名证书,您需要注意根证书的到期日期。根证书的过期可能会导致集群范围内的意外中断。

    请参考下列步骤的第一步来计算您的根证书的剩余寿命。

    下列步骤将向您展示如何转换到一个新的根证书。转换完成后,新的根证书将有 10 年的寿命。注意 Envoy 实例将会热重启来重新加载新的根证书,这可能会对长连接造成影响。请参考这里和这里来了解这些影响和 Envoy 热重启的原理。

    方案

    如果您目前在 Istio 中没使用双向 TLS 功能,并且将来也没打算用,您将不受影响,也无需任何动作。

    如果您将来可能会使用双向 TLS 功能,您应该按照下列步骤来转换根证书。

    如果您选择已经在 Istio 中使用了带有自签名证书的双向 TLS 功能,请按照下列步骤检查您是否会受到影响。

    根转换过程

    • 检查根证书的过期时间:

    在一台有能访问集群的 kubectl 工具的机器上下载脚本。

    1. $ wget https://raw.githubusercontent.com/istio/tools/release-1.4/bin/root-transition.sh
    2. $ chmod +x root-transition.sh
    3. $ ./root-transition.sh check-root
    4. ...
    5. =====YOU HAVE 30 DAYS BEFORE THE ROOT CERT EXPIRES!=====

    在根证书过期之前执行剩下的步骤,以避免系统中断。

    • 检查您的 sidecars 的版本,如果需要就将它升级:

    一些早期的 Istio sidecar 版本不会自动重载新的根证书。请运行以下命令检查您的 Istio sidecars 的版本。

    1. $ ./root-transition.sh check-version
    2. Checking namespace: default
    3. Istio proxy version: 1.3.5
    4. Checking namespace: istio-system
    5. Istio proxy version: 1.3.5
    6. Istio proxy version: 1.3.5
    7. ...

    如果您的 sidecars 的版本低于 1.0.8 和 1.1.8,请升级 Istio 控制面板和 sidecars 的版本到不低于 1.0.8 和 1.1.8。请参考 Istio 升级步骤或您的云服务提供商提供的步骤来升级。

    • 执行根证书转换:

    在转换的过程中,Envoy sidecars 可能会热重启来重载新证书。这可能会影响您的流量。请参考 Envoy 热重启并阅读这篇博客来获得更多细节。

    如果您的 Pilot 没有配置 Envoy sidecar,考虑为它安装一个。因为 Pilot 在使用旧的根证书验证新的工作负载证书时有问题,这可能会导致 Pilot 与 Envoy 断开连接。如何检测该条件请参考这儿。Istio 升级指南默认会为 Pilot 安装 Envoy sidecar。

    1. $ ./root-transition.sh root-transition
    2. Create new ca cert, with trust domain as cluster.local
    3. Wed Jun 5 19:11:15 PDT 2019 delete old ca secret
    4. secret "istio-ca-secret" deleted
    5. Wed Jun 5 19:11:15 PDT 2019 create new ca secret
    6. secret/istio-ca-secret created
    7. pod "istio-citadel-8574b88bcd-j7v2d" deleted
    8. Wed Jun 5 19:11:18 PDT 2019 restarted Citadel, checking status
    9. NAME READY STATUS RESTARTS AGE
    10. istio-citadel-8574b88bcd-l2g74 1/1 Running 0 3s
    11. New root certificate:
    12. Certificate:
    13. Data:
    14. ...
    15. Validity
    16. Not Before: Jun 6 03:24:43 2019 GMT
    17. Not After : Jun 3 03:24:43 2029 GMT
    18. Subject: O = cluster.local
    19. ...
    20. Your old certificate is stored as old-ca-cert.pem, and your private key is stored as ca-key.pem
    21. Please save them safely and privately.
    • 确认新的工作负载证书已经创建:
    1. $ ./root-transition.sh verify-certs
    2. ...
    3. Checking the current root CA certificate is propagated to all the Istio-managed workload secrets in the cluster.
    4. Root cert MD5 is 8fa8229ab89122edba73706e49a55e4c
    5. Checking namespace: default
    6. Secret default.istio.default matches current root.
    7. Secret default.istio.sleep matches current root.
    8. Checking namespace: istio-system
    9. Secret istio-system.istio.default matches current root.
    10. ...
    11. =====All Istio mutual TLS keys and certificates match the current root!=====

    如果命令执行失败,请等一会重新执行。Citadel 传播证书需要一些时间。

    • 确认 Envoy 已经加载了新的工作负载证书:

    您可以确认 Envoy 是否已经收到新的证书。下面是如何检查 Envoy 中某个 pod 的证书的命令示例。

    1. $ kubectl exec [YOUR_POD] -c istio-proxy -n [YOUR_NAMESPACE] -- curl http://localhost:15000/certs | head -c 1000
    2. {
    3. "certificates": [
    4. {
    5. "ca_cert": [
    6. ...
    7. "valid_from": "2019-06-06T03:24:43Z",
    8. "expiration_time": ...
    9. ],
    10. "cert_chain": [
    11. {
    12. ...
    13. }

    请检查 ca_certvalid_from 的值。如果它能匹配上步骤 3 中显示的新证书的 Not Before 的值,那么您的 Envoy 已经加载了新的根证书。

    问题排查

    为何工作负载无法获得新的证书?

    请确定您已经在步骤 2 中将 istio-proxy sidecars 更新至 1.0.8,1.1.8 或更新版本。

    如果您使用 Istio 1.1.3 - 1.1.7 版本,Envoy 可能不会在新证书创建后热重启。

    为何 Pilot 无法工作并输出 “handshake error” 日志?

    这可能是因为启用 controlPlaneSecurity 后,Pilot 没有使用 Envoy sidecar。这种情况下,重启 Galley 和 Pilot 以保证他们加载了新的证书。下列命令会通过删除 pod 来重新部署 Galley 和 Pilot 的 pod 作为示例。

    1. $ kubectl delete po <galley-pod> -n istio-system
    2. $ kubectl delete po <pilot-pod> -n istio-system

    如何判断 Pilot 有 sidecar?

    如果下列命令显示 1/1,意味着您的 Pilot 没有 Envoy sidecar,否则,如果它显示 2/2,您的 Pilot 正在使用 Envoy sidecar。

    1. $ kubectl get po -l istio=pilot -n istio-system
    2. istio-pilot-569bc6d9c-tfwjr 1/1 Running 0 11m

    为何我无法用 sidecar-injector 部署新的工作负载?

    这可能是因为您没有升级到 1.0.8,1.1.8 或更新版本。试着重启 sidecar injector。重启后 sidecar injector 会重新加载证书:

    1. $ kubectl delete po -l istio=sidecar-injector -n istio-system
    2. pod "istio-sidecar-injector-788bd8fc48-x9gdc" deleted

    相关内容

    Extending Istio Self-Signed Root Certificate Lifetime

    Learn how to extend the lifetime of Istio self-signed root certificate.

    Change in Secret Discovery Service in Istio 1.3

    Taking advantage of Kubernetes trustworthy JWTs to issue certificates for workload instances more securely.

    Multi-mesh deployments for isolation and boundary protection

    Deploy environments that require isolation into separate meshes and enable inter-mesh communication by mesh federation.

    App Identity and Access Adapter

    Using Istio to secure multi-cloud Kubernetes applications with zero code changes.

    Istio 1.2.4 sidecar image vulnerability

    An erroneous 1.2.4 sidecar image was available due to a faulty release operation.

    Secure Control of Egress Traffic in Istio, part 3

    Comparison of alternative solutions to control egress traffic including performance considerations.