[MDEV-28330] Hashicorp: Document key caching and key version caching Created: 2022-04-17  Updated: 2023-11-27  Resolved: 2022-05-10

Status: Closed
Project: MariaDB Server
Component/s: Documentation, Encryption, Plugins
Affects Version/s: N/A
Fix Version/s: 10.9.1

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Julius Goryavsky
Resolution: Fixed Votes: 0
Labels: Cloned

Issue Links:
Blocks
Issue split
split to MDEV-28528 Hashicorp Vault plugin: documentation... Closed
PartOf
is part of MDEV-28494 Hashicorp plugin documentation Closed
Relates
relates to MDEV-19281 Vault Key Management Plugin Closed

 Description   

According to the description in hashicorp_key_management.cnf, key cache related variables mean the following:

--[loose-]hashicorp-key-management-caching-enabled="on"|"off"

Enable key caching (storing key values received from
the Hashicorp Vault server in the local memory). By default
caching is enabled.

--[loose-]hashicorp-key-management-cache-timeout=<timeout>

The time (in milliseconds) after which the value of the key
stored in the cache becomes invalid and an attempt to read this
data causes a new request send to the vault server. By default,
cache entries become invalid after 60,000 milliseconds (after
one minute).

The test below does the following:

  • configure keys 1 and 4 in the vault;
  • create a table with ENCRYPTION_KEY_ID=4, so that the key has been read;
  • reconfigure the vault to remove key 4;
  • try to create another table with ENCRYPTION_KEY_ID=4.

Since key cache is enabled and the (default) timeout is 60 seconds, presumably it should still work and the table should be created using the key from the cache. It doesn't happen however, the statement fails due to the missing key.

# The test presumes that the local vault is running at $VAULT_ADDR,
 
# and the token is configured in $VAULT_TOKEN
 
 
 
--source include/have_innodb.inc
 
 
 
--exec vault secrets disable bug
 
--exec vault secrets enable -path /bug -version=2 kv
 
--exec vault kv put /bug/1 data=01234567890123456789012345678901 > /dev/null
 
--exec vault kv put /bug/4 data=01234567890123456789012345678904 > /dev/null
 
 
 
--let $restart_parameters= --plugin-load-add=hashicorp_key_management --hashicorp-key-management-vault-url="$VAULT_ADDR/v1/bug/" --hashicorp-key-management-token="$VAULT_TOKEN"
 
 
 
--source include/restart_mysqld.inc
 
 
 
CREATE TABLE t1 (a VARCHAR(8)) ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=4;
 
INSERT INTO t1 VALUES ('foo'),('bar');
 
 
 
select @@hashicorp_key_management_caching_enabled, @@hashicorp_key_management_cache_timeout;
 
 
 
--exec vault secrets disable bug
 
--exec vault secrets enable -path /bug -version=2 kv
 
--exec vault kv put /bug/1 data=01234567890123456789012345678901 > /dev/null
 
 
 
CREATE TABLE t2 (a VARCHAR(8)) ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=4;
 
 
 
# Cleanup
 
DROP TABLE IF EXISTS t1, t2;
 
--exec vault secrets disable bug

preview-10.9-MDEV-20119-misc e62a2a0615

 
CREATE TABLE t1 (a VARCHAR(8)) ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=4;
 
INSERT INTO t1 VALUES ('foo'),('bar');
 
select @@hashicorp_key_management_caching_enabled, @@hashicorp_key_management_cache_timeout;
 
@@hashicorp_key_management_caching_enabled	@@hashicorp_key_management_cache_timeout
 
1	60000
 
 
 
CREATE TABLE t2 (a VARCHAR(8)) ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=4;
 
 
 
mysqltest: At line 24: query 'CREATE TABLE t2 (a VARCHAR(8)) ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=4' failed: ER_CANT_CREATE_TABLE (1005): Can't create table `test`.`t2` (errno: 140 "Wrong create options")

There are no test cases coming with the plugin to validate any cache functionality, so there is still a room for interpretation. If expectations in the test above are false, then at least add tests to indicate how the cache is expected to act, and document it accordingly.

 Comments   
Comment by Julius Goryavsky [ 2022-04-19 ]

elenst Inside the plugin, actually two separate caches are implemented - one stores the latest key values ​​(for each key version), the second stores only the latest version numbers for each of the keys.

From the server side, the plugin receives two types of requests - to find out the latest version number for the key and to find out the value of the key. The key value is then used to encrypt the data. If caching is completely disabled, or if the timeout parameters are set to zero, then executing a generic statement using keys makes two requests to the hashicorp server - to get the latest version number of the key and then to read the value of the key. If caching is enabled for key values, then the load on the server is ideally halved, because only reading the actual key version number requires a new call to the hashicorp server, but the key value itself can be read from the cache, assuming that the version number has not changed.

If both timeout parameters are not equal to zero, then the load on the server drops dramatically, because it is possible to do without requesting the number of the current version of the key. But the reverse side of the coin is that if the user changes the key from the hashicorp side, for example, using the administrative utility, then we will read outdated data until the timeout expires. This may not be safe for some of our users if they want to always encrypt with the latest version of the key. It is possible as a compromise to make the timeout value for the versions significantly less than the timeout value for the key values ​​themselves, however during debugging with customer they asked to keep the default behavior of the system and therefore the second parameter was set to zero.

A separate variable to enable or disable caching (instead of setting timeouts to zero) allows you to disable caching without losing the old timeouts so that caching can be enabled and disabled dynamically without losing the timeouts.

Comment by Elena Stepanova [ 2022-04-19 ]

I see, thanks. Then, please just add test cases for both caches and interaction of their timeouts.

Comment by Elena Stepanova [ 2022-05-07 ]

I'm keeping it open for documentation purposes.

Comment by Julius Goryavsky [ 2022-05-10 ]

Fixed: https://github.com/MariaDB/server/commit/0902cfaec8cf15c042b1c2159db8ffc97e9bce95
Sub-task related to documentation moved to: https://jira.mariadb.org/browse/MDEV-28528

Generated at Thu Feb 08 09:59:52 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.