WL#13446: Migrate Keyring APIs to Components

Affects: Server-8.0   —   Status: Complete

At present, keyring functionality in MySQL server is available through plugin APIs. MySQL server provides plugin service for plugins to call these APIs.

This worklog aims at converting them to component services.

Goal would be to: 1. Add required component services for keyring functionality 2. Add PoC with one of the keyring backend 3. Deprecate existing plugin APIs 4. Update plugin service to call component APIs

Further, worklog will try to leverage work done on minimal chasis and make sure that new services can be used on top of minimal chasis.

Contents

Motivation

There are two distinct parts to secure a MySQL server:

  • Deployment security:
    • Relies on security provided by OS
    • Makes sure that packages are installed in a secure manner
    • Configures parts of server at initialization time to make sure we have a secure instance by default
    • Handled by various compile time defaults and packaging scripts
  • Operational security
    • Makes sure that there is no privilege escalation that may impact MySQL server OR the underlying host
    • Leverages on authentication and authorization capabilities built-in with server
    • Allows encryption of sensitive content to provide security for data-at-rest
    • Provides capabilities to secure communication links

Deployment security is fundamental block on which operational security relies.

At present Keyring falls into operational security because it is possible to configure keyring through system variables which can be configured using SQL.

Example: It is possible to make hashicorp keyring plugin to point to a different key server at run time by setting appropriate system variable.

This, managing keyring through server operations, is very convenient. However, if we want to secure everything in server - including server configuration using keyring, we must ground security in it. That is - we must make sure that any database operation CAN NOT CHANGE keyring's configuration. If we allow changes in keyring configuration through database operations, we essentially allow database to manage its trust store itself - which breaks the trust we placed in keyring.

Definitions

  • Keyring: A backend that can store sensitive data securely
  • Keyring manager: An interface to Keyring to manage sensitive data

Functional Requirements

Ability to load components early in bootstrap sequence

  • LOAD_FR_1: MySQL server should auto-discover a manifest file and load components listed in it.
  • LOAD_FR_2: MySQL server should not be able to modify Manifest file.
  • LOAD_FR_3: Manifest file should be read only during server start-up.
  • LOAD_FR_4: Deployment scripts should create a placeholder manifest file at the time of installation.

Keyring component service and its implementations

  • KEYRING_FR_1: New component services should be introduced to provide following functionalities from keyring:
    • Read sensitive data
    • Write/Erase sensitive data
    • Generate secrets
    • Iterators
    • Encryption/Decryption
    • Status
    • Utilities
  • KEYRING_FR_2: Two new component service implementations should be introduced that provide implementation of keyring component services mentioned in KEYRING_FR_1
    • A file based keyring component - Available in community edition
    • An encrypted file based keyring component - Available in enterprise edition
  • KEYRING_FR_3: It should be possible to load keyring components mentioned in KEYRING_FR_2 using MySQL server's manifest file (Refer to LOAD_FR_1).
  • KEYRING_FR_4: It should be possible to query keyring status from MySQL server process.

Supporting keyring migration

  • MIGRATION_FR_1: A new binary should be created to support migration from one keyring to the other.
  • MIGRATION_FR_2: It should be possible to perform migration while server is using the keyring.
    • MIGRATION_FR_2.1: MySQL server component should provide an implementation of keyring services mentioned in KEYRING_FR_1 to facilitate access control and locking.
  • MIGRATION_FR_3: To facilitate transition from keyring plugin to keyring components, it should be possible to migrate keys from format used by keyring_encrypted_file plugin to keyring components (refer KEYRING_FR_2).

Adaptation of keyring component and deprecation of keyring plugin

  • ADAPTATION_FR_1: Usage of keyring plugin should be deprecated.
  • ADAPTATION_FR_2: MySQL server should provide an implementation of keyring component services(refer KEYRING_FR_1) that serves as a proxy. It should use keyring component if one is available or use keyring plugin otherwise.
  • ADAPTATION_FR_3: Existing usage of Keyring plugin service APIs should be replaced by that of proxy implementation mentioned in ADAPTATION_FR_2 above.
  • ADAPTATION_FR_4: It should be possible to trigger reload of keyring component through SQL interface.

