Re: [openstack-dev] [TripleO] FreeIPA integration

[Fox, Kevin M]

Yeah, the console can be used as a building block to solve it. I'm just saying 
we should formalize the plumbing enough that it can be relied upon by everyone, 
instead of asking everyone to reinvent the wheel. Thats partially what the 
spec's about.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Thursday, April 07, 2016 6:33 AM
To: openstack-dev
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration

Excerpts from Adam Young's message of 2016-04-05 19:02:58 -0700:
> On 04/05/2016 11:42 AM, Fox, Kevin M wrote:
> > Yeah, and they just deprecated vendor data plugins too, which
> > eliminates my other workaround. :/
> >
> > We need to really discuss this problem at the summit and get a viable
> > path forward. Its just getting worse. :/
> >
> > Thanks,
> > Kevin
> > 
> > *From:* Juan Antonio Osorio [jaosor...@gmail.com]
> > *Sent:* Tuesday, April 05, 2016 5:16 AM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
> >
> >
> >
> > On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <kevin@pnnl.gov
> > <mailto:kevin@pnnl.gov>> wrote:
> >
> > This sounds suspiciously like, "how do you get a secret to the
> > instance to get a secret from the secret store" issue :)
> >
> > Yeah, sounds pretty familiar. We were using the nova hooks mechanism
> > for this means, but it was deprecated recently. So bummer :/
> >
> >
> > Nova instance user spec again?
> >
> > Thanks,
> > Kevin
> >
>
> Yep, and we need a solution.  I think the right solution is a keypair
> generated on the instance, public key posted by the instace to the
> hypervisor and stored with the instance data in the database.  I wrote
> that to the mailing list earlier today.
>

If you log your public SSH host key to the console, this already
happens. No need for hypervisor magic, just scrape your console.

__
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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Clint Byrum]

Excerpts from Adam Young's message of 2016-04-05 19:02:58 -0700:
> On 04/05/2016 11:42 AM, Fox, Kevin M wrote:
> > Yeah, and they just deprecated vendor data plugins too, which 
> > eliminates my other workaround. :/
> >
> > We need to really discuss this problem at the summit and get a viable 
> > path forward. Its just getting worse. :/
> >
> > Thanks,
> > Kevin
> > 
> > *From:* Juan Antonio Osorio [jaosor...@gmail.com]
> > *Sent:* Tuesday, April 05, 2016 5:16 AM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
> >
> >
> >
> > On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <kevin@pnnl.gov 
> > <mailto:kevin@pnnl.gov>> wrote:
> >
> > This sounds suspiciously like, "how do you get a secret to the
> > instance to get a secret from the secret store" issue :)
> >
> > Yeah, sounds pretty familiar. We were using the nova hooks mechanism 
> > for this means, but it was deprecated recently. So bummer :/
> >
> >
> > Nova instance user spec again?
> >
> > Thanks,
> > Kevin
> >
> 
> Yep, and we need a solution.  I think the right solution is a keypair 
> generated on the instance, public key posted by the instace to the 
> hypervisor and stored with the instance data in the database.  I wrote 
> that to the mailing list earlier today.
> 

If you log your public SSH host key to the console, this already
happens. No need for hypervisor magic, just scrape your console.

__
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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Adam Young]

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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Rich Megginson]

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)





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
freeipa-us...@redhat.com

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.

Re: [openstack-dev] [TripleO] FreeIPA integration

[Hayes, Graham]

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)
>


> 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
> freeipa-us...@redhat.com

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.

>>
>>

> 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Rich Megginson]

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)





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?  
If you want to discuss this more, we can take the discussion to 
freeipa-us...@redhat.com


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.








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: 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


__
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



__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [TripleO] FreeIPA integration

[Fox, Kevin M]

Yeah. I'm all for something like that.  The solution just needs to meet the 
requirements listed in https://review.openstack.org/93

That solution could also probably be reused for an ssh key. The security of 
openssh vms + nova is pretty bad.

There should be some kind of way for the vm to post its ssh pubkey to nova, and 
then have a nova ssh command on the client that pulls the key out of nova api 
and updates your known hosts with it, to prevent all the man in the middle 
potential we've lived with for a long time.

Thanks,
Kevin



