fix(kibana): use HTTPS for readiness check when kibana_tls is enabled#142
fix(kibana): use HTTPS for readiness check when kibana_tls is enabled#142
Conversation
The Kibana role's readiness probes hardcoded a plain `http://` curl against localhost:5601. With `kibana_tls: true` Kibana refuses HTTP, so the readiness check never satisfies `HTTP_CODE == 200|401` and the role times out. Switch the curl URL — and the task name — to `https` when `kibana_tls` is truthy, falling back to `http` otherwise. `-k` is already passed so self-signed or FreeIPA-issued certs work without extra CA wiring. Closes #141
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 49 minutes and 14 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
…stom_certs None of the existing molecule scenarios ran Kibana with web TLS turned on, so the HTTPS readiness regression in #141 would have slipped through CI. Flip kibana_tls: true in the two scenarios where it costs nothing extra: - kibana_custom_certs: reuse the test HTTP cert the scenario already generates as Kibana's server cert. Covers main.yml readiness on a fresh deploy and updates the verify to match (server.ssl.enabled is now expected; certificateAuthorities omission still holds since CA stays in the system trust store). - cert_renewal: turn TLS on in both the initial deploy and the renewal re-run. The renewal path notifies Restart Kibana, which covers restart_and_verify_kibana.yml — the only existing scenario that exercises that handler's readiness wait. Both verify steps flip to https:// with validate_certs: false (the CA is self-signed; the role's curl already uses -k for the same reason).
1 participant
Closes #141.
The Kibana readiness probe in
roles/kibana/tasks/main.ymland the matching one inroles/kibana/tasks/restart_and_verify_kibana.ymlboth curled a hardcodedhttp://localhost:5601/api/status. Withkibana_tls: trueKibana serves HTTPS only, so the probe never returned 200/401 and the role timed out. The fix switches the protocol (and the task name, for clarity) based onkibana_tls. Curl already uses-k, so self-signed or internal-CA certs work without extra wiring.None of the existing molecule scenarios deploy Kibana with
kibana_tls: true—kibana_custom_certsexplicitly opts out, with a comment that the in-container CA trust store is fiddly. I didn't spin up a new scenario for this (per CLAUDE.md, new scenarios are a last resort at ~10 min each), but happy to extend one in a follow-up if we want coverage for the TLS-on path.