Contents

Ability to load components early in bootstrap sequence

  • LOAD_HLS_1: A generic, header-only mechanism will be introduced that will facilitate reading manifest file for any given binary.
    • LOAD_HLS_1.1: The manifest file name should be: <binary_name>.my. E.g. mysqld.my.
    • LOAD_HLS_1.2: The manifest file should be in valid JSON format.
    • LOAD_HLS_1.3: Location of such a manifest file will be decided by the binary.
  • LOAD_HLS_2: MySQL server will use manifest file to identify and load components early in the bootstrap sequence
    • LOAD_HLS_2.1: MySQL server will attempt to read manifest file from following locations
      • Global manifest file: In the same directory where binary resides
      • Local manifest file: If global manifest file contains flag to use local level manifest file, then process shall attempt to read manifest file local to the instance from the data directory.
    • LOAD_HLS_2.2: Creation of manifest file for MySQL server should be user's responsibility. Users shall setup global manifest and instance level manifest as per their requirement before starting MySQL server.
  • LOAD_HLS_3: The format of manifest file for MySQL server will be:

Global or Local manifest file can list components to be loaded in following manner: 

{
  "components": "<component_uri>"
}

Alternatively, global manifest file can contain flag to read local manifest file 

{
  "read_local_manifest": <true|false>
}

Example:

{
  "components": "file://component_name"
}
  • LOAD_HLS_4: MySQL server will attempt to read instance manifest file iff global manifest file has "read_local_manifest" set to TRUE.
    • LOAD_HLS_4.1: If "read_local_manifest" is set to TRUE in global manifest file, but no local manifest file exists, it will be treated as an indicator that given instance does not wish to load any component. This is not an error state.
  • LOAD_HLS_5: In case of MySQL server, Manifest file will be read after data directory path is available.
  • LOAD_HLS_6: Server shall push a warning in log file if manifest file is present and is not RO.
  • LOAD_HLS_7: Server shall attempt to load components mentioned in manifest file. Upon failure, server start-up will halt.
  • LOAD_HLS_8: Component loaded through manifest file will be unloaded at the time of server shutdown.

Keyring component service and its implementations

  • KEYRING_HLS_1: Following new component services will be introduced
Keyring reader service

DEFINE_SERVICE_HANDLE(my_h_keyring_reader_object);

BEGIN_SERVICE_DEFINITION(keyring_reader_with_status)

/**
  Initialize reader

  @param [in]  data_id          Data Identifier
  @param [in]  auth_id          Authorization ID
  @param [out] reader_object    Reader object

  @returns status of the operation
    @retval -1 Keyring error. reader_object will not be created.
    @retval  0 Key not found OR error fetching keys.
               reader_object will not be created.
    @retval  1 Key found, check out parameters
*/
DECLARE_METHOD(int, init,
               (const char *data_id, const char *auth_id,
                my_h_keyring_reader_object *reader_object));

/**
  Deinitialize reader

   @param [in] reader_object    Reader object

   @returns status of the operation
     @retval false Success
     @retval true  Failure
*/
DECLARE_BOOL_METHOD(deinit, (my_h_keyring_reader_object reader_object));

/**
  Fetch length of the data if it exists
  data_size and data_type_size must not be nullptr.

  Data_type value is implementation specific. It associates type
  label with data which may be an important indicator for certain
  backends.

  Minimum expectation: AES, SECRET

  @param [in]  reader_object      Reader object
  @param [out] data_size          Size of fetched data in bytes
  @param [out] data_type_size     Size of data type

  @returns status of the operation
    @retval false success
    @retval true  failure
*/
DECLARE_BOOL_METHOD(fetch_length, (my_h_keyring_reader_object reader_object,
                                   size_t *data_size, size_t *data_type_size));

