[Freeipa-devel] How to support Designate?

[Simo Sorce]

On Wed, 2015-09-02 at 08:09 -0600, Rich Megginson wrote:
> On 09/02/2015 08:07 AM, Simo Sorce wrote:
> > On Wed, 2015-09-02 at 08:00 -0600, Rich Megginson wrote:
> >> On 09/01/2015 07:34 AM, Simo Sorce wrote:
> >>> On Tue, 2015-09-01 at 07:17 -0600, Rich Megginson wrote:
> >>>> On 09/01/2015 05:39 AM, Petr Spacek wrote:
> >>>>> On 1.9.2015 00:42, Rich Megginson wrote:
> >>>>>> On 08/31/2015 11:00 AM, Simo Sorce wrote:
> >>>>>>> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote:
> >>>>>>>> On 08/31/2015 01:35 AM, Petr Spacek wrote:
> >>>>>>>>> On 26.8.2015 20:09, Rich Megginson wrote:
> >>>>>>>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote:
> >>>>>>>>>>> On 8.7.2015 19:56, Rich Megginson wrote:
> >>>>>>>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote:
> >>>>>>>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it
> >>>>>>>>>>>>> would be
> >>>>>>>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136)
> >>>>>>>>>>>>> alongside their own JSON API.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add
> >>>>>>>>>>>>> zones
> >>>>>>>>>>>>> but still, standard protocol would mean that standard client (possibly
> >>>>>>>>>>>>> guest
> >>>>>>>>>>>>> OS inside VM) can update its records without any OpenStack dependency,
> >>>>>>>>>>>>> which
> >>>>>>>>>>>>> is very much desirable.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The use case here is to allow the guest OS to publish it's SSH key
> >>>>>>>>>>>>> (which was
> >>>>>>>>>>>>> generated inside the VM after first boot) to prevent Man in the middle
> >>>>>>>>>>>>> attacks.
> >>>>>>>>>> I'm working on a different approach for guest OS registration.  This
> >>>>>>>>>> involves
> >>>>>>>>>> a Nova hook/plugin:
> >>>>>>>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the
> >>>>>>>>>> OTP - add OTP to new host metadata - add ipa-client-registration script
> >>>>>>>>>> to new
> >>>>>>>>>> host cloud-init
> >>>>>>>>>> * new instance calls script - will wait for OTP to become available in
> >>>>>>>>>> metadata, then call ipa-client-install with OTP
> >>>>>>>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with
> >>>>>>>>>> new IP
> >>>>>>>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported.
> >>>>>>>>> ipa-client-install is using DNS UPDATE today.
> >>>>>>>> I already have to support the IPA JSON REST interface with kerberos
> >>>>>>>> credentials to do the host add, so it is easy to support dsrecord-add.
> >>>>>>>>
> >>>>>>>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova
> >>>>>>>>>>
> >>>>>>>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service
> >>>>>>>>>>>>> discovery using DNS, where a guest/container running a distributed
> >>>>>>>>>>>>> service
> >>>>>>>>>>>>> can
> >>>>>>>>>>>>> publish it's existence in DNS.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is
> >>>>>>>>>>>>> widely supported, too.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So DNS UPDATE is my biggest wish :-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Ok.  There was a Designate blueprint for such a feature, but I can't
> >>>>>>>>>>>> find it
> >>>>>>>>>>>> and neither can the Designate guys.  There is a mention of nsupdate in the
> >>>>>>>>>>>> minidns blueprint, but that's about it.  The fact that Designate upstream
> >>>>>>>>>>>> can't find the bp suggests that this is not a high priority for them
> >>>>>>>>>>>> and will
> >>>>>>>>>>>> not likely implement it on their own i.e. we would have to contribute this
> >>>>>>>>>>>> feature.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If Designate had such a feature, how would this help us integrate
> >>>>>>>>>>>> FreeIPA with
> >>>>>>>>>>>> Designate?
> >>>>>>>>>>> It would greatly simplify integration with FreeIPA. There is a plan to
> >>>>>>>>>>> support
> >>>>>>>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA
> >>>>>>>>>>> servers to
> >>>>>>>>>>> external DNS servers, so we could use the same code to integrate with AD &
> >>>>>>>>>>> Designate at the same time.
> >>>>>>>>>>>
> >>>>>>>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.)
> >>>>>>>>>>>
> >>>>>>>>>> For Designate for our use cases, we want IPA to be the authoritative
> >>>>>>>>>> source of
> >>>>>>>>>> DNS data.
> >>>>>>>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is
> >>>>>>>>> built around assumption that there is only one authoritative source of data
> >>>>>>>>> and as far as I can tell all attempts to bend this assumption did not end
> >>>>>>>>> well.
> >>>>>>>> But what about users/operators who want to integrate OpenStack with
> >>>>>>>> their existing DNS deployment (e.g. IPA or AD)?  Will they allow
> >>>>>>>> converting their IPA/AD DNS to be a replica of Designate?
> >>>>>>> No, they would not want to, or have no permissions to do so.
> >>>>>>> But that shouldn't be a big issue, designate will probably be made to
> >>>>>>> manage a completely unrelated namespace.
> >>>>>>>
> >>>>>>>> This seems to
> >>>>>>>> be the obverse of most of the ways OpenStack is integrated into existing
> >>>>>>>> deployments.  For example, for Keystone Identity, you don't configure
> >>>>>>>> Keystone to be the authoritative source of data for identity, then
> >>>>>>>> configure IPA or AD to be a replica of Keystone.  You configure Keystone
> >>>>>>>> to use IPA/AD for its identity information.
> >>>>>>> Indeed.
> >>>>>>>
> >>>>>>>>> In my eyes IPA should have ability to integrate with whatever DNS server
> >>>>>>>>> admin
> >>>>>>>>> wants to use, using standard protocols.
> >>>>>>>> Does this mean the best way to support Designate will be to change IPA
> >>>>>>>> DNS so that it can be a replica of Designate, and get its data via AXFR
> >>>>>>>> from Designate?
> >>>>>>> No, we should probably just make it possible for IPA to talk to
> >>>>>>> designate to add the necessary records. If Designate is in use, the IPA
> >>>>>>> DNS will not be in use and turned off.
> >>>>>> Then why use IPA at all?  Would be much simpler for the user to stand up a
> >>>>>> PowerDNS or BIND9 which are supported out of the box.
> >>>>> Yes, that is basically what I'm saying :-) In my eyes IPA should integrate
> >>>>> with whatever DNS server you want to use, be it Designate or anything else. If
> >>>>> we have such integration then there is no point in doing two-way
> >>>>> synchronization between IPA DNS and <whatever> DNS.
> >>>> What does "integration" mean in this context, if it doesn't mean
> >>>> synchronization or zone transfers?
> >>> It means that the IPA framework operates directly no an external DNS
> >>> server instead of using its own.
> >> So this is the same as the case where a customer already has DNS and
> >> wants to use it, and we tell them how to set up their DNS with the
> >> records that IPA needs?
> > No it goes beyond that, we have the framework enabled to do changes to
> > the DNS.
> >
> >>> This means we can still have automatic
> >>> changes in DNS w/o using the integrated one.
> >> How?
> > nsupdate as the simplest integration option, perhaps plugin with use of
> > native APIs if available.
> 
> I'm assuming this option does not exist currently.  Is there a freeipa 
> ticket for this?

https://fedorahosted.org/freeipa/ticket/4424

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York