If you dont own the DNS service and records, then i am willing to bet
you dont own the load balancers and their configs, either. so the
hurdle to overcome, engaging another team/department when needing a
change, probably still exists.
depending on the autonomy you are given over your servers, you may have
the ability to stop advertising a route via the routing daemon in order
to bring the anycasted KDC service "out of the mix".
if you are able to run quagga, frr, bird or some other dynamic routing
daemon, it can inject the route to your KDC when operational, and remove
the route for maintenance, etc. this puts you in control of your own
destiny and makes the change control process entirely internal to your
team/department. plus it allows you to stand up an new KDC at will,
with little more that some collaboration with the team that manages the
routing for your organization.
i used to manage the caching forward proxies used for internet access by
my org, and was kicking around the idea of using anycast for the VIP on
the load balancer, and doing normal load balancing behind the box for
the proxies. the specifics are a bit different, the theory still holds,
for KDC vs HTTP and you could likely do the same depending on how
"enterprise grade" your load balancers are.
to me, the idea that names and IPs would never have to change for the
KDC services is the selling point for anycast. i brought up the idea
for anycast when the org i work for was moving data centers and we didnt
want to disrupt DNS services, or require thousands of servers to be
updated. for the proxies, it would have brought high availability
across multiple data centers and failure recovery would happen as fast
as the network could reconverge. given that apps usually use proxy host
and proxy port configs, having the same name point to physically,
geographically disparate footprints, with inherent prioritization by the
underlying network, would have save a lot of meantime-to-repair (MTTR)
minutes.
in Simo's blog, the idea of using only one SPN is what i have gone with
in nearly all my configs, but i have added the ability to use alternate
ports in order to access a single individual host running the service.
i still have the single name/IP on the VIP, but alternate ports dictate
which backend server you hit. i did this for the proxies at work, and
do it with MariaDB, Apache, OpenLDAP, and Squid at home. they are all
kerberized services, and i can talk to the pool of servers for scaling
and performance or talk to an individual daemon for diagnostics or other
specific intentions, all the while authenticating properly with kerberos
tickets.
best,
brendan
On 11/4/22 5:08 AM, Ronald Wimmer via FreeIPA-users wrote:
On 04.11.22 09:35, Alexander Bokovoy wrote:
On pe, 04 marras 2022, Ronald Wimmer via FreeIPA-users wrote:
On 09.06.22 11:56, Ronald Wimmer via FreeIPA-users wrote:
IPA heavily relies on DNS entries. In my opinion, this design makes
it more difficult to quickly disable one or more IPA servers -
especially when using IPA in combination with external DNS (managed
by a different department).
Would it be possible to put all relevant DNS entries on a
Loadbalancer VIP and let the LB resolve to all IPA servers?
e.g. instead of having 8 DNS entries for
_kerberos-master._tcp.linux.oebb.at for every of our 8 IPA servers
I would have just one _kerberos-master._tcp.linux.oebb.at entry.
The LB would distribute requests in such a setup.
Is it possible to do that or would it break some IPA functionality?
As the question came up again I would highly appreciate to hear from
the IPA developers.
IMHO using an enterprise grade load balancer would have several
advantages over DNS round robin.
If you want something like that, please invest your own time and share
results of it. It may sound harsh but there are multiple issues with
centralized load balancers when interacting with Kerberos services,
specifically on degrading an overall security of that solution. You'd
need to understand what you are getting into and whether a specific
solution is secure enough for your own situation. There is no general
guideline but some of the problems and hints how to address them are
available in this old but true post of Simo:
https://ssimo.org/blog/id_019.html
Thank you for pointing me to the interesting article on LoadBalancers
and Kerberos. I'll dig into that.
Cheers,
Ronald
_______________________________________________
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
_______________________________________________
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