From: Adam Young [ayo...@redhat.com]
Sent: Tuesday, April 05, 2016 7:02 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/05/2016 11:42 AM, Fox, Kevin M wrote:
Yeah, and they just deprecated vendor data plugins too, which eliminates my 
other workaround. :/

We need to really discuss this problem at the summit and get a viable path 
forward. Its just getting worse. :/

Thanks,
Kevin

From: Juan Antonio Osorio [jaosor...@gmail.com<mailto:jaosor...@gmail.com>]
Sent: Tuesday, April 05, 2016 5:16 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration



On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:
This sounds suspiciously like, "how do you get a secret to the instance to get 
a secret from the secret store" issue :)
Yeah, sounds pretty familiar. We were using the nova hooks mechanism for this 
means, but it was deprecated recently. So bummer :/

Nova instance user spec again?

Thanks,
Kevin

Yep, and we need a solution.  I think the right solution is a keypair generated 
on the instance, public key posted by the instace to the hypervisor and stored 
with the instance data in the database.  I wrote that to the mailing list 
earlier today.

A basic rule of a private key is that it never leaves the machine on which it 
is generated.  The rest falls out from there.
__
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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Dan Prince]

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 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

On Wed, Apr 6, 2016 at 4:06 AM, 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.
>

Actually, even if we start using Barbican, which wouldn't also be a bad
idea. It still needs a backend. The default settings for Barbican are not
suitable for usage in production. One of the supported backends is DogTag
(which is deployed with FreeIPA). But ellaborating on this, using only
Barbican (with Dogtag as a backend) doesn't really address the issue, but
merely puts a REST interface on top of the problem. We would then need to
come up with a solution that we can propose to nova and further propose a
blueprint. Which is similar to what Kevin Fox once tried to do.

>
> 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.
>
> >
> > So, big question: is 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Adam Young]

On 04/05/2016 09: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.
Barbican is not a CA.  However, it can use the KRA deployed with Dogtag 
to store its secrets, so this actually supports Barbican nicely.




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.
Yep.  The big thing it gives you is the Cert management, and I don't 
want to rewrite that, but the rest can stay out of the way.


I do suspect that, once it is there, we will want to use more of IPA, 
but that is not the goal.







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.


Yeah, and I think I am fine with that.  It just means I have to rewrite 
some stuff, and that makes sense in keeping thing consistent.  Just 
figured I'd ask first before I had to star getting deep into Puppet.





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 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Adam Young]

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)






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.






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: 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



__
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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Adam Young]

On 04/05/2016 11:42 AM, Fox, Kevin M wrote:
Yeah, and they just deprecated vendor data plugins too, which 
eliminates my other workaround. :/


We need to really discuss this problem at the summit and get a viable 
path forward. Its just getting worse. :/


Thanks,
Kevin

*From:* Juan Antonio Osorio [jaosor...@gmail.com]
*Sent:* Tuesday, April 05, 2016 5:16 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration



On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <kevin@pnnl.gov 
<mailto:kevin@pnnl.gov>> wrote:


This sounds suspiciously like, "how do you get a secret to the
instance to get a secret from the secret store" issue :)

Yeah, sounds pretty familiar. We were using the nova hooks mechanism 
for this means, but it was deprecated recently. So bummer :/



Nova instance user spec again?

Thanks,
Kevin



Yep, and we need a solution.  I think the right solution is a keypair 
generated on the instance, public key posted by the instace to the 
hypervisor and stored with the instance data in the database.  I wrote 
that to the mailing list earlier today.


A basic rule of a private key is that it never leaves the machine on 
which it is generated.  The rest falls out from there.
__
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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Adam Young]

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  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;

Re: [openstack-dev] [TripleO] FreeIPA integration

[Rich Megginson]

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?


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 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Dan Prince]

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.

> 
> 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. 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

I was planning to bring it up informally for TripleO. But it would be cool
to have a slot to talk about this.

BR
On 5 Apr 2016 18:51, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

