settingsLogin | Registersettings

[openstack-dev] [TripleO] FreeIPA integration

0 votes

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.

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 for encryption. ACLs,
for now, would stay in the flat file format. In the future, we might
chose to use the LDAP backed ACLs for Rabbit, as they seem far more
flexible. Rabbit does not currently support Kerberos for either
authentication or encryption, but we can engage the upstream team to
implement it if desired in the future, or we can shift to a Proton based
deployment if Kerberos is essential for a deployment.

There are a couple ongoing efforts that will tie in with this:

  1. Designate should be able to use the DNS from FreeIPA. That was the
    original implementation.

  2. Juan Antonio Osorio has been working on TLS everywhere. The issue
    thus far has been Certificate management. This provides a Dogtag server
    for Certs.

  3. Rob Crittenden has been working on auto-registration of virtual
    machines with an Identity Provider upon launch. This gives that efforts
    an IdM to use.

  4. Keystone can make use of the Identity store for administrative users
    in their own domain.

  5. Many of the compliance audits have complained about cleartext
    passwords in config files. This removes most of them. MySQL supports
    X509 based authentication today, and there is Kerberos support in the
    works, which should remove the last remaining cleartext Passwords.

I mentioned Centralized SUDO and HBAC. These are both tools that may be
used by administrators if so desired on the install. I would recommend
that they be used, but there is no requirement to do so.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Apr 2, 2016 in openstack-dev by Adam_Young (19,940 points)   2 7 9

27 Responses

0 votes

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 deployment in
the same tool.

The data required to configure the OpenStack services should be passed in
via an environment file, e.g

openstack overcloud deploy --templates -e ipa-params.yaml

Then all the data from ipa-params.yaml should be mapped into hieradata
which puppet then uses to configure the OpenStack services appropriately -
this is the same model we support for integration with everything atm.

While it's technically possible to configure an overcloud, then reconfigure
it with some other tool (or even manually), you get the worst of all worlds
doing this - you modify things out-of-band (from a TripleO perspective) so
that all your changed get destroyed every overcloud update, and you run the
risk of "config management split brain" where e.g puppet configures a
service disabled, then ansible starts it or whatever.

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.

This should be:

  1. Install and validate IPA server $somewhere
  2. Generate environment file with parameters (this could be automated)
  3. Install overcloud passing in environment file with IPA $stuff
  4. Done

Basically anything touching the overcloud configuration should happen via
puppet in our current architecture, which I think means (4) and (5).

I'm less clear about (3) - this sounds like an IPA admin action, can it be
done before deploying the overcloud, or do we need each node to register
itself?

Similarly not sure about (6), probably need more info about what that
entails.

When we did the Rippowam demo, we used the Proton driver and Kerberos for
securing the message broker. Since Rabbit seems to be the tool of choice,
we would use X509 authentication and TLS for encryption. ACLs, for now,
would stay in the flat file format. In the future, we might chose to use
the LDAP backed ACLs for Rabbit, as they seem far more flexible. Rabbit
does not currently support Kerberos for either authentication or encryption,
but we can engage the upstream team to implement it if desired in the
future, or we can shift to a Proton based deployment if Kerberos is
essential for a deployment.

There are a couple ongoing efforts that will tie in with this:

  1. Designate should be able to use the DNS from FreeIPA. That was the
    original implementation.

  2. Juan Antonio Osorio has been working on TLS everywhere. The issue thus
    far has been Certificate management. This provides a Dogtag server for
    Certs.

  3. Rob Crittenden has been working on auto-registration of virtual machines
    with an Identity Provider upon launch. This gives that efforts an IdM to
    use.

Aha, this may be the answer to (3) above? E.g the discussion around nova
hooks?

  1. Keystone can make use of the Identity store for administrative users in
    their own domain.

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

Overall this sounds like a bunch of functionality we want, but I think the
integration requires more discussion (possibly at summit?) - my main
concern is that we integrate in a manner appropriate to our existing
implementation, and that we don't inadvertently make the undercloud a
mission-critical component, when it current is not.

Thanks,

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Steven_Hardy (16,900 points)   2 7 11
0 votes

