The SMB 3.0 protocol includes support for in-built network transport encryption. This isn’t to be confused with Tintri’s SecureVM at-rest encryption, which is used to encrypt persisted data, but may be used in conjunction with it.
SMB transport encryption is negotiated between Hyper-V hosts and the Tintri VMstore. It is easy to configure and doesn’t require generating and signing certificates or pre-shared keys as with other transport encryption approaches.
This transport encryption does come with a measurable performance cost, so may not be suitable for all use cases, but is available for cases where virtual machine I/O between compute and storage needs to be kept private.
The controls for configuring SMB transport encryption in VMstore are very straightforward:
- A checkbox per SMB share to enable encryption negotiation
- A checkbox at the global SMB level to enable encryption negotiation for all SMB shares
- A checkbox at the global SMB level to determine whether to accept or reject any unencrypted SMB requests
To enable encryption for all Hyper-V VM I/O, check the box in SMB settings tab labelled Encrypt data for all Hyper-V shares:
If the Reject unencrypted access when encryption is enabled box is checked, any Hyper-V host not also encrypting traffic will be denied. If some hosts or some requests are expected to be sent unencrypted, uncheck this box.
To enable encryption for a single share, select the share in the Hyper-V Shares tab and check the Encrypt data box:
The global Reject unencrypted access when encryption is enabled flag also applies when this per-share encryption is in use.
There are a similar set of controls on each of the Hyper-V hosts to enable the negotiation of encrypted SMB sessions. This Microsoft TechNet article shows how to make use of those.
Both the compute (Hyper-V) and the storage (Tintri VMstore) need to agree on whether to encrypt or not for encryption to happen.