> Yeah, and they just deprecated vendor data plugins too, which eliminates
> my other workaround. :/
>
> We need to really discuss this problem at the summit and get a viable path
> forward. Its just getting worse. :/
>
> Thanks,
> Kevin
> --
> *From:* Juan Antonio Osorio [jaosor...@gmail.com]
> *Sent:* Tuesday, April 05, 2016 5:16 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
>
>
>
> On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
>
>> This sounds suspiciously like, "how do you get a secret to the instance
>> to get a secret from the secret store" issue :)
>>
> Yeah, sounds pretty familiar. We were using the nova hooks mechanism for
> this means, but it was deprecated recently. So bummer :/
>
>>
>> Nova instance user spec again?
>>
>> Thanks,
>> Kevin
>>
>> --
>> *From:* Juan Antonio Osorio
>> *Sent:* Tuesday, April 05, 2016 4:07:06 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
>>
>>
>>
>> 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 servi

Re: [openstack-dev] [TripleO] FreeIPA integration

[Fox, Kevin M]

Yeah, and they just deprecated vendor data plugins too, which eliminates my 
other workaround. :/

We need to really discuss this problem at the summit and get a viable path 
forward. Its just getting worse. :/

Thanks,
Kevin

From: Juan Antonio Osorio [jaosor...@gmail.com]
Sent: Tuesday, April 05, 2016 5:16 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration



On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:
This sounds suspiciously like, "how do you get a secret to the instance to get 
a secret from the secret store" issue :)
Yeah, sounds pretty familiar. We were using the nova hooks mechanism for this 
means, but it was deprecated recently. So bummer :/

Nova instance user spec again?

Thanks,
Kevin


From: Juan Antonio Osorio
Sent: Tuesday, April 05, 2016 4:07:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration



On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy 
<sha...@redhat.com<mailto: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?

These auth pieces all appear critical to the operation of the deployed
cloud, thus I'd assume you really want them independently managed (probably
in an HA configuration on multiple nodes)?

So, I'd say we support one of:

1. Document that FreeIPA must exist, installed by existing non-TripleO
tooling

2. Support a heat template (in addition to overcloud.yaml) that can deploy
FreeIPA.

I feel like we should do (1), as it fits better with the TripleO vision
(which is to deploy OpenStack), and it removes the need for us to maintain
a bunch of non-openstack stuff.

The path I'm imagining is we have a documented integration with FreeIPA,
and perhaps some third-party CI, but we don't support deploying these
pieces directly via TripleO.

> 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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

Having an extra node for FreeIPA spawn up by heat works for me. And it's
not a hard-requirement that we have to wire this into the TripleO CI. But
the most sustainable approach to having TLS everywhere (at least for the
admin and internal endpoints of Openstack, the message broker server nodes
and the database) is using FreeIPA as a CA. So if we advertise (at some
point) that TripleO will support such a feature, then it's probably a good
idea to have it in the official CI.

BR

On Tue, Apr 5, 2016 at 4:01 PM, 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 
> 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).
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Steven Hardy]

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  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).

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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> This sounds suspiciously like, "how do you get a secret to the instance to
> get a secret from the secret store" issue :)
>
Yeah, sounds pretty familiar. We were using the nova hooks mechanism for
this means, but it was deprecated recently. So bummer :/

>
> Nova instance user spec again?
>
> Thanks,
> Kevin
>
> --
> *From:* Juan Antonio Osorio
> *Sent:* Tuesday, April 05, 2016 4:07:06 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [TripleO] FreeIPA integration
>
>
>
> 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?
>
>>
>> These auth pieces all appear critical to the operation of the deployed
>> cloud, thus I'd assume you really want them independently managed
>> (probably
>> in an HA configuration on multiple nodes)?
>>
>> So, I'd say we support one of:
>>
>> 1. Document that FreeIPA must exist, installed by existing non-TripleO
>> tooling
>>
>> 2. Support a heat template (in addition to overcloud.yaml) that can deploy
>> FreeIPA.
>>
>> I feel like we should do (1), as it fits better with the TripleO vision
>> (which is to deploy OpenStack), and it removes the need for us to maintain
>> a bunch 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Hayes, Graham]

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)
>



>
>
> 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


> 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: 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

Re: [openstack-dev] [TripleO] FreeIPA integration

[Fox, Kevin M]

This sounds suspiciously like, "how do you get a secret to the instance to get 
a secret from the secret store" issue :)

Nova instance user spec again?

