On 03/11/2014 11:33 AM, Petr Spacek wrote:
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectural approach to try to
fix a specific
use case with one off solution while we already know that we need
a key
storage.
I would rather do things right and reusable than jam them into
the currently
proposed release boundaries.
I want to make clear that I'm not opposed to Vault in general. I'm
questioning
the necessity of Vault from the beginning because it will delay
DNSSEC
significantly.
+1, I also now see number of scenarios where Vault will be needed.
One of the proposals in this thread is to use something simple for
DNSSEC keys
(with few lines of Python code) and migrate DNSSEC with Vault when
Vault is
available and stable enough (in some later release).
I understand that Vault brings a lot of work to the table. But
let us do it
right and if it does not fit into 4.0 let us do it in 4.1.
We will have one huge release with DNSSEC + Vault at once if we to
postpone
DNSSEC to the same release as Vault.
As a result, it would be harder to debug it because we will have
to find if
something is broken because of:
- DNSSEC-IPA integration
- Vault-IPA integration
- DNSSEC-Vault integration.
I don't think it is a good idea to make such huge release.
"Release early, release often"
I must say I tend to agree with Petr. If the "poor man's solution"
of DNSSEC
without Vault does not cost us too much time and it would seem that
the Vault
is not going to squeeze in 4.0 deadlines, I would rather release
the poor man's
solution in 4.0 and switch to Vault when it's available in 4.1.
This would let our users test the non-Vault parts of our DNSSEC
solution
instead of waiting to test a perfect solution.
Yesterday we have agreed that DNSSEC support is not going to depend
on Vault
from the beginning and that we can migrate to Vault later.
Here I'm proposing safe upgrade path from non-vault to Vault solution.
After all, it seems relatively easy.
TL;DR version
=============
Use information in cn=masters to detect if there are old replicas and
temporarily convert new keys from Vault to LDAP storage (until all
old replicas
are deleted).
Full version
============
IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA
server and
separate key import/export daemon (i.e. script called from cron or
something
like that) on all IPA servers.
In 4.0, we can add new LDAP objects for DNSSEC-related IPA services
(please
propose better names :-):
- key generator:
cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example
cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example
DNSSEC will be translated by FreeIPA to appropriate service name.
This can vary
between platforms. "v1" can be an attribute of the entry, I would not
add it's
to name.
- key imported/exporter:
cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example
I am thinking it may be sufficient to have just:
cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example
for all DNSSEC empowered masters and then just have:
ipaConfigString: keygenerator
... in the master VM. I am just trying to be future agnostic and avoid
hardcoding service names and implementations details in cn=masters.
FreeIPA on
master would know what services to run when it is a keygenerator or not.
Initial state before upgrade:
- N IPA 4.0 replicas
- N DNSSECKeyImporterv1 service instances (i.e. key distribution for
IPA 4.0)
- 1 OpenDNSSECv1 service instance (key generator)
Now we want to upgrade a first replica to IPA 4.1. For simplicity,
let's add a
*requirement* to upgrade the replica with OpenDNSSECv1 first. (We can
generalize the procedure if this requirement is not acceptable.)
Upgrade procedure:
- stop OpenDNSSECv1 service
- stop DNSSECKeyImporterv1 service
- convert OpenDNSSECv1 database to OpenDNSSECv2
This step is not related to Vault. We need to covert local SQLite
database from
single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC.
- convert private keys from LDAP to Vault *but let them in LDAP for
a while*.
- walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check
if there
are any other replicas with DNSSECKeyImporterv1 service:
In my proposal, one would just search for
"cn=DNSSEC,cn=*,cn=masters..." with
filter "(ipaConfigString=version 1)".
