5 posts tagged with "Architecture"

tiCrypt delegates VM storage to libvirt storage pools, but not every pool type can create volumes on demand. This article explains which pool types support dynamic provisioning and how encrypted data drives map onto network block-device backends like Ceph RBD and iSCSI.

tiCrypt is composed of several distinct components that communicate over tightly controlled channels. This article walks through the functional architecture of a tiCrypt deployment, explaining how requests flow from the user's workstation through the backend and into secure compute nodes. For infrastructure planning and deployment sizing, see Understanding tiCrypt Infrastructure.

Motivation​

The "traditional" LibVirt networking is based on Linux bridges. This architecture is simple yet effective for providing networking connectivity to VMs. If the VMs run on a single server, this architecture is sufficient. However, if the VMs run on multiple servers, the Linux bridge architecture becomes more complex and less efficient. Specifically, in the case of tiCrypt, it creates the following issues:

• Host network isolation: The Linux bridge network is confined to the host it is defined on. The network can be extended using routing, but this creates significant complexity.
• IP management complexity: IP assignment becomes very difficult since each host must have its own IP range.
• Control of external access: tiCrypt needs to control external access to the VMs, and this is more difficult to achieve with Linux bridges since firewall rules must be defined on each host.
• External proxied access: tiCrypt needs to provide external proxied access to the VMs. This is accomplished by mapping port ranges on the host to the possible VM IPs (port 22). Such mapping rules pollute the firewall rules on the hosts.
• VM migration: The Linux bridge architecture does not support VM migration. This is a planned feature for tiCrypt.
• Proxy performance: The Linux bridge solution forces the use of "software proxying" for external access to VMs. This is much slower than a firewall-based solution that requires a unified network architecture across hosts.
• Rigid network integration: Libvirt, when using the Linux bridge architecture, only supports a few (nat, route, and open) setups. This makes it difficult to deal with custom firewall rules on hosts and backend.

Planning a tiCrypt deployment starts with understanding the infrastructure that powers it. This guide walks through the core components, how they connect, and the deployment architectures available, from a lightweight demo system to a full-scale production environment with batch processing. For a detailed walkthrough of how traffic flows between these components, see tiCrypt Functional Architecture.

Note: This guide covers infrastructure planning and setup. The tiCrypt installation and software deployment process is covered separately.

tiCrypt Vault Storage​

The tiCrypt Vault offers a file system-like facility that allows files and directories to be created and used. All the metadata, such as file properties, directory entries, access information, and decryption keys, are stored in the MongoDB database used by the tiCrypt-file storage service.

In tiCrypt Vault, the file content is broken into 8MB chunks, each encrypted independently using the file key. The size of such chunks is 8MB+64Bytes on disk (unless they are the last, incomplete chunk). The extra 64Bytes contain the IV (initialization vector for AES encryption). For each file, the chunks are numbered from 0 onwards. The chunks are stored in a directory structure based on the file ID, visible only to the tiCrypt backend (preferably not to the VM hosts). The storage location can be configured in the configuration file of the tiCrypt-storage service.

tiCrypt is not opinionated on the file system or integration with other systems for this storage, but for compliance reasons, it is recommended that the access is restricted to only the tiCrypt backend.

Without the decryption keys that only users can recover, the content of the chunk files is entirely indecipherable. It is safe to back up these files using any method (including non-encrypted backup, cloud, etc). The strong encryption, coupled with the unavailability of the key to even administrators, ensures that this content can be replicated outside the secure environment from a compliance point of view.