Thanks,
Kevin


From: Juan Antonio Osorio
Sent: Tuesday, April 05, 2016 4:07:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration



On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy 
<sha...@redhat.com<mailto: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?

These auth pieces all appear critical to the operation of the deployed
cloud, thus I'd assume you really want them independently managed (probably
in an HA configuration on multiple nodes)?

So, I'd say we support one of:

1. Document that FreeIPA must exist, installed by existing non-TripleO
tooling

2. Support a heat template (in addition to overcloud.yaml) that can deploy
FreeIPA.

I feel like we should do (1), as it fits better with the TripleO vision
(which is to deploy OpenStack), and it removes the need for us to maintain
a bunch of non-openstack stuff.

The path I'm imagining is we have a documented integration with FreeIPA,
and perhaps some third-party CI, but we don't support deploying these
pieces directly via TripleO.

> 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.

I think we should require the IPA layer to be installed first - I mean
isn't it likely in many (most?) production environments that these services
already exist?

This simplifies things, because then you just pass inputs from the existing
proven IPA environment in as a tripleo/heat environment file - same 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy  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?

>
> These auth pieces all appear critical to the operation of the deployed
> cloud, thus I'd assume you really want them independently managed (probably
> in an HA configuration on multiple nodes)?
>
> So, I'd say we support one of:
>
> 1. Document that FreeIPA must exist, installed by existing non-TripleO
> tooling
>
> 2. Support a heat template (in addition to overcloud.yaml) that can deploy
> FreeIPA.
>
> I feel like we should do (1), as it fits better with the TripleO vision
> (which is to deploy OpenStack), and it removes the need for us to maintain
> a bunch of non-openstack stuff.
>
> The path I'm imagining is we have a documented integration with FreeIPA,
> and perhaps some third-party CI, but we don't support deploying these
> pieces directly via TripleO.


> > 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.
>
> I think we should require the IPA layer to be installed first - I mean
> isn't it likely in many (most?) production environments that these services
> already exist?
>
> This simplifies things, because then you just pass inputs from the existing
> proven IPA environment in as a tripleo/heat environment file - same model
> we already support for all kinds of vendor integration, SSL etc etc.
>
> > 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
> 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Juan Antonio Osorio]

On the certificate management side I had presented this blueprint*
https://review.openstack.org/#/c/282307/
 *which proposes FreeIPA as the
reference solution. There the steps are described however, I did leave away
where the FreeIPA instance will be installed, and that was on purpose.
Because first I want to figure out proper integration (since now the
nova-hooks are not an option and we will need another mechanism) and on the
other hand, I wanted to figure out where to put it.

Now, for CI, I have the same view as Adam; It would be very beneficial to
have that in the same node as the undercloud. But if that's not possible, I
would like to discuss different alternatives.

On Sun, Apr 3, 2016 at 12:28 AM, 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.
>
> 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.
>

Why not? I think this is quite a reasonable thing to do for testing
purposes. CI, for example.

>
>
> 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.
>
> 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 

Re: [openstack-dev] [TripleO] FreeIPA integration

[Steven Hardy]

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).

These auth pieces all appear critical to the operation of the deployed
cloud, thus I'd assume you really want them independently managed (probably
in an HA configuration on multiple nodes)?

So, I'd say we support one of:

1. Document that FreeIPA must exist, installed by existing non-TripleO
tooling

2. Support a heat template (in addition to overcloud.yaml) that can deploy
FreeIPA.

I feel like we should do (1), as it fits better with the TripleO vision
(which is to deploy OpenStack), and it removes the need for us to maintain
a bunch of non-openstack stuff.

The path I'm imagining is we have a documented integration with FreeIPA,
and perhaps some third-party CI, but we don't support deploying these
pieces directly via TripleO.

> 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.

I think we should require the IPA layer to be installed first - I mean
isn't it likely in many (most?) production environments that these services
already exist?

This simplifies things, because then you just pass inputs from the existing
proven IPA environment in as a tripleo/heat environment file - same model
we already support for all kinds of vendor integration, SSL etc etc.

> 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.
> 
> 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.

In short, no.  I don't see how you can do the hardening with ansible,
unless you're proposing to reimplement the entire overcloud