On the certificate management side I had presented this blueprint*
https://review.openstack.org/#/c/282307/
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 ayoung@redhat.com 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 for encryption. ACLs, for now,
would stay in the flat file format. In the future, we might chose to use
the LDAP backed ACLs for Rabbit, as they seem far more flexible. Rabbit
does not currently support Kerberos for either authentication or
encryption, but we can engage the upstream team to implement it if desired
in the future, or we can shift to a Proton based deployment if Kerberos is
essential for a deployment.

There are a couple ongoing efforts that will tie in with this:

  1. Designate should be able to use the DNS from FreeIPA. That was the
    original implementation.

  2. Juan Antonio Osorio has been working on TLS everywhere. The issue
    thus far has been Certificate management. This provides a Dogtag server
    for Certs.

  3. Rob Crittenden has been working on auto-registration of virtual
    machines with an Identity Provider upon launch. This gives that efforts an
    IdM to use.

  4. Keystone can make use of the Identity store for administrative users in
    their own domain.

  5. Many of the compliance audits have complained about cleartext passwords
    in config files. This removes most of them. MySQL supports X509 based
    authentication today, and there is Kerberos support in the works, which
    should remove the last remaining cleartext Passwords.

I mentioned Centralized SUDO and HBAC. These are both tools that may be
used by administrators if so desired on the install. I would recommend that
they be used, but there is no requirement to do so.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Juan_Antonio_Osorio (2,900 points)   1 2
0 votes

On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy shardy@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 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 deployment in
the same tool.

The data required to configure the OpenStack services should be passed in
via an environment file, e.g

openstack overcloud deploy --templates -e ipa-params.yaml

Then all the data from ipa-params.yaml should be mapped into hieradata
which puppet then uses to configure the OpenStack services appropriately -
this is the same model we support for integration with everything atm.

While it's technically possible to configure an overcloud, then reconfigure
it with some other tool (or even manually), you get the worst of all worlds
doing this - you modify things out-of-band (from a TripleO perspective) so
that all your changed get destroyed every overcloud update, and you run the
risk of "config management split brain" where e.g puppet configures a
service disabled, then ansible starts it or whatever.

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.

This should be:

  1. Install and validate IPA server $somewhere
  2. Generate environment file with parameters (this could be automated)
  3. Install overcloud passing in environment file with IPA $stuff
  4. Done

This is an acceptable solution IMO and was according to what I was
thinking. It will also be easier to setup the overcloud with FreeIPA
specific configurations once we have the composable services work done.

To me, the biggest interrogation is what the value of that $somewhere is.
To me, for testing purposes it seemed acceptable to have FreeIPA running in
the same node as the undercloud. And in production it would be a separate
node (or set of nodes).

Basically anything touching the overcloud configuration should happen via
puppet in our current architecture, which I think means (4) and (5).

I'm less clear about (3) - this sounds like an IPA admin action, can it be
done before deploying the overcloud, or do we need each node to register
itself?

The nodes need to get the IPA client installation which pretty much
involves enrollment. For this, they need to have some type of credentials.
So this is the main thing Rob is working towards. To have a safe method to
pass credentials to the nodes, and have them autoregister to FreeIPA.

Similarly not sure about (6), probably need more info about what that
entails.

When we did the Rippowam demo, we used the Proton driver and Kerberos for
securing the message broker. Since Rabbit seems to be the tool of
choice,
we would use X509 authentication and TLS for encryption. ACLs, for now,
would stay in the flat file format. In the future, we might chose to use
the LDAP backed ACLs for Rabbit, as they seem far more flexible. Rabbit
does not currently support Kerberos for either authentication or
encryption,
but we can engage the upstream team to implement it if desired in the
future, or we can shift to a Proton based deployment if Kerberos is
essential for a deployment.

There are a couple ongoing efforts that will tie in with this:

  1. Designate should be able to use the DNS from FreeIPA. That was the
    original implementation.

  2. Juan Antonio Osorio has been working on TLS everywhere. The issue
    thus
    far has been Certificate management. This provides a Dogtag server for
    Certs.

  3. Rob Crittenden has been working on auto-registration of virtual
    machines
    with an Identity Provider upon launch. This gives that efforts an IdM to
    use.

