Encryption everywhere with IPSEC
This adds the blueprint for enabling service communication encryption using IPSEC. bp ipsec Change-Id: If56c135dcd2727710b5aeecc5dbdd4b778c96451
This commit is contained in:
Juan Antonio Osorio Robles
parent
ae41e2be2d
commit
ea8597a179
|
|
@ -0,0 +1,189 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
========================
|
||||
IPSEC encrypted networks
|
||||
========================
|
||||
|
||||
https://blueprints.launchpad.net/tripleo/+spec/ipsec
|
||||
|
||||
This proposes the usage of IPSEC tunnels for encrypting all communications in a
|
||||
TripleO cloud.
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
Having everything in the network encrypted is a hard requirements for certain
|
||||
use-cases. While TLS everywhere provides support for this, not everyone wants a
|
||||
full-fledged CA. IPSEC provides an alternative which requires one component
|
||||
less (the CA) while still fulfilling the security requirements. With the
|
||||
downside that IPSEC tunnel configurations can get quite verbose.
|
||||
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
As mentioned in the mailing list [1], for OSP10 we already worked on an ansible
|
||||
role that runs on top of a TripleO deployment [2].
|
||||
|
||||
It does the following:
|
||||
|
||||
* Installs IPSEC if it's not available in the system.
|
||||
|
||||
* Sets up the firewall rules.
|
||||
|
||||
* Based on a hard-coded set of networks, it discovers the IP addresses for each
|
||||
of them.
|
||||
|
||||
* Based on a hard-coded set of networks, it discovers the Virtual IP addresses
|
||||
(including the Redis VIP).
|
||||
|
||||
* It puts up an IPSEC tunnel for most IPs in each network.
|
||||
|
||||
- Regular IPs are handled as a point-to-point IPSEC tunnel.
|
||||
|
||||
- Virtual IPs are handled with road-warrior configurations. This means that
|
||||
the VIP's tunnel listens for any connections. This enables easier
|
||||
configuration of the tunnel, as the VIP-holder doesn't need to be aware nor
|
||||
configure each tunnel.
|
||||
|
||||
- Similarly to TLS everywhere, this focuses on service-to-service
|
||||
communication, so we explicitly skip the tenant network. Or,
|
||||
as it was in the original ansible role, compute-to-compute communication.
|
||||
This significantly reduces the amount of tunnels we need to set up, but
|
||||
leaves application security to the deployer.
|
||||
|
||||
- Authentication for the tunnels is done via a Pre-Shared Key (PSK), which is
|
||||
shared between all nodes.
|
||||
|
||||
* Finally, it creates an OCF resource that tracks each VIP and puts up or down
|
||||
its corresponding IPSEC tunnel depending on the VIP's location.
|
||||
|
||||
- While this resource is still in the repository [3], it has now landed
|
||||
upstream [4]. Once this resource is available in the packaged version of
|
||||
the resource agents, the preferred version will be the packaged one.
|
||||
|
||||
- This resource effectively handles VIP fail-overs, by detecting that a VIP
|
||||
is no longer hosted by the node, it cleanly puts down the IPSEC tunnel and
|
||||
enables it where the VIP is now hosted.
|
||||
|
||||
All of this work is already part of the role, however, to have better
|
||||
integration with the current state of TripleO, the following work is needed:
|
||||
|
||||
* Support for composable networks.
|
||||
|
||||
- Now that composable networks are a thing, we can no longer rely on the
|
||||
hard-coded values we had in the role.
|
||||
|
||||
- Fortunately, this is information we can get from the tripleo dynamic
|
||||
inventory. So we would need to add information about the available networks
|
||||
and the VIPs.
|
||||
|
||||
* Configurable skipping of networks.
|
||||
|
||||
- In order to address the tenant network skipping, we need to somehow make it
|
||||
configurable.
|
||||
|
||||
* Add the IPSEC package as part of the image.
|
||||
|
||||
* Configure Firewall rules the TripleO way.
|
||||
|
||||
- Currently the role handles the firewall rule setup. However, it should be
|
||||
fairly simple to configure these rules the same way other services
|
||||
configure theirs (Using the tripleo.<service>.firewall_rules entry). This
|
||||
will require the usage of a composable service template.
|
||||
|
||||
* As mentioned above, we will need to create a composable service template.
|
||||
|
||||
- This could take into use the recently added `external_deploy_tasks` section
|
||||
of the templates, which will work similarly to the Kubernetes configuration
|
||||
and would rely on the config-download mechanism [5].
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
While deployers can already use TLS everywhere. A few are already using the
|
||||
aforementioned ansible role. So this would provide a seamless upgrade path for
|
||||
them.
|
||||
|
||||
Security Impact
|
||||
---------------
|
||||
|
||||
This by itself is a security enhancement, as it enables encryption in the
|
||||
network.
|
||||
|
||||
The PSK being shared by all the nodes is not ideal and could be addressed by
|
||||
per-network PSKs. However, this work could be done in further iterations.
|
||||
|
||||
Other End User Impact
|
||||
---------------------
|
||||
|
||||
Currently, the deployer needs to provide their PSK. However, this could be
|
||||
automated as part of the tasks that TripleO does.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Same as with TLS everywhere, adding encryption in the network will have a
|
||||
performance impact. We currently don't have concrete data on what this impact
|
||||
actually is.
|
||||
|
||||
Other Deployer Impact
|
||||
---------------------
|
||||
|
||||
This would be added as a composable service. So it would be something that the
|
||||
deployer would need to enable via an environment file.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
jaosorior
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Add libreswan (IPSEC's frontend) package to the overcloud-full iamge.
|
||||
|
||||
* Add required information to the dynamic inventory (networks and VIPs)
|
||||
|
||||
* Based on the inventory, create the IPSEC tunnels dynamically, and not based
|
||||
on the hardcoded networks.
|
||||
|
||||
* Add tripleo-ipsec ansible role as part of the TripleO umbrella.
|
||||
|
||||
* Create composable service.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* This requires the triple-ipsec role to be available. For this, it will be
|
||||
moved to the TripleO umbrella and packaged as such.
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Given that this doesn't require an extra component, we could test this as part
|
||||
of our upstream tests. The requirement being that the deployment has
|
||||
network-isolation enabled.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] http://lists.openstack.org/pipermail/openstack-dev/2017-November/124615.html
|
||||
[2] https://github.com/JAORMX/tripleo-ipsec
|
||||
[3] https://github.com/JAORMX/tripleo-ipsec/blob/master/files/ipsec-resource-agent.sh
|
||||
[4] https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/ipsec
|
||||
[5] https://github.com/openstack/tripleo-heat-templates/blob/master/extraconfig/services/kubernetes-master.yaml#L58
|
||||
Loading…
Reference in New Issue