Upstream spec proposed describing a potential implementation

https://specs.openstack.org/openstack/manila-specs/specs/dalmatian/share_encryption.html 

What are the use cases this RFE is solving?

This allows users to create and control the keys for encrypted shares, from manila itself or to provide an encryption key (stored in barbican). In either scenario, after the key is fetched it will be given to the storage back end driver, NetApp supports this.

High Level view on how the feature works

There are broadly two levels of encryption: "front-end" (data in-transit) and "back-end" (data at-rest). Currently, users can request back-end data encryption via share types that have custom extra-specs. These custom-extra specs direct the back end driver to encrypt the share data at rest. If a share is

created using such share types, Manila will generate an encryption key with the help of Barbican. Ideally, users must be allowed to create and manage their own encryption keys. This RFE proposes an approach that enables Manila to coordinate user defined encryption keys for "back-end" (at rest) encryption of share/volume data. 

Is this feature driver dependent or driver related?

No. Administrators would be able to provide configuration for Barbican and the configuration could be applied in the backends. Manila will have barbican only as the key manager for the encryption in the backends.

 

Are there any known limitations? (e.g multi attach + encryption)

No

 

Is a CLI change required, does the openstack cmd support it?

Yes. New CLI commands must be implemented for managing the encryption types in Manila.

 

Does this RFE impact / need to be included into the control plane podification?

It will be included and it is being tracked as part of this epic.

 

Does this RFE benefit/impact DCN?

No.

 

Does this RFE benefit/impact shift on stack?

Not specifically shift on stack, but the feature would be widely available to be used..

 

Can this feature be turned on or used in an existing environment?

Yes, but it may be hard with shares that are already created.

 

Does this feature affect another DFG or product?

Manila-operator is likely being impacted by this as well.

 

Does this feature depend on another RFE?

No

 

How will the feature affect Upgrades?

It will not affect upgrades.

 

How will the feature affect performance or scaling?

It will not affect performance/scaling, as the encryption itself is not done by Manila. Manila will only manage the encryption keys.

 

What are the test cases for this RFE?

CRUD for encryption types, as well as possible scenario tests for ensuring that the shares are encrypted.

 

Are there CI implications?

We cannot test that the data itself is encrypted but can be sure that the correct API calls are being made by manila and Barbican. Tempest tests should suffice.

 

Does it have documentation impact and require early planning with the doc team?

Yes.

 

Are there known packaging challenges?

No.

 

Are there any security considerations?

Shares created with a share type that has an encryption type might end up being encrypted in the backend. This can help with security hardening for the shares.

 

How much upstream resistance might there be to this feature?

None.

 

Will this feature require new or different support skills?

No

 

Will this be required for knowledge transfer to GSS?

Yes.

 

Will this feature impact existing partners or certification programs?

NetApp supports encryption, Ceph does not. Will need to update the compatibility matrix.

 

API Deprecation/Compatibility?

No.

 

Are any GUI impact/changes required (Horizon)?

Yes there is an impact, we will need to add support in manila-ui.