Aha, this may be the answer to (3) above? E.g the discussion around nova
hooks?

  1. Keystone can make use of the Identity store for administrative users
    in
    their own domain.

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

Overall this sounds like a bunch of functionality we want, but I think the
integration requires more discussion (possibly at summit?) - my main
concern is that we integrate in a manner appropriate to our existing
implementation, and that we don't inadvertently make the undercloud a
mission-critical component, when it current is not.

Thanks,

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Juan_Antonio_Osorio (2,900 points)   1 2
0 votes

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 shardy@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 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 deployment in
the same tool.

The data required to configure the OpenStack services should be passed in
via an environment file, e.g

openstack overcloud deploy --templates -e ipa-params.yaml

Then all the data from ipa-params.yaml should be mapped into hieradata
which puppet then uses to configure the OpenStack services appropriately -
this is the same model we support for integration with everything atm.

While it's technically possible to configure an overcloud, then reconfigure
it with some other tool (or even manually), you get the worst of all worlds
doing this - you modify things out-of-band (from a TripleO perspective) so
that all your changed get destroyed every overcloud update, and you run the
risk of "config management split brain" where e.g puppet configures a
service disabled, then ansible starts it or whatever.

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.

This should be:

  1. Install and validate IPA server $somewhere
  2. Generate environment file with parameters (this could be automated)
  3. Install overcloud passing in environment file with IPA $stuff
  4. Done
    This is an acceptable solution IMO and was according to what I was thinking. It will also be easier to setup the overcloud with FreeIPA specific configurations once we have the composable services work done.

To me, the biggest interrogation is what the value of that $somewhere is. To me, for testing purposes it seemed acceptable to have FreeIPA running in the same node as the undercloud. And in production it would be a separate node (or set of nodes).

Basically anything touching the overcloud configuration should happen via
puppet in our current architecture, which I think means (4) and (5).

I'm less clear about (3) - this sounds like an IPA admin action, can it be
done before deploying the overcloud, or do we need each node to register
itself?
The nodes need to get the IPA client installation which pretty much involves enrollment. For this, they need to have some type of credentials. So this is the main thing Rob is working towards. To have a safe method to pass credentials to the nodes, and have them autoregister to FreeIPA.

Similarly not sure about (6), probably need more info about what that
entails.

When we did the Rippowam demo, we used the Proton driver and Kerberos for
securing the message broker. Since Rabbit seems to be the tool of choice,
we would use X509 authentication and TLS for encryption. ACLs, for now,
would stay in the flat file format. In the future, we might chose to use
the LDAP backed ACLs for Rabbit, as they seem far more flexible. Rabbit
does not currently support Kerberos for either authentication or encryption,
but we can engage the upstream team to implement it if desired in the
future, or we can shift to a Proton based deployment if Kerberos is
essential for a deployment.

There are a couple ongoing efforts that will tie in with this:

  1. Designate should be able to use the DNS from FreeIPA. That was the
    original implementation.

  2. Juan Antonio Osorio has been working on TLS everywhere. The issue thus
    far has been Certificate management. This provides a Dogtag server for
    Certs.

  3. Rob Crittenden has been working on auto-registration of virtual machines
    with an Identity Provider upon launch. This gives that efforts an IdM to
    use.

Aha, this may be the answer to (3) above? E.g the discussion around nova
hooks?

  1. Keystone can make use of the Identity store for administrative users in
    their own domain.

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

Overall this sounds like a bunch of functionality we want, but I think the
integration requires more discussion (possibly at summit?) - my main
concern is that we integrate in a manner appropriate to our existing
implementation, and that we don't inadvertently make the undercloud a
mission-critical component, when it current is not.

Thanks,

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

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

  1. Juan Antonio Osorio has been working on TLS everywhere. The issue
    thus far has been Certificate management. This provides a Dogtag server
    for Certs.

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

  3. Keystone can make use of the Identity store for administrative users
    in their own domain.

  4. 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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by graham.hayes_at_hpe. (6,780 points)   1 2 2
0 votes

