>What kind of traffic you are load-balancing?
>
>If your load-balancer only supports HTTP protocols, chances are that it
>is unable to utilize Kerberos over HTTPS either, so it cannot access any
>of IPA API end-points. It also means it cannot really validate IPA
>server HTTP end-points are working beyond a simple 'yes, it responded,
>with whatever status code'.
First of all, As i mentioned, our load balancer only supports HTTP protocol **for healthcheck,
And for traffic routing, the lb supports necessary protocols in IPA such as TCP, UDP.
We're using external passthrough network load balancer of GCP and configure routing protocol like below.
TCP
389, 636: LDAP/LDAPS
88, 464: kerberos
UDP
464: kerberos
And gcp team guide like below.
https://cloud.google.com/load-balancing/docs/network/networklb-target-pools?hl=ko#health_checks
"External passthrough Network Load Balancers rely on legacy HTTP health checks to determine instance health. Even if your service does not use HTTP, you must run a basic web server on each instance that the health check system can query.
Legacy HTTPS health checks aren't supported for external passthrough Network Load Balancers and cannot be used with most other types of load balancers."
https://cloud.google.com/load-balancing/docs/health-check-concepts#success-legacy-hc
"If the response received by the legacy health check probe is HTTP 200 OK, the probe is considered successful. All other HTTP response codes, including a redirect (301, 302), are considered unhealthy."
They guided that their NLB only support HTTP protocol for healthcheck and the healthcheck of NLB consider 'HTTP 200 OK' as healthy status.
So, we're finding the HTTP API with status code. (heatlthy : 200 / unhealty : whatever except 200)
Is there any API we can check the status of ipa servers?
>curl -X POST \ > -H 'Accept-Language: en' > --data '{"method":"i18n_messages", "params":[[],{}]}' \ > --referer https://ipa-server.hostname/ipa/ \ > https://ipa-server.hostname/ipa/i18n_messages
And when i ran the curl you mentioned, I got error message below.
"curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above."
Gahee Jung
--------- Original Message ---------
Sender : Alexander Bokovoy <[email protected]>
Date : 2024-10-22 16:39 (GMT+9)
Title : Re: [Freeipa-users] Inquery about ipa healthcheck api
On Аўт, 22 кас 2024, gahee jung via FreeIPA-users wrote:
>Hello,
>
>I would like to inquire about the healthcheck API of IPA.
>
>First of all, I set up 5 freeipa core servers and these core servers
>are located behind the load balancer. (to distribute clients' traffic)
>(* The freeipa version is v4.11)
FreeIPA team does not support putting load balancers in front of FreeIPA
servers. See, for example, https://protect2.fireeye.com/v1/url?k=8771a5b9-e6fab0fe-87702ef6-000babff99aa-6fefaea54ba1c0d7&q=1&e=32dd9e3d-44af-4666-8990-8dc52eed190c&u=http%3A%2F%2Fssimo.org%2Fblog%2Fid_019.html.
>And I am trying to configure the healthcheck method on my load balancer
>to avoid sending client's traffic to unhealthy server. I know that
>there is a command named 'ipa-healcheck' provied by freeipa. But, our
>load balancer only supports HTTP, HTTPS, and HTTP2 protocol for
>healthcheck. So I couldn't use ipa-healthcheck command for our load
>balancer.
>
>So, I tried to create additional API '/healthcheck' in httpd server.
>and each call to HTTP path /healthcheck will trigger a local execution
>of ipa-healthcheck command to return the status of all services.
> : ipa-healthcheck --source 'ipahealthcheck.meta.services' --all
>
>And today we just test using ipa-healthcheck command with rpcservers.
>But, Unfortunately, the CPU usage of the ipa-healthcheck command is
>pretty high (~80% CPU). So, we can not use this method for our
>healthcheck.
ipa-healthcheck is a tool to validate server's configuration. It is not
a tool to quickly check whether a system is running and answers your
calls.
It really depends on what you are trying to achieve here. IPA servers
are all-or-nothing services. E.g. if KDC does not work, all other
services should not be accessed on this host as well. If LDAP server
does not work, all other services should be considered inaccessible as
well.
What kind of traffic you are load-balancing?
>So, Could you let me know is there an API provided by Freeipa for
>healthcheck? or Please share me if there is a best way to configure
>healthcheck with HTTP protocol.
If your load-balancer only supports HTTP protocols, chances are that it
is unable to utilize Kerberos over HTTPS either, so it cannot access any
of IPA API end-points. It also means it cannot really validate IPA
server HTTP end-points are working beyond a simple 'yes, it responded,
with whatever status code'.
If you want a minimal non-authenticated response, may be do
curl -X POST \
-H 'Accept-Language: en'
--data '{"method":"i18n_messages", "params":[[],{}]}' \
--referer https://ipa-server.hostname/ipa/ \
https://ipa-server.hostname/ipa/i18n_messages
It would return JSON of translations used by the FreeIPA Web UI for the
chosen language ('en' in this case). It exercises IPA RPC infrastructure
but otherwise doesn't look at any system state.
If you'd do authentication using username/password, then that's going to
give you exercise of Kerberos + LDAP + IPA RPC infrastructure:
https://protect2.fireeye.com/v1/url?k=b3da1e34-d2510b73-b3db957b-000babff99aa-a079c75dcf4e71fa&q=1&e=32dd9e3d-44af-4666-8990-8dc52eed190c&u=https%3A%2F%2Ffreeipa.readthedocs.io%2Fen%2Flatest%2Fapi%2Fjsonrpc_usage.html%23password-authentication
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
|
-- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
