On 04/06/2016 10:44 AM, Dan Prince wrote:
On Tue, 2016-04-05 at 19:19 -0600, Rich Megginson wrote:
On 04/05/2016 07:06 PM, Dan Prince wrote:
On Sat, 2016-04-02 at 17:28 -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.
Would using Barbican to provide an API to manage the certificates
make
more sense for our deployment tooling? This could be useful for
both
undercloud and overcloud cases.
As for the rest of this, how invasive is the implementation of
FreeIPA.? Is this something that we can layer on top of an existing
deployment such that users wishing to use FreeIPA can opt-in.
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.
I was also able to run FreeIPA in a container on the undercloud
machine,
but this is, I think, not how we want to migrate to a container
based
strategy. It should be more deliberate.
While the ideal setup would be to install the IPA layer first,
and
create service users in there, this produces a different install
path
between with-FreeIPA and without-FreeIPA. Thus, I suspect the
right
approach is to run the overcloud deploy, then "harden" the
deployment
with the FreeIPA steps.
The IdM team did just this last summer in preparing for the Tokyo
summit, using Ansible and Packstack. The Rippowam project
https://github.com/admiyo/rippowam was able to fully lock down a
Packstack based install. I'd like to reuse as much of Rippowam
as
possible, but called from Heat Templates as part of an overcloud
deploy. I do not really want to re implement Rippowam in Puppet.
As we are using Puppet for our configuration I think this is
currently
a requirement. There are many good puppet examples out there of
various
servers and a quick google search showed some IPA modules are
available
as well.
I think most TripleO users are quite happy in using puppet modules
for
configuration in that the puppet openstack modules are quite mature
and
well tested. Making a one-off exception for FreeIPA at this point
doesn't make sense to me.
What about calling an ansible playbook from a puppet module?
Given our current toolset in TripleO having the ability to manage all
service configurations with a common language overrides any short cuts
that calling Ansible from Puppet would give you I think.
The best plan I think for IPA integration into the Over and underclouds
would be a puppet-freeipa module.
Puppet is fine. I have some feedback from the IPA side that the
https://github.com/purpleidea/puppet-ipa/ works ok. Work on it seems
to have tapered off last June, but we could revive.
So, big question: is Heat->ansible (instead of Puppet) for an
overcloud
deployment an acceptable path? We are talking Ansible 1.0
Playbooks,
which should be relatively straightforward ports to 2.0 when the
time
comes.
Thus, the sequence would be:
1. Run existing overcloud deploy steps.
2. Install IPA server on the allocated VM
3. Register the compute nodes and the controller as IPA clients
4. Convert service users over to LDAP backed services, complete
with
necessary kerberos steps to do password-less authentication.
5. Register all web services with IPA and allocate X509
certificates
for
HTTPS.
6. Set up Host based access control (HBAC) rules for SSH access
to
overcloud machines.
When we did the Rippowam demo, we used the Proton driver and
Kerberos
for securing the message broker. Since Rabbit seems to be the
tool
of
choice, we would use X509 authentication and TLS for
encryption. ACLs,
for now, would stay in the flat file format. In the future, we
might
chose to use the LDAP backed ACLs for Rabbit, as they seem far
more
flexible. Rabbit does not currently support Kerberos for either
authentication or encryption, but we can engage the upstream team
to
implement it if desired in the future, or we can shift to a
Proton
based
deployment if Kerberos is essential for a deployment.
There are a couple ongoing efforts that will tie in with this:
1. Designate should be able to use the DNS from FreeIPA. That
was
the
original implementation.
2. Juan Antonio Osorio has been working on TLS everywhere. The
issue
thus far has been Certificate management. This provides a Dogtag
server
for Certs.
3. Rob Crittenden has been working on auto-registration of
virtual
machines with an Identity Provider upon launch. This gives that
efforts
an IdM to use.
4. Keystone can make use of the Identity store for administrative
users
in their own domain.
5. Many of the compliance audits have complained about cleartext
passwords in config files. This removes most of them. MySQL
supports
X509 based authentication today, and there is Kerberos support in
the
works, which should remove the last remaining cleartext
Passwords.
I mentioned Centralized SUDO and HBAC. These are both tools that
may
be
used by administrators if so desired on the install. I would
recommend
that they be used, but there is no requirement to do so.
_________________________________________________________________
____
_____
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:un
subs
cribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___________________________________________________________________
_______
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsu
bscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_____________________________________________________________________
_____
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubs
cribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
