NetApp
Add a third volume provisioning encryption choice for ONTAP drivers to allow for NAE configurations
ONTAP supports volume encryption (NVE) and aggregate encryption (NAE) for volumes. When provisioning volumes via the CLI or API, using a value of "true" for the encryption parameter results in a NVE encrypted volume in order to be backwards compatible with older versions of ONTAP that did not support NAE. In order to actually provision a NAE encrypted volume, the encryption parameter needs to be omitted from the CLI or API call, in which case the default for an NAE enabled aggregate on an AFF system is to use NAE enabled volumes.
Right now, Trident only allows for provisioning of volumes with encryption=false (the default) or encryption=true. With these being the only options, there is no way to make use of NAE encrypted volumes. One suggestion would be to allow a 3rd choice, such as encryption=aggregate_default, in which case the API call for volume creation from Trident would not pass in anything at all related to volume encryption, and ONTAP would provision the volume with it's own defaults based on the platform and aggregate encryption configuration.
Hi @frasmarco, we are currently tracking this feature request on our roadmap. Thanks for inquiring on this issue as it provides us with a better idea of interest in this enhancement.
Hi @pjos and @matalve,
The Trident team just finished investigating this issue and found that if NAE is enabled for your aggregate then data at rest is encrypted for every volume on that aggregate. This means that NAE does not require any interaction with Trident in order to work. We will update the Trident documentation in the next few days with this information.
Refer to the Security hardening guide for NetApp ONTAP 9 for more information on NAE and NVE.
Hey @gnarl, does that mean that something has changed since @arndt-netapp made his description starting this issue? Because I've read that Trident refuses to provision storage if the aggregate is NAE enabled and I think @arndt-netapp ran into the same thing.
Hi @matalve,
From our testing we did not observe that NAE encryption could be disabled. We did observe that setting the encryption flag as "true" overrides NAE enabled aggregates with an NVE encrypted volume. This is a feature that allows the customer to choose the encryption that they need based on their use case. More information can now be found in the Trident documentation. Reading the Security hardening guide for NetApp ONTAP 9 is also recommended.
Can you please point to the Trident release where NAE support was added? I assume your testing was made with the latest version of Trident.
Previously linked NetApp Docs issue from February says it's not possible for Trident to handle NAE and the documentation was changed. Has it now been changed again to saying NAE is ok?
@matalve and @arndt-netapp,
I need to apologize as @arndt-netapp's original post is correct. The issue is that current Trident versions send a "false" flag for the encryption value when a volume is created. I initially thought that this only applied to NVE. In the case of when NAE is enabled, setting the encryption value to false for volume creation results in an error of "Unencrypted volumes are not supported in NAE (NetApp Aggregate Encryption) aggregates.".
With commit 418b9eb Trident will not set the encryption value if it is not specified in the backend configuration file. This will allow volumes to be created on NAE enabled aggregates. This change will be available in the Trident 22.10 release.
@matalve and @arndt-netapp,
I need to apologize as @arndt-netapp's original post is correct. The issue is that current Trident versions send a "false" flag for the encryption value when a volume is created. I initially thought that this only applied to NVE. In the case of when NAE is enabled, setting the encryption value to false for volume creation results in an error of "Unencrypted volumes are not supported in NAE (NetApp Aggregate Encryption) aggregates.".
With commit 418b9eb Trident will not set the encryption value if it is not specified in the backend configuration file. This will allow volumes to be created on NAE enabled aggregates. This change will be available in the Trident 22.10 release.
How to work around this now? I am having this exact issue. Is the solution to remove the encryption parameter completely from the backend config or to set it to "true"?
Just remove the encryption parameter from your configuration and you should get the default encryption behavior for the platform/aggregate you are provisioning on.
From: Janina Uhl @.> Date: Wednesday, May 24, 2023 at 10:35 AM To: NetApp/trident @.> Cc: Arndt, Michael @.>, Mention @.> Subject: Re: [NetApp/trident] Add a third volume provisioning encryption choice for ONTAP drivers to allow for NAE configurations (Issue #672)
@matalvehttps://github.com/matalve and @arndt-netapphttps://github.com/arndt-netapp,
I need to apologize as @arndt-netapphttps://github.com/arndt-netapp's original post is correct. The issue is that current Trident versions send a "false" flag for the encryption value when a volume is created. I initially thought that this only applied to NVE. In the case of when NAE is enabled, setting the encryption value to false for volume creation results in an error of "Unencrypted volumes are not supported in NAE (NetApp Aggregate Encryption) aggregates.".
With commit 418b9ebhttps://github.com/NetApp/trident/commit/418b9eb918fe5f253944868c1760132d43aff936 Trident will not set the encryption value if it is not specified in the backend configuration file. This will allow volumes to be created on NAE enabled aggregates. This change will be available in the Trident 22.10 release.
How to work around this now? I am having this exact issue. Is the solution to remove the encryption parameter completely or to set it to "true"?
— Reply to this email directly, view it on GitHubhttps://github.com/NetApp/trident/issues/672#issuecomment-1561280335, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE6WSUDNMGR3W2GV737ZSBDXHYMBNANCNFSM5HOIWOVA. You are receiving this because you were mentioned.Message ID: @.***>