feat: add gateway ingress tls setting#295
Conversation
gfyrag
commented
Jul 1, 2025
gfyrag
commented
- feat: add capability to explicitely enable tls at gateway level
- feat: add doc
WalkthroughThe documentation was updated to improve table formatting and add a new Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Gateway
participant Settings
participant Ingress
User->>Gateway: Create or update Gateway
Gateway->>withTls: Call with context and Gateway object
withTls->>Settings: Check "gateway.ingress.tls.enabled"
alt TLS explicitly configured
withTls->>Ingress: Set TLS using provided secret name
else TLS enabled via setting
withTls->>Ingress: Set TLS with default secret name
else TLS not enabled
withTls-->>Ingress: Do not set TLS
end
Suggested reviewers
Poem
✨ Finishing Touches
🧪 Generate Unit Tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
🚨 BugBot couldn't runBugBot is experiencing high demand right now. Try again in a few minutes by commenting "bugbot run" (requestId: serverGenReqId_7f560a54-6739-41d6-832c-641b68b39a9a). |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
docs/09-Configuration reference/01-Settings.md(2 hunks)internal/resources/gateways/ingress.go(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
internal/resources/gateways/ingress.go (5)
internal/core/context.go (1)
Context(10-16)api/formance.com/v1beta1/gateway_types.go (1)
Gateway(76-82)internal/core/utils.go (1)
ObjectMutator(70-70)internal/resources/settings/helpers.go (1)
GetBoolOrFalse(242-244)api/formance.com/v1beta1/stack_types.go (1)
Stack(77-83)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Tests
🔇 Additional comments (6)
docs/09-Configuration reference/01-Settings.md (2)
12-12: Minor table formatting improvement.The table separator formatting has been made more compact and consistent.
57-57: New TLS setting documentation looks accurate.The new
gateway.ingress.tls.enabledsetting is properly documented with correct type, example, and clear description that aligns with the implementation in the Go code.internal/resources/gateways/ingress.go (4)
50-50: Function signature updated to support configuration-based TLS enablement.The addition of the
ctx core.Contextparameter enables the function to access configuration settings, which is necessary for the new TLS enablement feature.
54-60: Good error handling and configuration retrieval.The implementation properly:
- Uses
GetBoolOrFalsewhich provides a safe default offalse- Handles errors from the settings retrieval
- Only enables TLS when explicitly configured via settings
141-141: Function call correctly updated with context parameter.The call to
withTlshas been properly updated to pass the required context parameter.
66-69: No outdated withTls calls foundI verified that all invocations of withTls use the updated signature (
withTls(ctx, gateway)). No calls with a single-parameter signature exist in the codebase.
| var secretName string | ||
| if gateway.Spec.Ingress.TLS == nil { | ||
| return nil | ||
| tlsEnabled, err := settings.GetBoolOrFalse(ctx, gateway.Spec.Stack, "gateway", "ingress", "tls", "enabled") | ||
| if err != nil { | ||
| return err | ||
| } | ||
| if !tlsEnabled { | ||
| return nil | ||
| } | ||
| secretName = gateway.Name + "-tls" | ||
| } else { | ||
| secretName = gateway.Spec.Ingress.TLS.SecretName | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify that default TLS secret will be available.
The new logic correctly implements configuration-based TLS enablement, but when TLS is enabled via settings, it generates a default secret name (gateway.Name + "-tls"). This assumes the secret will exist or be created by another process.
Please verify that the default TLS secret generation and management is handled properly:
🏁 Script executed:
#!/bin/bash
# Description: Check if there's any secret management logic for the default TLS secret name pattern
# Search for TLS secret creation or management logic
rg -A 5 -B 5 "tls.*secret|secret.*tls" --type go
# Search for specific pattern of default secret name generation
rg "\-tls" --type go
# Look for certificate or TLS secret management
ast-grep --pattern 'func $FUNC($_) {
$$$
SecretName: $_,
$$$
}'Length of output: 3571
Ensure default TLS secret is provisioned or created
The code now derives secretName = gateway.Name + "-tls" when TLS is enabled via settings, but there’s no logic in this package to actually create or validate that Kubernetes Secret. Without it, the Ingress will reference a non-existent secret and fail.
Please address this by either:
- Adding Secret creation logic (e.g. a
v1.Secretmanifest or integration with cert-manager) alongside the Ingress. - Or documenting clearly that users must provision a Secret named
<gateway.Name>-tlsbefore enabling TLS.
Location to update:
• internal/resources/gateways/ingress.go (around lines 52–64)
🤖 Prompt for AI Agents
In internal/resources/gateways/ingress.go around lines 52 to 64, the code sets
secretName to gateway.Name + "-tls" when TLS is enabled via settings but does
not create or validate the corresponding Kubernetes Secret. To fix this, add
logic to create or ensure the existence of the TLS Secret (for example, by
generating a v1.Secret manifest or integrating with cert-manager) before
referencing it in the Ingress, or alternatively add clear documentation stating
that users must manually provision a Secret named <gateway.Name>-tls prior to
enabling TLS.
2 participants
