On 04/05/2016 09:01 AM, Steven Hardy wrote:
On Tue, Apr 05, 2016 at 02:07:06PM +0300, Juan Antonio Osorio wrote:
On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy <sha...@redhat.com> wrote:
On Sat, Apr 02, 2016 at 05:28:57PM -0400, Adam Young wrote:
> I finally have enough understanding of what is going on with Tripleo
to
> reasonably discuss how to implement solutions for some of the main
security
> needs of a deployment.
>
>
> FreeIPA is an identity management solution that can provide support
for:
>
> 1. TLS on all network communications:
>Â Â A. HTTPS for web services
>Â Â B. TLS for the message bus
>Â Â C. TLS for communication with the Database.
> 2. Identity for all Actors in the system:
>  A. API services
>  B. Message producers and consumers
>  C. Database consumers
>  D. Keystone service users
> 3. Secure DNS DNSSEC
> 4. Federation Support
> 5. SSH Access control to Hosts for both undercloud and overcloud
> 6. SUDO management
> 7. Single Sign On for Applications running in the overcloud.
>
>
> The main pieces of FreeIPA are
> 1. LDAP (the 389 Directory Server)
> 2. Kerberos
> 3. DNS (BIND)
> 4. Certificate Authority (CA) server (Dogtag)
> 5. WebUI/Web Service Management Interface (HTTPD)
>
> Of these, the CA is the most critical. Without a centralized CA, we
have no
> reasonable way to do certificate management.
>
> Now, I know a lot of people have an allergic reaction to some, maybe
all, of
> these technologies. They should not be required to be running in a
> development or testbed setup. But we need to make it possible to
secure an
> end deployment, and FreeIPA was designed explicitly for these kinds of
> distributed applications. Here is what I would like to implement.
>
> Assuming that the Undercloud is installed on a physical machine, we
want to
> treat the FreeIPA server as a managed service of the undercloud that
is then
> consumed by the rest of the overcloud. Right now, there are conflicts
for
> some ports (8080 used by both swift and Dogtag) that prevent a drop-in
run
> of the server on the undercloud controller. Even if we could
deconflict,
> there is a possible battle between Keystone and the FreeIPA server on
the
> undercloud. So, while I would like to see the ability to run the
FreeIPA
> server on the Undercloud machine eventuall, I think a more realistic
> deployment is to build a separate virtual machine, parallel to the
overcloud
> controller, and install FreeIPA there. I've been able to modify
Tripleo
> Quickstart to provision this VM.
IMO these services shouldn't be deployed on the undercloud - we only
support a single node undercloud, and atm it's completely possible to
take
the undercloud down without any impact to your deployed cloud (other
than
losing the ability to manage it temporarily).
This is fair enough, however, for CI purposes, would it be acceptable to
deploy it there? Or where do you recommend we have it?
We're already well beyond capacity in CI, so to me this seems like
something that's probably appropriate for a third-party CI job?
To me it just doesn't make sense to integrate these pieces on the
undercloud, and integrating it there just because we need it available for
CI purposes seems like a poor argument, because we're not testing a
representative/realistic environment.
If we have to wire this in to TripleO CI I'd favor spinning up an extra
node with the FreeIPA pieces in, e.g a separate Heat stack (so, e.g the
nonha job takes 3 nodes, a "freeipa" stack of 1 and an overcloud of 2).
So, this is actually what I proposed. If you reread my original, put
the emphasis on the first part:
"Assuming that the Undercloud is installed on a physical machine, we
want to treat the FreeIPA server as a managed service of the undercloud
that is then consumed by the rest of the overcloud." Running it on the
Undercloud machine was only
"I would like ... ability ... eventually"
As I said, with quickstart, I have the ability to deploy an additional
VM and throw IPA on there. I have it all set with Ansible. This
machine could avoid using Puppet itself.
But, it is possible to install IPA using Puppet, and we could do that
too, its just new code to be written.
The ability to run with an existing IPA server is also important. Either
way, though, what is important is that IPA be available, or we lose the
Certificate management. So, for CI, I would like to drive on with
running it this way.
There are a couple one efforts to make this happen out there;
https://github.com/purpleidea/puppet-ipa
https://forge.puppetlabs.com/huit/ipa
Steve
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