/**
  Fetches data if it exists.
  All pointer parameters must be non-null.

  Data_type value is implementation specific. It associates type
  label with data which may be an important indicator for certain
  backends.

  Minimum expectation: AES, SECRET

  data_buffer size must be enough to hold data
  data_type size must be enough to hold datatype and
  a null-terminating character

  @sa fetch_length - To fetch length information about sensitive data

  @param [in]  reader_object           Reader object
  @param [out] data_buffer             Out buffer for data
  @param [in]  data_buffer_length      Length of out buffer
  @param [out] data_size               Size of fetched data
  @param [out] data_type               Type of data
  @param [in]  data_type_buffer_length Length of data type buffer
  @param [out] data_type_size          Size of fetched datatype

  @returns status of the operation
    @retval false success
    @retval true  failure
*/


DECLARE_BOOL_METHOD(fetch,
                    (my_h_keyring_reader_object reader_object,
                     unsigned char *data_buffer, size_t data_buffer_length,
                     size_t *data_size, char *data_type,
                     size_t data_type_buffer_length, size_t *data_type_size));

END_SERVICE_DEFINITION(keyring_reader_with_status)
Keyring writer service

BEGIN_SERVICE_DEFINITION(keyring_writer)

/**
  Store data identified with (data_id, auth_id) in keyring backend

  Data_type value is implementation specific. It associates type
  label with data which may be an important indicator for certain
  backends.

  Examples: AES, SECRET

  Note: If components want to support aes_encryption service,
  it must spport storing data of type AES.

  A success status implies that data is stored persistently on
  keyring backend and shall always be available for access unless
  removed explicitly.

  @note Implementation can restrict type and/or size of data that can be
        stored in keyring.

  @param [in]  data_id        Data Identifier
  @param [in]  auth_id        Authorization ID
  @param [in]  data           Data to be stored
  @param [in]  data_size      Size of data to be stored
  @param [in]  data_type      Type of data

  @returns status of the operation
    @retval false Success - Data is stored successfully in backend
    @retval true  Failure
*/

DECLARE_BOOL_METHOD(store, (const char *data_id, const char *auth_id,
                            const unsigned char *data, size_t data_size,
                            const char *data_type));

/**
  Remove data identified by (data_id, auth_id) from keyring backend
  if present.

  Data_type value is implementation specific. It associates type
  label with data which may be an important indicator for certain
  backends.

  Examples: AES, SECRET

  Once removed, data should not be accessible through keyring implementation.
  Based on keyring backend, implementor may decide to either destroy the data
  completely or change the state of the data to make in unavailable.

  @param [in] data_id Data Identifier
  @param [in] auth_id Authorization ID

  @returns status of the operation
    @retval false Success - Key removed successfully or key not present.
    @retval true  Failure
*/

DECLARE_BOOL_METHOD(remove, (const char *data_id, const char *auth_id));
Keyring generator service

BEGIN_SERVICE_DEFINITION(keyring_generator)

/**
  Generate random data of length data_size and
  store it in keyring using identifiers as (data_id, auth_id).

  Data_type value is implementation specific. It associates type
  label with data which may be an important indicator for certain
  backends.

  Examples: AES, SECRET

  Note: If components want to support aes_encryption service,
  it must spport storing data of type AES.

  If error object is not initialized, the method will initialize it if returns
  false. Caller will be responsible for freeing error state in such cases.
  No error object will be created or modified if return value is true.

  The action should be atomic from caller's point of view.
  As much as possible, deligate data generation to keyring backend.

  @note Implementation can restrict type and/or size of data that can be
        stored in keyring.

  @param [in]  data_id   Data Identifier
  @param [in]  auth_id   Authorization ID
  @param [in]  data_type Type of data. Assumed null terminated.
  @param [in]  data_size Size of the data to be generated

  @returns status of the operation
    @retval false Success - Key generated and stored in keyring.
    @retval true Failure
*/

DECLARE_BOOL_METHOD(generate, (const char *data_id, const char *auth_id,
                               const char *data_type, size_t data_size));
Keyring keys metadata iterator service
DEFINE_SERVICE_HANDLE(my_h_keyring_keys_metadata_iterator);

