Duplicity
- Canonical BootStack Charmers
Channel | Revision | Published | Runs on |
---|---|---|---|
latest/stable | 3 | 07 Jun 2024 | |
latest/candidate | 3 | 06 May 2024 | |
latest/edge | 10 | Yesterday |
juju deploy duplicity
Deploy universal operators easily with Juju, the Universal Operator Lifecycle Manager.
Platform:
Cryptography
Data in transit
The cryptography used for file transfers depends on the backend charm option. For all backend options it’s necessary to set the remote_backup_url.
SSH - Charm side
The backends for backups that use SSH are: rsync, scp, and sftp. For those options the user needs to pass the following charm configuration:
- private_ssh_key: This is the base64-encoded private ssh key that will be placed in the duplicity unit disk at /root/.ssh/duplicity_id_rsa with read and write permissions for the owner of the file, in this case the root user. This key is used to authenticate the duplicity application against the remote backup host. Note that the public key of the client should be stored in the remote backup host in order to accept the connection.
- known_host_key: This option is used to store the fingerprint (a hash of the remote host public key) that will be placed in the duplicity unit disk at /root/.ssh/known_hosts. The known_hosts file essentially acts as a trust store for remote server identities. Storing the server’s public key fingerprint ensures that you’re connecting to the correct server in future sessions, avoiding Man-in-the-Middle attacks.
- remote_password: This is an alternative to the public and private keys used for authentication.
In summary, it’s possible to connect via SSH in two ways:
- Key-based authentication using private and public keys.
- Password-based authentication using passwords.
SSH - Payload side
Duplicity uses the paramiko library, which relies on the SSHv2 protocol and uses the cryptography Python package for crypto functionality. Paramiko provides an easy-to-use interface for handling SSH and SFTP communications, enabling secure remote operations over SSH without the need for command-line tools.
HTTPS - Charm side
Both S3 and Azure backends use an HTTPS-based API for file transferring.
For AWS S3 buckets the user needs to provide the aws_access_key_id and aws_secret_access_key charm options. These options will be used as environment variables with the names AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, respectively. Note that it is necessary to have upload privileges to S3 buckets to be able to store the backups.
For Azure, it’s necessary to use the azure_connection_string charm option that will be used as an environmental variable named AZURE_CONNECTION_STRING. For more information about the connections string see the documentation.
HTTPS - Payload side
Duplicity uses the boto3 library for handling S3 buckets and azure-storage-blob for the Azure backend.
No cryptography
If ftp is used as a backend, there is no cryptography technology for data transferring.
Data at rest
Backups can be encrypted using GPG asymmetrically using keys or symmetrically using password.
GPG keys
GPG uses a public key to encrypt data asymmetrically, so that only the owner of the private key may be able to decrypt it. To use this technology, use the gpg_public_key charm option to set the public key that will be used to encrypt the files.
Password
As an alternative, users can set an encryption passphrase via the encryption_passphrase charm option. Duplicity will encrypt symmetrically by invoking gpg
with the --symmetric
option. At the moment this yields an AES256-encrypted file.
No cryptography
Users can disable backup encryption by setting the disable_encryption charm configuration option to True.