On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M Kevin.Fox@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 shardy@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 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 deployment in
the same tool.

The data required to configure the OpenStack services should be passed in
via an environment file, e.g

openstack overcloud deploy --templates -e ipa-params.yaml

Then all the data from ipa-params.yaml should be mapped into hieradata
which puppet then uses to configure the OpenStack services appropriately -
this is the same model we support for integration with everything atm.

While it's technically possible to configure an overcloud, then
reconfigure
it with some other tool (or even manually), you get the worst of all
worlds
doing this - you modify things out-of-band (from a TripleO perspective) so
that all your changed get destroyed every overcloud update, and you run
the
risk of "config management split brain" where e.g puppet configures a
service disabled, then ansible starts it or whatever.

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.

This should be:

  1. Install and validate IPA server $somewhere
  2. Generate environment file with parameters (this could be automated)
  3. Install overcloud passing in environment file with IPA $stuff
  4. Done

This is an acceptable solution IMO and was according to what I was
thinking. It will also be easier to setup the overcloud with FreeIPA
specific configurations once we have the composable services work done.

To me, the biggest interrogation is what the value of that $somewhere is.
To me, for testing purposes it seemed acceptable to have FreeIPA running in
the same node as the undercloud. And in production it would be a separate
node (or set of nodes).

Basically anything touching the overcloud configuration should happen
via
puppet in our current architecture, which I think means (4) and (5).

I'm less clear about (3) - this sounds like an IPA admin action, can it be
done before deploying the overcloud, or do we need each node to register
itself?

The nodes need to get the IPA client installation which pretty much
involves enrollment. For this, they need to have some type of credentials.
So this is the main thing Rob is working towards. To have a safe method to
pass credentials to the nodes, and have them autoregister to FreeIPA.

Similarly not sure about (6), probably need more info about what that
entails.

When we did the Rippowam demo, we used the Proton driver and Kerberos
for
securing the message broker. Since Rabbit seems to be the tool of
choice,
we would use X509 authentication and TLS for encryption. ACLs, for now,
would stay in the flat file format. In the future, we might chose to
use
the LDAP backed ACLs for Rabbit, as they seem far more flexible. Rabbit
does not currently support Kerberos for either authentication or
encryption,
but we can engage the upstream team to implement it if desired in the
future, or we can shift to a Proton based deployment if Kerberos is
essential for a deployment.

There are a couple ongoing efforts that will tie in with this:

  1. Designate should be able to use the DNS from FreeIPA. That was the
    original implementation.

  2. Juan Antonio Osorio has been working on TLS everywhere. The issue
    thus
    far has been Certificate management. This provides a Dogtag server for
    Certs.

  3. Rob Crittenden has been working on auto-registration of virtual
    machines
    with an Identity Provider upon launch. This gives that efforts an IdM
    to
    use.

Aha, this may be the answer to (3) above? E.g the discussion around nova
hooks?

  1. Keystone can make use of the Identity store for administrative users
    in
    their own domain.

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

Overall this sounds like a bunch of functionality we want, but I think the
integration requires more discussion (possibly at summit?) - my main
concern is that we integrate in a manner appropriate to our existing
implementation, and that we don't inadvertently make the undercloud a
mission-critical component, when it current is not.

