HPCC-34819 Document SSL/TLS setup for Containerized ESPs #20419
Conversation
Signed-off-by: Panagiotatos <greg.panagiotatos+copilot@lexisnexisrisk.com>
Signed-off-by: Panagiotatos <greg.panagiotatos+copilot@lexisnexisrisk.com>
There was a problem hiding this comment.
Pull Request Overview
This PR adds comprehensive documentation for SSL/TLS setup in containerized ESP deployments, addressing the gap between bare-metal and Kubernetes-based HPCC Platform installations. The documentation covers multiple SSL/TLS implementation approaches and provides practical configuration examples.
Key changes:
- Consolidates SSL/TLS certificate ownership and permissions documentation in the bare-metal installation guide
- Adds extensive SSL/TLS configuration section for containerized ESP deployments
- Documents ingress controller SSL termination, pod-level SSL, and cert-manager integration approaches
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| ssl-esp.xml | Consolidates certificate ownership documentation and adds section on converting HTTP to HTTPS service bindings |
| ConfigureValues.xml | Adds comprehensive SSL/TLS configuration documentation for containerized ESP deployments with examples and troubleshooting |
| <programlisting>esp: | ||
| - name: eclwatch | ||
| application: eclwatch | ||
| replicas: 1 | ||
| service: | ||
| port: 8010 | ||
| servicePort: 8010 | ||
| protocol: http | ||
| ingress: | ||
| enabled: true | ||
| annotations: | ||
| kubernetes.io/ingress.class: nginx | ||
| cert-manager.io/cluster-issuer: letsencrypt-prod | ||
| nginx.ingress.kubernetes.io/ssl-redirect: "true" | ||
| hosts: | ||
| - host: eclwatch.example.com | ||
| paths: | ||
| - path: / | ||
| pathType: Prefix | ||
| tls: | ||
| - secretName: eclwatch-tls | ||
| hosts: | ||
| - eclwatch.example.com |
There was a problem hiding this comment.
The ingress class annotation kubernetes.io/ingress.class is deprecated. Use spec.ingressClassName field instead or the newer annotation kubernetes.io/ingress.class should be replaced with ingressClassName: nginx in the spec section.
Copilot uses AI. Check for mistakes.
| https: | ||
| enabled: true | ||
| certificateSecretName: esp-tls-secret | ||
| # Optional: specify passphrase for encrypted private keys | ||
| # passphrase: "your-passphrase" | ||
| volumes: | ||
| - name: esp-certs | ||
| secret: | ||
| secretName: esp-tls-secret | ||
| volumeMounts: | ||
| - name: esp-certs | ||
| mountPath: /etc/ssl/esp | ||
| readOnly: true</programlisting> |
There was a problem hiding this comment.
The configuration references the same secret esp-tls-secret in both certificateSecretName and the volume definition, which creates redundancy. Consider documenting whether both are needed or if one approach is preferred over the other to avoid confusion.
Copilot uses AI. Check for mistakes.
| <varlistentry> | ||
| <term>Certificate Not Found</term> | ||
| <listitem> | ||
| <para>Verify the certificate secret exists in the correct namespace and contains both 'tls.crt' and 'tls.key' keys. Use <command>kubectl describe secret <secret-name></command> to inspect.</para> |
There was a problem hiding this comment.
The command uses HTML entity encoding for angle brackets (< and >) which may not render correctly in all documentation formats. Consider using backticks or code formatting instead: kubectl describe secret <secret-name>.
| <para>Verify the certificate secret exists in the correct namespace and contains both 'tls.crt' and 'tls.key' keys. Use <command>kubectl describe secret <secret-name></command> to inspect.</para> | |
| <para>Verify the certificate secret exists in the correct namespace and contains both 'tls.crt' and 'tls.key' keys. Use <command>kubectl describe secret <replaceable>secret-name</replaceable></command> to inspect.</para> |
Copilot uses AI. Check for mistakes.
|
Jira Issue: https://hpccsystems.atlassian.net//browse/HPCC-34819 Jirabot Action Result: |
There was a problem hiding this comment.
I cannot confirm the correctness, However, is there a scenario where the certificates are store in a vault? I ask because the platform supports retrieving secrets both from Kubernetes and from a vault. If certs can be store in a vault, that should be covered here. If not, it should be stated that only certs retrieved as a Kubernetes secret is supported.
Yes I think that's true. I'll confirm and add information if so. |
|
@g-pan this will need rebasing. |
Please review content carefully - Copilot was used extensively in writing this material
Examples are prone to hallucinations
@asselitx I believe that you maybe most familiar with this content to review,
please add any another reviewer as necessary.
Thank you.
Type of change:
Checklist:
Smoketest:
Testing:
see: https://github.com/g-pan/github-action-dev-build/actions/runs/17959821424