BEGIN_SERVICE_DEFINITION(keyring_keys_metadata_iterator)

/**
  Forward iterator initialization.

  This function allocates required memory for forward_iterator and initializes
  it. Caller should use deinit() to perform clean-up.

  An iterator may become invalid if content of keyring is changed.

  @param [out] forward_iterator metadata iterator

  @returns Status of the operation
    @retval false Success
    @retval true  Failure
*/

DECLARE_BOOL_METHOD(init,
                    (my_h_keyring_keys_metadata_iterator * forward_iterator));

/**
  Iterator deinitialization

  @note forward_iterator should not be used after call to deinit

  @param [in, out] forward_iterator metadata iterator

  @returns Status of the operation
    @retval false Success
    @retval true  Failure
*/

DECLARE_BOOL_METHOD(deinit,
                    (my_h_keyring_keys_metadata_iterator forward_iterator));

/**
  Check validity of the iterator

  @param [in] forward_iterator metadata iterator

  @returns Validty of the iterator
    @retval true  Iterator is valid
    @retval false Iterator is invalid
*/
DECLARE_BOOL_METHOD(is_valid,
                    (my_h_keyring_keys_metadata_iterator forward_iterator));

/**
  Move iterator forward.

  @param [in,out] forward_iterator metadata iterator

  @returns Status of the operation
    @retval false Success - indicates that iterator is pointing to next entry
    @retval true  Failure - Failure in moving iterator forward or next was
                            called after iterator reached the end.
*/

DECLARE_BOOL_METHOD(next,
                    (my_h_keyring_keys_metadata_iterator forward_iterator));


/**
  Fetch metadata for current key pointed by iterator

  Out buffers should be big enough to accomodate data + null terminating
  character

  @param [in]  forward_iterator forward_iterator metadata iterator
  @param [out] data_id          ID information of current data
  @param [in]  data_id_length   Length of data_id buffer
  @param [out] auth_id          Owner of the key
  @param [in]  auth_id_length   Length of auth_id buffer

  @returns Status of the operation
    @retval false Success
    @retval true  Failure
*/
DECLARE_BOOL_METHOD(get, (my_h_keyring_keys_metadata_iterator forward_iterator,
                          char *data_id, size_t data_id_length, char *auth_id,
                          size_t auth_id_length));


END_SERVICE_DEFINITION(keyring_keys_metadata_iterator)
Keyring initialize service
BEGIN_SERVICE_DEFINITION(keyring_initialize)

/**
  Initialize keyring

  A call to initialize service API should result into
  - Reading keyring configuration from its source
  - Connecting to keyring backend
  - Fetch information about stored key and populate
    new in-memory structures - as needed

  Note: This routine should be called only once - typically right after
        loading keyring component.

  @param [in]  component_path Path to component's shared library

  @retval Status of the operation
    @retval false Success
    @retval true  Failure
*/

DECLARE_BOOL_METHOD(initialize, (const char *component_path));

END_SERVICE_DEFINITION(keyring_initialize)
Keyring reload service
BEGIN_SERVICE_DEFINITION(keyring_reload)

/**
  Reload keyring

  A call to reload service API should result into
  - Reading keyring configuration from its source
  - Reconnecting to keyring backend
  - Fetch information about stored key and populate
    new in-memory structures - as needed
  - On success, cleanup old in-memory data
  - On  failure, cleanup new in-memory data and
    return to previous good state

  @retval Status of the operation
    @retval false Success
    @retval true  Failure
*/

DECLARE_BOOL_METHOD(reload, ());

END_SERVICE_DEFINITION(keyring_reload)
Keyring status service
BEGIN_SERVICE_DEFINITION(keyring_component_status)

/**
  Returns status of the keyring component

  returns true if keyring initialized, false otherwise.
*/
DECLARE_BOOL_METHOD(keyring_initialized, ());

END_SERVICE_DEFINITION(keyring_component_status)
Keyring metadata query service
DEFINE_SERVICE_HANDLE(my_h_keyring_component_metadata_iterator);

