Advanced configuration

In the previous chapter, we have covered the basic usage of Cloud Gateway. This one is going deeper into the advanced features of the product, like the encryption and compression filters.

Filters

Filters are a powerful tool allowing Cloud Gateway to transform data on-the-fly while they are transferred to and from the storage providers. Two filters are currently provided with Cloud Gateway 1.1.2, the encryption filter and the compression filter.

Filters are applied to a specific instance, not to the whole filesystem. This means that you can create a mirrored filesystem with a non-encrypted instance, for example on a private cloud storage, and an encrypted one using a public cloud provider.

Encryption

One of the key goals of Cloud Gateway is to protect your files. This means protecting them from becoming unreachables by using caching and mirroring, but also protecting them from external snooping, by using encryption at various levels.

In addition to protecting your data during the transfers to and from storage providers with SSL and TLS, Cloud Gateway can use a filter to encrypt your data before sending them to the storage provider, transparently decrypting them when they are later retrieved. That way, the storage provider himself has no way to access your data.

Two modes of operation are currently supported, Cipher Bloc Chaining
[10] and CTR Integer Counter Mode [11]:
  • CBC is known to be vulnerable to padding-oracle attacks when not used properly, but this kind of attack is not practically feasable in the way it is used in Cloud Gateway. Moreover, Cloud Gateway uses a strong integrity check based on a Message Authentication Code [12] function, deterring any padding-oracle attack.
  • CTR is not vulnerable to this kind of attack and offer greater encryption speed because it allows blocks to be encrypted in parallel.

The exact list of supported ciphers can be found in the documentation for the Configuration/Instances/Instance/Filters/Filter/Specifics/Cipher directive, but Cloud Gateway supports at least the following algorithms:

  • Advanced Encryption Standard [13], a well-known NIST standard, supporting key sizes of 128, 192 and 256 bits ;
  • Camellia, a well-known japanese cipher supporting key sizes of 128, 192 and 256 bits.

Please note that encryption is a CPU-consuming operation. For more information, see section   on page .

Configuration

In order to add an encryption filter to an existing instance named Instance1, using the AES cipher, with a 256-bits key based on the MyStrongPassphrase password, a SHA-256 digest and an iteration count of 2000, the following command maye be used:

$ ${INSTALL_PREFIX}/bin/CloudGatewayAddFilterToInstance \
  -i Instance1 \
  -t Encryption \
  -c aes-256-ctr \
  -d sha256 \
  -k 2000 \
  -p MyStrongPassphrase \
  -f ${INSTALL_PREFIX}/etc/CloudGatewayConfiguration.xml

The complete list of supported ciphers and digests can be found below on the description of, respectively, the Configuration/Instances/Instance/Filters/Filter/Specifics/Cipher and Configuration/Instances/Instance/Filters/Filter/Specifics/Digest parameters.

Key derivation

For each different file, a new key and initialization vector [14] is derivated from the user-supplied password. In order for this key and IV to be different for each file, a salt is randomly generated for each file at the beginning of the transfer and used in the key derivation function. The exact processing is dependant on the Configuration/Instances/Instance/Filters/Filter/Specifics/Digest and Configuration/Instances/Instance/Filters/Filter/Specifics/KeyIterationCount Storage Manager parameters. Nuage Labs advises that to you use a strong digest, such as as SHA-256, and a key iteration count of at least 2000.

Compression

In order to speed up the transfer, save bandwidth and storage costs, Cloud Gateway provides a compression filter based on the deflate algorithm allowing on-the-fly compression of files. Depending on the compression level and the data typology, the compression ratio can rise up to 99%. Of course, an higher level of compression requires more CPU time and uses more memory, so this level is configurable.

For more information on compression levels and cost, see section   on page .

Configuration

In order to add a compression filter to an existing instance named Instance1, using a compression level of 3 (best compression is 9, fastest is 1), the following command maye be used:

$ ${INSTALL_PREFIX}/bin/CloudGatewayAddFilterToInstance \
  -i Instance1 \
  -t Compression \
  -l 3 \
  -f ${INSTALL_PREFIX}/etc/CloudGatewayConfiguration.xml

Restrictions

Because of the inner concept of compression means that there is no way to predict the exact size of compressed data from the original size, Cloud Gateway’s compression filter requires that the storage provider provides a way to send variable-length data without annoucing the final size before-hand. Unfortunately, the S3 API does not provide such an ability. Therefore, the compression filter is disabled for instances using a S3 API.

NFS

Many customers want to export their Cloud Gateway filesystem over the network, in order to be able to use it as a network attached storage. The easiest way to do that is to export the filesystem over NFS, using the Linux NFS kernel server.

Installing the system packages

The NFS kernel server package needs to be installed, and the exact method differs from distribution. For aptitude-based distributions, this is done with:

$ aptitude install nfs-kernel-server portmap

For yum-based ones:

$ yum install nfs-utils portmap

Editing the exports file

The /etc/exports file contains the list of all NFS exports, with the options used for each one of them.

For the sake of this example, we will be exporting the Cloud Gateway filesystem mounted on /home/cloudgw/mymountpoint, and allow read-write mode to all hosts in the 192.168.42.0/24 network.

/home/cloudgw/mymountpoint \
  192.168.42.0/24(rw,no_subtree_check,fsid=42,insecure)

Users familiar with the /etc/exports syntax may be surprised to see the rarely-used fsid option. Normally, filesystems provides the kernel with a unique identifier, which is used as fsid by NFS. Due to a limitation in the API Cloud Gateway is using, we have currently no way of providing this identifier to the kernel. Therefore we have to manually assign a unique numeric fsid for each Cloud Gateway volumes we want to export over NFS. A simple positive integer, greater than zero and unique for each export is sufficient.

The rw specifies a read-write filesystem, the no_subtree_check is the default on most Linux versions and enhances stability, and finally the insecure option allows requests originating on an Internet port less than IPPORT_RESERVED (1024). None of these last three options are required for Cloud Gateway, but they are most of the time the ones you will want to use.

(Re-)starting the services

After editing the /etc/exports file, you must start the corresponding services:

$ /etc/init.d/portmap start
$ /etc/init.d/nfs-kernel-server start

If the services were already running, you can simply reload the configuration file:

$ exportfs -arv
[10]CBC
[11]CTR
[12]MAC
[13]AES
[14]IV