Kubernetes中运行的Java应用，自签名证书公钥应存于何处？

除了你提到的两种方案，还有以下几种可行的实现方式：

• 使用Kubernetes Secrets存储证书：虽然公钥敏感性较低，但Secrets支持集群级加密存储，比ConfigMap更适合存储证书类资产，挂载逻辑和ConfigMap一致，仅需将资源类型替换为Secret。
• 容器启动时动态导入证书：编写自定义启动脚本，在Java应用启动前通过keytool命令，将挂载的公钥导入到Java默认的cacerts信任库或自定义信任库。示例命令：

  keytool -importcert -file /path/to/mounted/cert.pem -alias my-custom-cert -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -noprompt
  

  将该命令集成到容器的ENTRYPOINT或CMD中，确保每次启动都完成证书导入，避免ConfigMap更新后未生效的问题。
• 集群级证书管理工具集成：如果组织有内部CA，可通过cert-manager这类工具将内部CA证书注入集群节点或容器的信任体系，Java应用直接继承系统信任链，无需单独配置。
• 挂载预配置的TrustStore文件：提前将所有需信任的自签证书导入到自定义TrustStore文件，再通过ConfigMap或Secrets挂载到容器，通过Java启动参数-Djavax.net.ssl.trustStore=/path/to/mounted/truststore.jks指定使用该信任库，跳过动态导入步骤。

关于你提到的方案2（ConfigMap挂载公钥），你所说的灵活性优势确实成立，但有几个容易遗漏的细节需要注意：

1. 文件权限问题：ConfigMap挂载的文件默认权限为644，需确保Java进程拥有读取权限，必要时可在volumeMounts中设置defaultMode: 0644，或在启动脚本中通过chmod调整。
2. 证书导入的必要性：Java不会自动识别并加载挂载的公钥文件，必须通过keytool命令手动导入到信任库，这一步必须集成到容器启动流程中，否则挂载证书也无法解决握手异常。
3. 证书更新的生效方式：更新ConfigMap后，容器内的挂载文件会自动更新，但Java应用不会实时重新加载信任库，必须重启容器才能让新证书生效，这一点需在运维流程中明确。
4. 多证书场景处理：若需信任多个自签证书，可在ConfigMap中存储多个证书文件，挂载到容器同一目录下，再在启动脚本中循环遍历目录内的所有证书逐个导入。
5. 默认信任库密码：Java默认cacerts的密码为changeit，若基础镜像修改过该密码，keytool命令需对应调整-storepass参数，否则会导入失败。

内容的提问来源于stack exchange，提问作者user15110545