BEGIN_SERVICE_DEFINITION(keyring_component_metadata_query)

/**
  Initialize metadata iterator. deinit should be called for clean-up.

  @param [out] metadata_iterator Metadata iterator handle

  @returns Status of iterator initialization
    @retval false Success
    @retval true  Failure.
*/
DECLARE_BOOL_METHOD(init, (my_h_keyring_component_metadata_iterator *
                           metadata_iterator));

/**
  Deinitialize metadata iterator

  @param [in, out] metadata_iterator Metadata iterator handle

  @returns Status of iterator deinitialization
    @retval false Success
    @retval true  Failure.
*/
DECLARE_BOOL_METHOD(
    deinit, (my_h_keyring_component_metadata_iterator metadata_iterator));

/**
  Check validity of iterator

  @param [in] metadata_iterator Metadata iterator handle

  @returns Validity of the the iterator
    @retval true  Iterator valid
    @retval false Iterator invalid
*/
DECLARE_BOOL_METHOD(
    is_valid, (my_h_keyring_component_metadata_iterator metadata_iterator));

/**
  Move iterator forward

  @param [in, out] metadata_iterator Metadata iterator handle

  @returns Status of operation
    @retval false Success
    @retval true  Failure. Either iterator already reached end position
                           or some other error was encountered.
*/
DECLARE_BOOL_METHOD(
    next, (my_h_keyring_component_metadata_iterator metadata_iterator));

/**
  Get length information about metadata key and value

  @param [in]  metadata_iterator   Metadata iterator handle
  @param [out] key_buffer_length   Length of the key buffer
  @param [out] value_buffer_length Length of the value buffer

  @returns Get length information about key and value
    @retval false Success check out paramters
    @retval true  Failure
*/
DECLARE_BOOL_METHOD(get_length,
                    (my_h_keyring_component_metadata_iterator metadata_iterator,
                     size_t *key_buffer_length, size_t *value_buffer_length));

/**
  Get name and value of metadata at current position

  @param [in]  metadata_iterator   Metadata iterator handle
  @param [out] key_buffer          Output buffer for key
  @param [in]  key_buffer_length   Length of key buffer
  @param [out] value_buffer        Output buffer for value
  @param [in]  value_buffer_length Length of value buffer

  @returns Status of fetch operation
    @retval false Success
    @retval true  Failure
*/
DECLARE_BOOL_METHOD(get,
                    (my_h_keyring_component_metadata_iterator metadata_iterator,
                     char *key_buffer, size_t key_buffer_len,
                     char *value_buffer, size_t value_buffer_len));


END_SERVICE_DEFINITION(keyring_component_metadata_query)
Keyring encryption/decryption service

BEGIN_SERVICE_DEFINITION(keyring_aes_encryption)

/**
  Retrieve required out buffer length information

  @param [in]  input_length Length of input text
  @param [in]  mode         AES mode
  @param [in]  block_size   AES block size information
  @param [out] out_size     Size of out buffer

  @returns Output buffer length or error
    @retval false Success
    @retval true  Error processing given mode and/or block size
*/
DECLARE_BOOL_METHOD(get_size,
               (size_t input_length, const char *mode, size_t block_size,
                size_t *out_size));

/**
  Encrypt given piece of plaintext

  Block mode for operation (e.g. "ecb", "cbc", cfb1",...)
  Block size (e.g. 256)

  Length of out buffer should be sufficient to hold ciphertext
  data. See get_size() API.

  Encrypted data should be stored in out_buffer with out_length
  set to actual length of data.

  IV must be provided if block mode of operation requires it.

  It is caller's responsibility to supply same IV for encryption/decryption.

  @param [in]  data_id            Name of the key
  @param [in]  auth_id            Owner of the key
  @param [in]  mode               AES mode
  @param [in]  block_size         AES block size information
  @param [in]  iv                 Initialization vector
  @param [in]  padding            padding preference (0 implies no padding)
  @param [in]  data_buffer        Input buffer
  @param [in]  data_buffer_length Input buffer lenth
  @param [out] out_buffer         Output buffer
  @param [in]  out_buffer_length  Output buffer length
  @param [out] out_length         Length of encrypted data

  @returns status of the operation
    @retval false Success
    @retval true  Failure

*/
DECLARE_BOOL_METHOD(encrypt,
                    (const char *data_id, const char *auth_id, const char *mode,
                     size_t block_size, const unsigned char *iv, int padding,
                     const unsigned char *data_buffer,
                     size_t data_buffer_length, unsigned char *out_buffer,
                     size_t out_buffer_length, size_t *out_length));

