"conjurctl export" creates an evoke compatible Conjur archive

[micahlee]

Workflow

1. Given a running Conjur server setup using the open source Getting Started guide.

2. Run the export command inside the Conjur container

   # conjurctl export -o /opt/export
   Exporting to '/opt/export'...
   Generating key file /opt/export/key
   gpg: directory `/root/.gnupg' created
   gpg: new configuration file `/root/.gnupg/gpg.conf' created
   gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
   gpg: keyring `/root/.gnupg/pubring.gpg' created
   
   Export placed in /opt/export/2018-07-23T21-08-19Z.tar.xz.gpg
   It's encrypted with key in /opt/export/key.
   If you're going to store the export, make
   sure to store the key file separately.

3. Copy the exported data files out of the container

   $ docker-compose ps
   Name                  Command              State           Ports
   -----------------------------------------------------------------------------
   dev_conjur_1   /sbin/my_init                   Up      0.0.0.0:3000->3000/tcp
   dev_pg_1       docker-entrypoint.sh postgres   Up      5432/tcp
   
   $ docker cp dev_conjur_1:/opt/export/2018-07-23T21-08-19Z.tar.xz.gpg .
   $ docker cp dev_conjur_1:/opt/export/key .

[kgilpin]

So, a problem is that an EE backup file also contains lots of EE specific info like data encryption keys, configuration files of various services, etc. Conjur OSS is not going to be able to easily create a backup file that's compatible with EE, since there are a lot of EE features that are expected to be configured in the backup file (but OSS knows nothing about these features...).

[kgilpin]

It might be simpler architecturally to put all the knowledge about how to upgrade from OSS to EE into the EE product itself. For example, a new evoke command or evoke option set which configures the server as an upgrade from a running OSS container.

[micahlee]

Sure, that makes sense.

I agree the upgrade knowledge would live most appropriately with enterprise. I think I can generalize this to two starting choices:

• Offline: We need some artifact from Conjur Open Source to configure EE with (where the evoke idea came from)
• Online: We need a running Conjur Open Source server / database to connect to

I will switch gears a bit and write up the experience for standing up EE from an online OSS container.

cc @jvanderhoof in case you have any thoughts or guidance from PM conversations that would influence this.

[jvanderhoof]

Maybe this is a dumb question, but could we just do a sql dump from OS and load it into Evoke as part of the EE setup?

[micahlee]

A SQL dump will certainly have to be a part of it. My initial thinking was that it was an implementation detail, rather than part of the end-user experience directly.

I haven't gone deep yet, but I know you would at least have two pieces that need to come from Open Source, the SQL dump and the data key, in order to move the data into an EE instance. Having the end-user export those directly feels sloppy to me, compared with the experience of evoke backup. There, the details about what is in the backup isn't something I have to be concerned with if I don't want to, and I gain some overall confidence because the tool has taken the care to protect the backup information for me.

[kgilpin]

@micahlee It's not probably possible to add a volume mount after the Conjur container is already running. Maybe it would be better to show how to capture the backup and then copy to the local filesystem using docker cp.