[Freeipa-devel] How to support Designate?

Wed Sep 2 14:09:07 UTC 2015

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?

>
> Simo.
>
>>> There may be limitations
>>> (like no DNSSEC available, no ability to create forward zones, no
>>> discovery location support or similar) but at least it should be
>>> possible to set the core names that are needed for client discovery and
>>> similar.
>>>
>>> Simo.
>>>
>>>>>>> It makes little to no sense to replicate stuff out of designate if we
>>>>>>> are not the master server.
>