/**
  Decrypt given piece ciphertext

  Block mode for operation (e.g. "ecb", "cbc", cfb1",...)
  Block size (e.g. 256)

  Length of out buffer should be sufficient to hold ciphertext
  data. See get_size() API.


  If block mode requires IV, same should be provided by caller.
  This should same IV that was used for encryption operation.

  @param [in]  data_id            Name of the key
  @param [in]  auth_id            Owner of the key
  @param [in]  mode               AES mode
  @param [in]  block_size         AES block size information
  @param [in]  iv                 Initialization vector
  @param [in]  padding            padding preference (0 implies no padding)
  @param [in]  data_buffer        Input buffer
  @param [in]  data_buffer_length Input buffer lenth
  @param [out] out_buffer         Output buffer
  @param [in]  out_buffer_length  Output buffer length
  @param [out] out_length         Length of decrypted data

  @returns status of the operation
    @retval false Success
    @retval true  Failure

*/
DECLARE_BOOL_METHOD(decrypt,
                    (const char *data_id, const char *auth_id, const char *mode,
                     size_t block_size, const unsigned char *iv, int padding,
                     const unsigned char *data_buffer,
                     size_t data_buffer_length, unsigned char *out_buffer,
                     size_t out_buffer_length, size_t *out_length));
  • KEYRING_HLS_2: A keyring service implementation will be added that uses flat file as backend. Component name - component_keyring_file.so/.dll
    • KEYRING_HLS_2.1: This component will implement all services mentioned in KEYRING_HLS_1.
  • KEYRING_HLS_3: File used by the component will be in JSON format
{
  "version": "1.0",
  "elements": [
    {
      "user": "<user_name>",
      "data_id": "<name>",
      "data_type": "<data_type>",
      "data": "<hex_of_data>",
      "extension": [
      ]
    },
    ...
    ...
  ]
}
  • KEYRING_HLS_4: The component mentioned in KEYRING_HLS_2 will read configuration from configuration file that is located in same directory as component binary. It should be in following format:
{
  "path": "/full/path/to/keyring/file",
  "read_only": true | false
}

OR 

{ "read_local_config": <true|false> }
    • KEYRING_HLS_4.1: If configuration file at above mentioned location contains 
       {"read_local_config": true}
      , then binary shall attempt to read configuration file from current working directory.
    • KEYRING_HLS_4.1.1: In case of MySQL server, keyring component is loaded by processing server's manifest file. At this point, server's current working directory is set to data directory. Thus, in case of MySQL server, local configuration will be read from data directory.
  • KEYRING_HLS_5: A keyring service implementation will be added that uses encrypted flat file as backend. Component name - component_keyring_encrypted_file.so/.dll
  • KEYRING_FILE_6: Component shall create data representation similar to KEYRING_HLS_1.1 before encrypting it. Encrypted content will then be converted to HEX and stored in flat file.
  • KEYRING_HLS_7: Component will use AES encryption with CBC mode and 512 bit key.
  • KEYRING_HLS_8: The component mentioned in KEYRING_HLS_5 will read configuration from configuration file that is located in same directory as component binary. It should be in following format:
{
  "path": "/full/path/to/keyring/file",
  "password": "<passphrase>",
  "read_only": true | false
}
  • KEYRING_HLS_9: A new performance schema table - keyring_component_status will be introduced. It shall fetch status information from keyring component and display it in tabular format.
    • KEYRING_HLS_9.1: The table will have two columns: 1> STATUS_KEY VARCHAR(256) 2> STATUS_VALUE VARCHAR(1024)

