启用传输中加密时的最佳实践 - Amazon ElastiCache
在启用传输中加密之前：确保您正确处理 DNS 记录在传输中加密期间：注意迁移过程何时完成

启用传输中加密时的最佳实践

在启用传输中加密之前：确保您正确处理 DNS 记录

注意

在此过程中，我们正在更改和删除旧端点。不正确地使用端点可能会导致 Valkey 或 Redis OSS 客户端使用旧的和已删除的端点，从而使其无法连接到集群。

当集群从无 TLS 迁移到首选 TLS 时，旧的每节点 DNS 记录会被保留，并将以不同的格式生成新的每节点 DNS 记录。启用 TLS 的集群与未启用 TLS 的集群所使用的 DNS 记录格式不同。当集群配置为“加密模式：首选”时，ElastiCache 将保留这两种 DNS 记录，以便应用程序和其他 Valkey 或 Redis OSS 客户端可以在它们之间切换。在 TLS 迁移过程中，DNS 记录发生以下更改：

启用传输中加密时发生的 DNS 记录更改的描述

对于 CME 集群

当集群设置为“传输加密模式：首选”时：

  • 未启用 TLS 的集群的原始集群端点将保持活动状态。将集群从 TLS 加密模式“无”重新配置为“首选”时，不会出现停机。

  • 当集群设置为首选 TLS 模式时，将生成新的 TLS Valkey 或 Redis OSS 端点。这些新端点将解析为与旧端点（非 TLS）相同的 IP。

  • 新的 TLS Valkey 或 Redis OSS 配置端点将在 ElastiCache 控制台和对 describe-replication-group API 的响应中公开。

当集群设置为“传输加密模式：需要”时：

  • 将删除未启用 TLS 的旧端点。TLS 集群端点将不会停机。

  • 您可以从 ElastiCache 控制台或 describe-replication-group API 检索新的 cluster-configuration-endpoint 文件。

对于启用了自动失效转移或禁用了自动失效转移的 CMD 集群

当复制组设置为“传输加密模式：首选”时：

  • 未启用 TLS 的集群的原始主端点和读取器端点将保持活动状态。

  • 当集群设置为 TLS Preferred 模式时，将生成新的 TLS 主端点和读取器端点。此新端点将解析为与旧端点（非 TLS）相同的 IP。

  • 新的主端点和读取器端点将在 ElastiCache 控制台和对 describe-replication-group API 的响应中公开。

当复制组设置为“传输加密模式：需要”时：

  • 将删除旧的非 TLS 主端点和读取器端点。TLS 集群端点将不会停机。

  • 您可以从 ElastiCache 控制台或 describe-replication-group API 检索新的主端点和读取器端点。

DNS 记录的建议用法

对于 CME 集群

  • 在应用程序代码中使用集群配置端点，而不是每节点 DNS 记录。不建议直接使用每节点 DNS 名称，因为在添加或删除分片时它们可能会发生变化。

  • 不要在应用程序中对集群配置端点进行硬编码，因为在此过程中此端点会发生变化。

  • 在应用程序中对集群配置端点进行硬编码是一种不好的做法，因为在此过程中可能会对此端点进行更改。传输中加密完成后，使用 describe-replication-group API 查询集群配置端点 [如上所示（粗体）]，然后从此时起使用从响应中获得的 DNS。

对于启用了自动失效转移的 CMD 集群

  • 在应用程序代码中使用主端点和读取器端点而不是每节点 DNS 名称，因为将集群从无 TLS 迁移到首选 TLS 时，会删除旧的每节点 DNS 名称并生成新的 DNS 名称。不建议直接使用每节点 DNS 名称，因为将来您可能会向集群添加副本。此外，启用自动失效转移后，ElastiCache 服务会自动更改主集群和副本的角色，建议使用主端点和读取器端点来帮助您跟踪这些更改。最后，使用读取器端点将帮助您在集群中的副本之间平均分配从副本进行的读取操作。

  • 在应用程序中对主端点和读取器端点进行硬编码是不好的做法，因为在 TLS 迁移过程中可能会对端点进行更改。完成向首选 TLS 的迁移更改后，使用 describe-replication-group API 查询主端点和读取器端点，然后从此时起使用从响应中获得的 DNS。这样，您将能够以动态方式跟踪端点的变化。

对于禁用了自动失效转移的 CMD 集群

  • 在应用程序的代码中使用主端点和读取器端点，而不是每节点 DNS 名称。禁用自动失效转移时，启用自动失效转移时由 ElastiCache 服务自动管理的扩缩、修补、失效转移以及其他过程将改为由您完成。这使您能够更轻松地手动跟踪不同的端点。由于在将集群从无 TLS 迁移到首选 TLS 时，会删除旧的每节点 DNS 名称并生成新的每节点 DNS 名称，因此请勿直接使用每节点 DNS 名称。这一点是强制性的，以便客户端能够在 TLS 迁移期间连接到集群。此外，在使用读取器端点时会在副本之间均匀分布读取操作，并且在集群中添加或删除副本时会跟踪 DNS 记录，因此您将受益匪浅。

  • 在应用程序中对集群配置端点进行硬编码是一种不好的做法，因为在 TLS 迁移过程中可能会对端点进行更改。

在传输中加密期间：注意迁移过程何时完成

传输加密模式的更改并非立即生效，而可能需要一些时间。对于大型集群而言，这种情况尤其如此。只有当集群完成向首选 TLS 的迁移后，集群才能接受和提供 TCP 和 TLS 连接。因此，在传输中加密完成之前，不应创建尝试与集群建立 TLS 连接的客户端。

有几种方法可以在传输中加密成功完成或失败时获得通知：（未显示在上面的代码示例中）：

  • 使用 SNS 服务在加密完成时收到通知

  • 使用将在加密完成后发出事件的 describe-events API

  • 在 ElastiCache 控制台中看到一条表明加密已完成的消息

您还可以在应用程序中实现逻辑以了解加密是否已完成。在上面的示例中，我们看到了几种确保集群完成迁移的方法：

  • 等到迁移过程开始（集群状态更改为“正在修改”），然后等到修改完成（集群状态变回为“可用”）

  • 通过查询 describe-replication-group API 断言集群已将 transit_encryption_enabled 设置为 True。

启用传输中加密后：确保正确配置了您使用的客户端

当集群处于首选 TLS 模式时，您的应用程序应建立与集群的 TLS 连接并仅使用这些连接。这样，在启用传输中加密时，应用程序就不会出现停机。您可以使用 SSL 部分下的 info 命令，确保与 Valkey 或 Redis OSS 引擎之间没有更清晰的 TCP 连接。

# SSL
ssl_enabled:yes
ssl_current_certificate_not_before_date:Mar 20 23:27:07 2017 GMT
ssl_current_certificate_not_after_date:Feb 24 23:27:07 2117 GMT
ssl_current_certificate_serial:D8C7DEA91E684163
tls_mode_connected_tcp_clients:0   (should be zero)
tls_mode_connected_tls_clients:100