[SERVER-31211] Use config_base=false for encryption at rest WT instance. Created: 21/Sep/17 Updated: 30/Oct/23 Resolved: 18/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Maria van Keulen | Assignee: | Daniel Gottlieb (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Storage 2017-10-23 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
|
| Comments |
| Comment by Daniel Gottlieb (Inactive) [ 18/Oct/17 ] |
|
The FCV work to downgrade correctly was added in |
| Comment by Githook User [ 18/Oct/17 ] |
|
Author: {'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}Message: |
| Comment by Susan LoVerso [ 26/Sep/17 ] |
|
I think it makes most sense to change the keystore database to include the config_base=false option in the same manner the normal MongoDB database does. I'd consider that a fix, not a workaround. In addition, |
| Comment by Daniel Gottlieb (Inactive) [ 25/Sep/17 ] |
|
The values being validated are from the WiredTiger.basecfg file generated for the keystore database. The encryption at rest code does not pass in config_base=false. The omission was benign. There are a few ways forward that we're working on. In the meantime it should be possible to get test working with a workaround. |
| Comment by Daniel Gottlieb (Inactive) [ 24/Sep/17 ] |
|
The problem Maria ran into is specifically when running an encryption at rest key rotation with a 3.6 mongod, followed by trying to downgrade to 3.4. I believe I've identified the cause, waiting on confirmation of Key rotation is a means of re-encrypting the keystore database. A refresher on how that works:
To ease downgrading scenarios, MongoDB 3.6 always uses compatibility=(release=2.9) for the keystore database, which is deemed acceptable because the data format changes are mostly for performance optimizations, and the keystore database is modified on only a fraction of the metadata changes to the "outer" database. However it seems, creating a new database with WiredTiger 3.0 (step 3) still adds a version of 3.0 to some metadata, regardless of the release compatibility that prevents access from WiredTiger 2.9, ergo, MongoDB 3.4. I don't believe databases created with WiredTiger 2.9 that are upgraded to 3.0 and downgraded back to 2.9 are affected in this way. |