Thanks,

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Juan_Antonio_Osorio (2,900 points)   1 2
0 votes

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 shardy@redhat.com wrote:

 On Sat, Apr 02, 2016 at 05:28:57PM -0400, Adam Young wrote:
 > I finally have enough understanding of what is going on with Tripleo
 to
 > reasonably discuss how to implement solutions for some of the main
 security
 > needs of a deployment.
 >
 >
 > FreeIPA is an identity management solution that can provide support
 for:
 >
 > 1. TLS on all network communications:
 >    A. HTTPS for web services
 >    B. TLS for the message bus
 >    C. TLS for communication with the Database.
 > 2. Identity for all Actors in the system:
 >   A.  API services
 >   B.  Message producers and consumers
 >   C.  Database consumers
 >   D.  Keystone service users
 > 3. Secure  DNS DNSSEC
 > 4. Federation Support
 > 5. SSH Access control to Hosts for both undercloud and overcloud
 > 6. SUDO management
 > 7. Single Sign On for Applications running in the overcloud.
 >
 >
 > The main pieces of FreeIPA are
 > 1. LDAP (the 389 Directory Server)
 > 2. Kerberos
 > 3. DNS (BIND)
 > 4. Certificate Authority (CA) server (Dogtag)
 > 5. WebUI/Web Service Management Interface (HTTPD)
 >
 > Of these, the CA is the most critical.  Without a centralized CA, we
 have no
 > reasonable way to do certificate management.
 >
 > Now, I know a lot of people have an allergic reaction to some, maybe
 all, of
 > these technologies. They should not be required to be running in a
 > development or testbed setup.  But we need to make it possible to
 secure an
 > end deployment, and FreeIPA was designed explicitly for these kinds of
 > distributed applications.  Here is what I would like to implement.
 >
 > Assuming that the Undercloud is installed on a physical machine, we
 want to
 > treat the FreeIPA server as a managed service of the undercloud that
 is then
 > consumed by the rest of the overcloud. Right now, there are conflicts
 for
 > some ports (8080 used by both swift and Dogtag) that prevent a drop-in
 run
 > of the server on the undercloud controller.  Even if we could
 deconflict,
 > there is a possible battle between Keystone and the FreeIPA server on
 the
 > undercloud.  So, while I would like to see the ability to run the
 FreeIPA
 > server on the Undercloud machine eventuall, I think a more realistic
 > deployment is to build a separate virtual machine, parallel to the
 overcloud
 > controller, and install FreeIPA there. I've been able to modify
 Tripleo
 > Quickstart to provision this VM.

 IMO these services shouldn't be deployed on the undercloud - we only
 support a single node undercloud, and atm it's completely possible to
 take
 the undercloud down without any impact to your deployed cloud (other
 than
 losing the ability to manage it temporarily).

This is fair enough, however, for CI purposes, would it be acceptable to
deploy it there? Or where do you recommend we have it?

We're already well beyond capacity in CI, so to me this seems like
something that's probably appropriate for a third-party CI job?

To me it just doesn't make sense to integrate these pieces on the
undercloud, and integrating it there just because we need it available for
CI purposes seems like a poor argument, because we're not testing a
representative/realistic environment.

If we have to wire this in to TripleO CI I'd favor spinning up an extra
node with the FreeIPA pieces in, e.g a separate Heat stack (so, e.g the
nonha job takes 3 nodes, a "freeipa" stack of 1 and an overcloud of 2).

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Steven_Hardy (16,900 points)   2 7 11
0 votes

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 shardy@redhat.com 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 shardy@redhat.com
wrote:

 On Sat, Apr 02, 2016 at 05:28:57PM -0400, Adam Young wrote:
 > I finally have enough understanding of what is going on with

Tripleo
to

reasonably discuss how to implement solutions for some of the main
security
needs of a deployment.

FreeIPA is an identity management solution that can provide
support
for:

  1. TLS on all network communications:
    Â Â A. HTTPS for web services
    Â Â B. TLS for the message bus
    Â Â C. TLS for communication with the Database.
  2. Identity for all Actors in the system:
      A. API services
      B. Message producers and consumers
      C. Database consumers
      D. Keystone service users
  3. Secure DNS DNSSEC
  4. Federation Support
  5. SSH Access control to Hosts for both undercloud and overcloud
  6. SUDO management
  7. Single Sign On for Applications running in the overcloud.

The main pieces of FreeIPA are
1. LDAP (the 389 Directory Server)
2. Kerberos
3. DNS (BIND)
4. Certificate Authority (CA) server (Dogtag)
5. WebUI/Web Service Management Interface (HTTPD)

Of these, the CA is the most critical. Without a centralized
CA, we
have no
reasonable way to do certificate management.

Now, I know a lot of people have an allergic reaction to some,
maybe
all, of
these technologies. They should not be required to be running in a
development or testbed setup. But we need to make it possible to
secure an
end deployment, and FreeIPA was designed explicitly for these
kinds of
distributed applications. Here is what I would like to
implement.

