WL#11543: instrument the keyring into performance schema
Affects: Server-8.0 — Status: Complete — Priority: Medium
Currently the keyring data are completely non-transparent to SQL users. This worklog aims at adding P_S tables to expose the metadata of the keys (key IDs, key owner), provided that the user has enough privileges to see these. When using an external key vault (OKV) it is useful to match the internal key ID used by the keyring infrastructure, to the ID that this key is stored in the Key Vault.
FR1: Add a Performance Schema table "keyring_keys" in the "performance_schema" database. FR2: Upon successful query of to query "keyring_keys" table, return the list of the keys in the active Keyring, showing only the key metadata (internal ID, owner and backend ID) FR3: Implement a component service function (in the plugins that can provide such information) to return the external (backend) ID used to store the key in external key vaults. FR4: No key data is going to be exposed in the keyring_keys table. No sensitive information about the keys should be exposed, only the IDs of the key (both internal and external) and the user are to be shown. FR5: Existing performance schema authentication will be reused. Only users with permissions to query the performance schema can access the keyring_keys table.
HLS1: A new table performance_schema.keyring_keys will be introduced. It will display details about the registered keys in the keyring CREATE TABLE IF NOT EXISTS keyring_keys ( KEY_ID VARCHAR(255) NOT NULL, KEY_OWNER VARCHAR(255), BACKEND_KEY_ID VARCHAR(255), ) HLS2: Existing performance schema authentication will be used
mysql_key_iterator is used to query the list of the keys. keyring->mysql_key_iterator_init() creates the iterator. keyring->mysql_key_iterator_get_key() queries the iterator until there is no more data or the iterator gets invalidated upon keyring modification. If implemented by the active keyring plugin, get_backend_key_id() component service function will be used to query the backend ID for each key returned by the iterator The iterator is thread-safe for reading. It is invalidated when the keyring gets modified. Consecutive calls to keyring->mysql_key_iterator_get_key() will fail so the query will prematurely complete. If a race condition occurs, the concurrent query to the keyring performance schema table will return incomplete data. Currently there is no way to know that the iterator got invalidated, in order to restart the collection of the key information. A vector of
structures is used to internally hold the list of the keys used for the current query. plugin_foreach() is used to query all the installed keyring plugins. The result set will hold a copy of the key information only for one of the installed keyring plugin(s). The rest of the installed keyring plugins (if any) will be ignored. Selecting which of the plugin to be used is undefined and may be random.
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.