计划在 Vertica 和 Kafka 之间进行 TLS/SSL 加密

开始配置 TLS/SSL 之前需注意的一些事项：

  • 需要对调度程序、Vertica 和 Kafka 之间的哪些连接加密？在某些情况下，可能只需在 Vertica 与 Kafka 之间启用加密。当 Vertica 和 Kafka 群集位于不同的网络中时，这种情况很常见。例如，假设 Kafka 托管在云提供商处，而 Vertica 托管在您的内部网络中。那么，数据在两者之间必须穿过不安全的 Internet。但是，如果 Vertica 和调度程序都位于本地网络中，则可以断定不需要将其配置为使用 SSL/TLS。在其他情况下，需要对系统的所有部分进行加密。例如，当 Kafka、Vertica 和调度程序都托管在网络可能不安全的云提供商处时，需要对所有流量进行加密。

  • 需要信任调度程序、Vertica 和 Kafka 之间的哪些连接？如果一个系统无法验证另一个系统的身份，则可以选择将其中的任意连接设为失败。请参阅下面的验证身份。

  • 您将使用哪些 CA 对每个证书进行签名？配置调度程序、Kafka 和 Vertica 的最简单方法是使用同一 CA 对设置 TLS/SSL 时将使用的所有证书进行签名。使用同一根 CA 对证书进行签名时，需要能够编辑 Kafka、Vertica 和调度程序的配置。如果无法使用同一 CA 对所有证书进行签名，则所有信任库必须包含用于对证书进行签名的整个 CA 链（直到根 CA）。添加整个信任链可确保每个系统都可以验证彼此的身份。

验证身份

在 Vertica、调度程序和 Kafka 之间配置 TLS/SSL 加密时，主要挑战是确保调度程序、Kafka 和 Vertica 都可以验证彼此的身份。设置 TLS/SSL 加密时用户最常遇到的问题是，如何确保远程系统可以验证系统证书的真实性。防止出现此问题的最佳方法是，确保所有系统的证书均由所有系统明确信任的 CA 进行签名。

当一个系统尝试启动与另一个系统的加密连接时，它会将其证书发送到远程系统。此证书可由一个或多个帮助识别建立连接的系统的证书颁发机构 (CA) 进行签名。这些签名形成了“信任链”。一个证书由一个 CA 进行签名。反过来，该 CA 可能已由另一个 CA 进行签名，依此类推。通常，该链以来自知名商业证书提供商（例如 Comodo SSL 或 DigiCert）的 CA（称为根 CA）结束，默认情况下，这些证书在许多平台（例如操作系统和 Web 浏览器）上均受信任。

如果远程系统找到其信任的链中的某个 CA，则会验证建立连接的系统的身份，然后就可以继续建立连接。如果远程系统找不到其信任的 CA 的签名，则可能会阻止连接，具体取决于其配置。可以将系统配置为仅允许与身份已经过验证的系统建立的连接。