Assuming that the Undercloud is installed on a physical machine,
we
want to
treat the FreeIPA server as a managed service of the undercloud
that
is then
consumed by the rest of the overcloud. Right now, there are
conflicts
for
some ports (8080 used by both swift and Dogtag) that prevent a
drop-in
run
of the server on the undercloud controller. Even if we could
deconflict,
there is a possible battle between Keystone and the FreeIPA
server on
the
undercloud. So, while I would like to see the ability to run the
FreeIPA
server on the Undercloud machine eventuall, I think a more
realistic
deployment is to build a separate virtual machine, parallel to the
overcloud
controller, and install FreeIPA there. I've been able to modify
Tripleo
Quickstart to provision this VM.

 IMO these services shouldn't be deployed on the undercloud - we only
 support a single node undercloud, and atm it's completely possible

to
take
the undercloud down without any impact to your deployed cloud (other
than
losing the ability to manage it temporarily).

This is fair enough, however, for CI purposes, would it be acceptable
to
deploy it there? Or where do you recommend we have it?

We're already well beyond capacity in CI, so to me this seems like
something that's probably appropriate for a third-party CI job?

To me it just doesn't make sense to integrate these pieces on the
undercloud, and integrating it there just because we need it available for
CI purposes seems like a poor argument, because we're not testing a
representative/realistic environment.