Error logging

  • ERROR_LOGGING_1: Keyring components described in previous section will rely on following component services for error logging:
    • log_builtins
    • log_builtins_string
  • ERROR_LOGGING_2: When keyring component is used for MySQL server binary, MySQL server component's implementation of above mentioned services will be used by keyring component.
  • ERROR_LOGGING_3: When keyring component is used for other binaries where log_builtins/log_builtins_string are not available, keyring components will use implementation of these services provided by itself.
    • ERROR_LOGGING_3.1: The implementation is not as rich as server's implementation. It will make sure that macros like LogErr/LogComponentErr works.

Supporting keyring migration

  • MIGRATION_HLS_1: A new binary - mysql_migrate_keyring, will be introduced to support migration from one keyring component format to another.
  • MIGRATION_HLS_2: The binary will accept following parameters:
    • Directory where components are located: --component-dir=<path>
    • Source keyring component: --source='<uri>'
    • Destination keyring component: --destination='<uri>'
      • --online-migration
      • HOST | PORT or SOCKET details:
        • --host
        • --port
        • --socket
      • TLS parameters
        • --ssl-ca
        • --ssl-capath
        • --ssl-cert
        • --ssl-key
        • --ssl-crl
        • --ssl-crlpath
        • --ssl-mode
        • --ssl-cipher
        • --tls-cipherlist (for TLSv1.3 ciphers)
        • server-public-key-path
        • get-server-public-key
      • User name: --user
      • Password: --password
  • MIGRATION_HLS_3: New binary will report required information indicating migration status.
  • MIGRATION_HLS_4: mysql_keyring_migrate will load minimal chassis so that required source/destination keyring components can be loaded.
  • MIGRATION HLS_5: In order to migrate from keyring plugin to keyring component, MySQL server's migration functionality will be extended. Server will now support following new command line options:
    • --keyring-migration-to-component: It signals that destination is a keyring component. This way, it is possible to migrate from any keyring plugin to any keyring component.

Adaptation of keyring component and deprecation of keyring plugin

  • ADAPTATION_HLS_1: Installation of keyring plugin should throw a deprecation warning.
  • ADAPTATION_HLS_2: Keyring plugin service should be updated to mention deprecation details.
  • ADAPTATION_HLS_3: MySQL server component will provide 2 implementation of services mentioned in KEYRING_HLS_1.
    • ADAPTATION_HLS_3.1: An implementation that exposes keyring plugin APIs through keyring component service APIs. It will use keyring plugin service to call plugin APIs.
      • ADAPTATION_HLS_3.1.1: This will be implemented through a static daemon plugin - daemon_keyring_proxy_plugin, within MySQL server. When we decide to remove keyring plugins completely, this plugin can be removed.

Notes to Documentation: This plugin, even though builtin, is indeed a pluginn and serves as a bridge between keyring component service APIs and keyring plugin service APIs.

    • ADAPTATION_HLS_3.2: An implementation that restricts access to Keyring component (Or proxy implementation as mentioned in ADAPTATION_HLS_3.1) using RWLock.
      • ADAPTATION_HLS_3.2.1: This will be default implementation of keyring component services.
  • ADAPTATION_HLS_4: MySQL server binary will maintain a global reference to keyring component service. The server binary will try to acquire this reference at following places:
    • Once the server manifest file is read. See LOAD_HLS_3.
    • If no keyring component was loaded through manifest file, server will try to acquire the reference after daemon plugin mentioned in ADAPTATION_HLS_3.1 is initialized.
  • ADAPTATION_HLS_5: Existing keyring clients, that uses keyring plugin services will be modified to use keyring component service APIs.
  • ADAPTATION_HLS_6: A new SQL: ALTER INSTANCE RELOAD KEYRING will be introduced to reload keyring component.
    • Binlogged: No
    • Privilege Requirement: ENCRYPTION_KEY_ADMIN


Copyright (c) 2000, 2024, Oracle Corporation and/or its affiliates. All rights reserved.