You must manually reapply these settings on Standbys and Followers when they are redeployed. For details, see Enable rotation.Ĭustom configuration variables (those set through the evoke variable command) are only retained on the Leader through the backup and restore process. If you are working with the rotation feature, you need to re-enable it manually on the Leader. $ docker exec new-container-name evoke keys exec -m /secrets/master.key - evoke restore -accept-eula $ docker exec new-container-name evoke restore -accept-eula In this case, the evoke-HSM integration handles the key retrieval. For more information, see Encrypt the master key using AWS KMS. In this case, the evoke-KMS integration handles the key retrieval.Ĭonjur Enterprise instances must have valid AWS credentials, otherwise the evoke restore -accept-eula command will generate an error with the following message: error: Master key can't be empty. Master key encrypted with the Amazon Key Management Service (KMS)Įvoke restore -accept-eula evoke keys encrypt evoke keys unlock Server keys encrypted with evoke keys encryptĮvoke keys exec -m - evoke restore -accept-eula evoke keys encrypt evoke keys encrypt Įvoke keys exec -m /secrets/master.key - evoke restore -accept-eula evoke keys encrypt /secrets/master.key evoke keys encrypt /secrets/master.key For more information, see the note about accepting the EULA in Configure the Leader.
BACKUP AND RESTORE HOW TO
The following table shows the possible key encryption scenarios and how to restore each one.Īppend the -accept-eula flag to automatically accept the end-user license agreement (EULA), as you would when usually configuring the Leader. The exact command to use depends on whether the original Leader (the one that was backed up) was configured with a master key that encrypted the Server keys. Run the evoke restore command to configure the new node as a Leader. Podman users only: Create a ui folder using the following command (not required for Docker): $ docker exec new-container-name evoke unpack backup -key /keys/key /backup/.gpg (If the /opt/conjur/backup directory doesn't exist, create it first.) (Optional) Create a custom passphrase and save it in /opt/conjur/backup/key on the Leader node. The string must be stored in the path /opt/conjur/backup/ in a file named key, on the node to be backed up.Īfter running the backup, you can store the key elsewhere and remove it from this location.
BACKUP AND RESTORE PASSWORD
We recommend that it have at least 256 bits of password entropy. It is essentially a passphrase for deriving the actual key. The requirements for a custom passphrase are: You can also copy a key that was generated elsewhere to reuse it. You can create a custom passphrase for generating the encryption key using openssl rand or other system such as HSM.
The file name incorporates the creation date and time stamp.
BACKUP AND RESTORE ARCHIVE
The archive is saved in the /opt/conjur/backup directory in the node that was backed up. Otherwise, the backup creates a key and stores it in /opt/conjur/backup/key. If the file /opt/conjur/backup/key exists in the node to be backed up, the backup command uses that key. This file contains a passphrase used to generate an encryption key. The following files are used or generated by evoke backup. GPG provides a convenient file format with metadata, which is convenient for managing archive files. The archive is encrypted with AES-256 and generated using GPG. The archive can ultimately be used to restore a damaged Leader. In a Conjur cluster, the backups are created on the Leader. The evoke backup command creates an encrypted archive of the Conjur database. When evoke restore is issued, the conjur.yml file is copied to /etc/conjur/config in the Docker container on the new Leader. The evoke utility includes backup and restore functions.ĭuring a backup operation, the conjur.yml file is included in the archive that is created on the Leader node and is saved in the /opt/conjur/backup directory on the Leader that is being backedup.
0 kommentar(er)