If we have to wire this in to TripleO CI I'd favor spinning up an extra
node with the FreeIPA pieces in, e.g a separate Heat stack (so, e.g the
nonha job takes 3 nodes, a "freeipa" stack of 1 and an overcloud of 2).

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Juan_Antonio_Osorio (2,900 points)   1 2
0 votes

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 [jaosorior@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.Fox@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 shardy@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 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 deployment in
the same tool.

The data required to configure the OpenStack services should be passed in
via an environment file, e.g

openstack overcloud deploy --templates -e ipa-params.yaml

Then all the data from ipa-params.yaml should be mapped into hieradata
which puppet then uses to configure the OpenStack services appropriately -
this is the same model we support for integration with everything atm.

While it's technically possible to configure an overcloud, then reconfigure
it with some other tool (or even manually), you get the worst of all worlds
doing this - you modify things out-of-band (from a TripleO perspective) so
that all your changed get destroyed every overcloud update, and you run the
risk of "config management split brain" where e.g puppet configures a
service disabled, then ansible starts it or whatever.

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.

This should be:

  1. Install and validate IPA server $somewhere
  2. Generate environment file with parameters (this could be automated)
  3. Install overcloud passing in environment file with IPA $stuff
  4. Done
    This is an acceptable solution IMO and was according to what I was thinking. It will also be easier to setup the overcloud with FreeIPA specific configurations once we have the composable services work done.

To me, the biggest interrogation is what the value of that $somewhere is. To me, for testing purposes it seemed acceptable to have FreeIPA running in the same node as the undercloud. And in production it would be a separate node (or set of nodes).

Basically anything touching the overcloud configuration should happen via
puppet in our current architecture, which I think means (4) and (5).

I'm less clear about (3) - this sounds like an IPA admin action, can it be
done before deploying the overcloud, or do we need each node to register
itself?
The nodes need to get the IPA client installation which pretty much involves enrollment. For this, they need to have some type of credentials. So this is the main thing Rob is working towards. To have a safe method to pass credentials to the nodes, and have them autoregister to FreeIPA.

Similarly not sure about (6), probably need more info about what that
entails.

When we did the Rippowam demo, we used the Proton driver and Kerberos for
securing the message broker. Since Rabbit seems to be the tool of choice,
we would use X509 authentication and TLS for encryption. ACLs, for now,
would stay in the flat file format. In the future, we might chose to use
the LDAP backed ACLs for Rabbit, as they seem far more flexible. Rabbit
does not currently support Kerberos for either authentication or encryption,
but we can engage the upstream team to implement it if desired in the
future, or we can shift to a Proton based deployment if Kerberos is
essential for a deployment.

There are a couple ongoing efforts that will tie in with this:

  1. Designate should be able to use the DNS from FreeIPA. That was the
    original implementation.

  2. Juan Antonio Osorio has been working on TLS everywhere. The issue thus
    far has been Certificate management. This provides a Dogtag server for
    Certs.

  3. Rob Crittenden has been working on auto-registration of virtual machines
    with an Identity Provider upon launch. This gives that efforts an IdM to
    use.

Aha, this may be the answer to (3) above? E.g the discussion around nova
hooks?

  1. Keystone can make use of the Identity store for administrative users in
    their own domain.

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

Overall this sounds like a bunch of functionality we want, but I think the
integration requires more discussion (possibly at summit?) - my main
concern is that we integrate in a manner appropriate to our existing
implementation, and that we don't inadvertently make the undercloud a
mission-critical component, when it current is not.

Thanks,

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

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.Fox@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 [jaosorior@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.Fox@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 shardy@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 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 deployment in
the same tool.

The data required to configure the OpenStack services should be passed in
via an environment file, e.g

openstack overcloud deploy --templates -e ipa-params.yaml

Then all the data from ipa-params.yaml should be mapped into hieradata
which puppet then uses to configure the OpenStack services appropriately
-
this is the same model we support for integration with everything atm.

While it's technically possible to configure an overcloud, then
reconfigure
it with some other tool (or even manually), you get the worst of all
worlds
doing this - you modify things out-of-band (from a TripleO perspective)
so
that all your changed get destroyed every overcloud update, and you run
the
risk of "config management split brain" where e.g puppet configures a
service disabled, then ansible starts it or whatever.

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.

This should be:

  1. Install and validate IPA server $somewhere
  2. Generate environment file with parameters (this could be automated)
  3. Install overcloud passing in environment file with IPA $stuff
  4. Done

This is an acceptable solution IMO and was according to what I was
thinking. It will also be easier to setup the overcloud with FreeIPA
specific configurations once we have the composable services work done.

To me, the biggest interrogation is what the value of that $somewhere is.
To me, for testing purposes it seemed acceptable to have FreeIPA running in
the same node as the undercloud. And in production it would be a separate
node (or set of nodes).

Basically anything touching the overcloud configuration should happen
via
puppet in our current architecture, which I think means (4) and (5).

I'm less clear about (3) - this sounds like an IPA admin action, can it
be
done before deploying the overcloud, or do we need each node to register
itself?

The nodes need to get the IPA client installation which pretty much
involves enrollment. For this, they need to have some type of credentials.
So this is the main thing Rob is working towards. To have a safe method to
pass credentials to the nodes, and have them autoregister to FreeIPA.

Similarly not sure about (6), probably need more info about what that
entails.

When we did the Rippowam demo, we used the Proton driver and Kerberos
for
securing the message broker. Since Rabbit seems to be the tool of
choice,
we would use X509 authentication and TLS for encryption. ACLs, for
now,
would stay in the flat file format. In the future, we might chose to
use
the LDAP backed ACLs for Rabbit, as they seem far more flexible.
Rabbit
does not currently support Kerberos for either authentication or
encryption,
but we can engage the upstream team to implement it if desired in the
future, or we can shift to a Proton based deployment if Kerberos is
essential for a deployment.

There are a couple ongoing efforts that will tie in with this:

  1. Designate should be able to use the DNS from FreeIPA. That was the
    original implementation.

  2. Juan Antonio Osorio has been working on TLS everywhere. The
    issue thus
    far has been Certificate management. This provides a Dogtag server for
    Certs.

  3. Rob Crittenden has been working on auto-registration of virtual
    machines
    with an Identity Provider upon launch. This gives that efforts an IdM
    to
    use.

Aha, this may be the answer to (3) above? E.g the discussion around nova
hooks?

  1. Keystone can make use of the Identity store for administrative
    users in
    their own domain.

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

Overall this sounds like a bunch of functionality we want, but I think
the
integration requires more discussion (possibly at summit?) - my main
concern is that we integrate in a manner appropriate to our existing
implementation, and that we don't inadvertently make the undercloud a
mission-critical component, when it current is not.

Thanks,

Steve


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 5, 2016 by Juan_Antonio_Osorio (2,900 points)   1 2
...