[docs] Document PKI configuration for multihost pipelines. #5519
Conversation
There was a problem hiding this comment.
Pull request overview
Documents the PKI/HTTPS setup needed for single-host and multihost pipelines, clarifying that multihost is a preview/enterprise feature and introducing the private CA requirement for nested pod DNS names.
Changes:
- Expanded HTTPS documentation to cover wildcard certs (single-host) and private CA chains (multihost).
- Added docs notes indicating multihost pipelines are a preview feature in Enterprise.
- Updated Helm/Kubernetes secret instructions to include an optional CA secret (
caSecretRef) for multihost support.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| docs.feldera.com/docs/get-started/enterprise/https.md | Adds detailed guidance for wildcard certs + private CA chain and corresponding K8s secrets/Helm values. |
| docs.feldera.com/docs/architecture/enterprise.md | Notes multihost pipelines are a preview feature. |
| crates/feldera-types/src/config.rs | Documents hosts config as enterprise-only preview for multihost. |
| -in private_intermediate_tls.csr -CA private_root_tls.crt -CAkey private_root_tls.key \ | ||
| -CAcreateserial -out private_intermediate_tls.crt \ | ||
| -days 360 -sha256 \ | ||
| -extfile intermediate_x509_v3.ext -extensions x509_v |
There was a problem hiding this comment.
The OpenSSL invocation likely contains a typo: -extensions x509_v doesn’t match the [x509_v3] section name used earlier in intermediate_x509_v3.ext. This would cause OpenSSL to fail to apply the intended extensions. Use the same section name consistently (e.g., -extensions x509_v3).
| -extfile intermediate_x509_v3.ext -extensions x509_v | |
| -extfile intermediate_x509_v3.ext -extensions x509_v3 |
|
|
||
| ``` | ||
| openssl req -x509 -newkey rsa:4096 -nodes \ | ||
| -keyout private_root_tls.key -out private_root_tls.crt -days 365 \ |
There was a problem hiding this comment.
The root and intermediate CA validity periods are hard-coded (365/360 days) without explanation. Consider either aligning them (common practice is a longer-lived root) or briefly documenting why these values were chosen, so readers don’t cargo-cult short-lived CA lifetimes into production.
| openssl x509 -req \ | ||
| -in private_intermediate_tls.csr -CA private_root_tls.crt -CAkey private_root_tls.key \ | ||
| -CAcreateserial -out private_intermediate_tls.crt \ | ||
| -days 360 -sha256 \ |
There was a problem hiding this comment.
The root and intermediate CA validity periods are hard-coded (365/360 days) without explanation. Consider either aligning them (common practice is a longer-lived root) or briefly documenting why these values were chosen, so readers don’t cargo-cult short-lived CA lifetimes into production.
| ``` | ||
|
|
||
| 3. Provide in the Helm installation the reference for the | ||
| `httpsSecretRef` and, for multihost support, `caSecretRef`, value. |
There was a problem hiding this comment.
Minor grammar issue: “caSecretRef, value” should be plural (e.g., “values”) or rephrased (e.g., “set httpsSecretRef and (for multihost) caSecretRef”).
Signed-off-by: Ben Pfaff <[email protected]>
Signed-off-by: feldera-bot <[email protected]>
No description provided.