[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:
Depends
depends on WT-3602 compatible=(release=2.9) is insuffici... Closed
depends on SERVER-30242 Add a method to determine if fCV has ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage 2017-10-23
Participants:

 Description   

SERVER-30242 addresses a bug in encryption at rest that triggers an unintentional downgrade. We need to assert that the fix for SERVER-30242 correctly addresses this problem.



 Comments   
Comment by Daniel Gottlieb (Inactive) [ 18/Oct/17 ]

The FCV work to downgrade correctly was added in SERVER-31513. This ticket was re-purposed for a discovered problem that prevented downgrading from 3.6 to 3.4 in the encryption at rest keystore instance.

Comment by Githook User [ 18/Oct/17 ]

Author:

{'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}

Message: SERVER-31211: Use config_base=false on the encryption at rest WT instance.
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/49e815bc0fe2a44980020f58f0ecaca1b38e16e7

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, WT-3602 is fixed and merged and will be in the next drop.

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 WT-3602. As a reminder, encryption at rest creates a second WiredTiger database, known as the keystore database, to store the encryption keys (which itself is encrypted via a master key, typically managed by a kmip server).

Key rotation is a means of re-encrypting the keystore database. A refresher on how that works:

  1. Connect to KMIP to retrieve the master key and open the original keystore database
  2. Request a new encryption key from KMIP.
  3. Create a new WiredTiger keystore database in a temporary directory, writing data out with the new encryption key.
  4. Read all the data from the original keystore and copy it to the new keystore.
  5. Close both WiredTiger keystores and moving the new keystore in place and invalidating the old keystore.

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.

Generated at Thu Feb 08 04:26:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.