[openstack-dev] [TripleO][CI] FreeIPA Deployment

Ben Nemec openstack at nemebean.com
Mon Aug 21 14:48:51 UTC 2017



On 08/21/2017 01:45 AM, Juan Antonio Osorio wrote:
> The second option seems like the most viable. Not sure how the TripleO 
> integration would go though. Care to elaborate on what you had in mind?

I can't remember if we discussed this when we were first implementing 
the ci job, but could FreeIPA run on the undercloud itself?  We could 
have the undercloud install process install FreeIPA before it does the 
rest of the undercloud install, and then the undercloud by default would 
talk to that local instance of FreeIPA.  We'd provide configuration 
options to allow use of a standalone server too, of course.

I feel like there was probably a reason we didn't do that in the first 
place (port conflicts?), but it would be the easiest option for 
deployers if we could make it work.

> 
> On Fri, Aug 18, 2017 at 9:11 PM, Emilien Macchi <emilien at redhat.com 
> <mailto:emilien at redhat.com>> wrote:
> 
>     On Fri, Aug 18, 2017 at 8:34 AM, Harry Rybacki <hrybacki at redhat.com
>     <mailto:hrybacki at redhat.com>> wrote:
>      > Greetings Stackers,
>      >
>      > Recently, I brought up a discussion around deploying FreeIPA via
>      > TripleO-Quickstart vs TripleO. This is part of a larger discussion
>      > around expanding security related CI coverage for OpenStack.
>      >
>      > A few months back, I added the ability to deploy FreeIPA via
>      > TripleO-Quickstart through three reviews:
>      >
>      > 1) Adding a role to deploy FreeIPA via OOOQ_E[1]
>      > 2) Providing OOOQ with the ability to deploy a supplemental node
>      > (alongside the undercloud)[2]
>      > 3) Update the quickstart-extras playbook to deploy FreeIPA[3]
>      >
>      >
>      > The reasoning behind this is as follows (copied from a conversation
>      > with jaosorior):
>      >
>      >> So the deal is that both the undercloud and the overcloud need
>     to be registered as a FreeIPA client.
>      >> This is because they need to authenticate to it in order to
>     execute actions.
>      >>
>      >> * The undercloud needs to have FreeIPA credentials because it's
>     running novajoin, which in turn
>      >> executes requests to FreeIPA in order to create service principals
>      >>  - The service principals are ultimately the service name and
>     the node name entries for which we'll
>      >> requests the certificates.
>      >> * The overcloud nodes need to be registered and authenticated to
>     FreeIPA (which right now happens > through a cloud-init script
>     provisioned by nova/nova-metadata) because that's how it requests
>      >> certificates.
>      >>
>      >> So the flow is as follows:
>      >>
>      >> * FreeIPA node is provisioned.
>      >>  - We'll appropriate credentials at this point.
>      >>  - We register the undercloud as a FreeIPA client and get an OTP
>     (one time password) for it
>      >> - We add the OTP to the undercloud.conf and enable novajoin.
>      >> * We trigger the undercloud install.
>      >>  - after the install, we have novajoin running, which is the
>     service that registers automatically the
>      >> overcloud nodes to FreeIPA.
>      >> * We trigger the overcloud deploy
>      >>  - We need to set up a flag that tells the deploy to pass
>     appropriate nova metadata (which tells
>      >> novajoin that the nodes should be registered).
>      >>  - profit!! we can now get certificates from the CA (and do
>     other stuff that FreeIPA allows you to do,
>      >> such as use kerberos auth, control sudo rights of the nodes'
>     users, etc.)
>      >>
>      >> Since the nodes need to be registered to FreeIPA, we can't rely
>     on FreeIPA being installed by
>      >> TripleO, even if that's possible by doing it through a
>     composable service.
>      >> If we would use a composable service to install FreeIPA, the
>     flow would be like this:
>      >>
>      >> * Install undercloud
>      >> * Install overcloud with one node (running FreeIPA)
>      >> * register undercloud node to FreeIPA and modify undercloud.conf
>      >> * Update undercloud
>      >> * scale overcloud and register the rest of the nodes to FreeIPA
>     through novajoin.
>      >>
>      >> So, while we could install FreeIPA with TripleO. This really
>     complicates the deployment to an
>      >> unnecessary point.
>      >>
>      >> So I suggest keeping the current behavior, which treats FreeIPA
>     as a separate node to be
>      >> provisioned before the undercloud). And if folks would like to
>     have a separate FreeIPA node for their > overcloud deployment (which
>     could provision certs for the tenants) then we could do that as a
>      >> composable service, if people request it.
>      >
>      > I am now re-raising this to the group at large for discussion about
>      > the merits of this approach vs deploying via TripleO itself.
> 
>     There are 3 approaches here:
> 
>     - Keep using Quickstart which is of course not the viable option since
>     TripleO Quickstart is only used by CI and developers right now. Not by
>     customers neither in production.
>     - Deploy your own Ansible playbooks or automation tool to deploy
>     FreeIPA and host it wherever you like. Integrate the playbooks in
>     TripleO, as an external component (can be deployed manually between
>     some steps but will be to be documented).
>     - Create a composable service that will deploy FreeIPA service(s),
>     part of TripleO Heat Templates. The way it works *now* will require
>     you to have a puppet-freeipa module to deploy the bits but we're
>     working toward migrating to Ansible at some point.
> 
> This approach is not ideal and will be quite a burdain as I described 
> above. I wouldn't consider this an option.
> 
> 
>     I hope it helps, let me know if you need further details on a
>     specific approach.
>     --
>     Emilien Macchi
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> -- 
> Juan Antonio Osorio R.
> e-mail: jaosorior at gmail.com <mailto:jaosorior at gmail.com>
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list