On 04/06/2016 10:38 AM, Hayes, Graham wrote:
On 06/04/2016 17:17, Rich Megginson wrote:
On 04/06/2016 02:55 AM, Hayes, Graham wrote:
On 06/04/16 03:09, Adam Young wrote:
On 04/05/2016 08:02 AM, Hayes, Graham wrote:
On 02/04/2016 22:33, 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)
<snip>
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.
Designate cannot use FreeIPA - we haven't had a driver for it since
Kilo.
There have been various efforts since to support FreeIPA, but it
requires that it is the point of truth for DNS information, as does
Designate.
If FreeIPA supported the traditional Notify and Zone Transfer mechanisms
then we would be fine, but unfortunately it does not.
[1] Actually points out that the goal of FreeIPA's DNS integration
"... is NOT to provide general-purpose DNS server. Features beyond
easing FreeIPA deployment and maintenance are explicitly out of scope."
1 - http://www.freeipa.org/page/DNS#Goals
Lets table that for now. No reason they should not be able to
interoperate somehow.
Without work being done by FreeIPA (to enable the XFR interface on the
bind server) or us (Designate) re-designing our DNS Driver interface
they will not be able to inter-operate.
It's going to be very difficult for FreeIPA to support XFR for the
"main" zone (i.e. the zone in which records are actively
updated/maintained in LDAP and kept in sync globally). It might be
possible to make it work for a child/sub zone that LDAP doesn't have to
pay much attention to, and let that zone be updated by Designate via
XFR. I suppose Designate has the same problem with AD DNS integration?
Yes, we do. The MS DNS server has support for other secondary zones
that we could use - that is what we did in the pre Kilo driver.
(as a disclaimer, the msdns driver is known-broken, and unless there
is some resurgence of interest in it it will be deleted soon.)
If you want to discuss this more, we can take the discussion to
[email protected]
Will spin up a thread there - thanks.
The ipa/nova join functionality allows new VM hosts to be automatically
registered with IPA, including the DNS records for floating IP
assignments, bypassing Designate.
Ah, I did not realise there was work done on that. There was quite a bit
of work done this cycle to tie nova + neutron + designate together by
adding a "dns_name" to neutron ports - that is what we focused on.
The work that was done for nova/ipa integration:
* is specific to ipa - it uses ipa specific apis, files, commands, etc.
* does a lot more than just DNS registration - it configures the system
to allow ssh into the system, to allow kerberos auth, HBAC including
based on hostgroup, etc. - this is the demo I did for OpenStack Tokyo:
http://richmegginson.livejournal.com/27573.html
Rob Crittenden, Juan Osorio Robles, and Adam Young have helped with this
effort and have extended it since then.
It unfortunately relies on unsupported internal nova apis (hooks), and
there will be a discussion in Austin about how to do this going forward.
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: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
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
