Hi !
I don’t understand why when I have the audit and encryption components on the same instance, the audit component pushes an encryption key into my vault even though it is explicitly asked not to encrypt anything. Do you think this is a bug?
I use PS 8.4.4
mysql> show variables like 'audit_log_filter.encryption%';
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+
| audit_log_filter.encryption | NONE |
+-----------------------------+-------+
1 row in set (0.00 sec)
mysql> SELECT * FROM performance_schema.keyring_keys;
+-----------------------------+-----------+----------------+
| KEY_ID | KEY_OWNER | BACKEND_KEY_ID |
+-----------------------------+-----------+----------------+
| audit_log-20250604T105008-1 | audit_log | |
+-----------------------------+-----------+----------------+
1 row in set (0.00 sec)
If the key isn’t actually being used, I would not consider it a bug, but an annoyance. It could be behavior that “if encryption enabled, generate key” and no option to disable that condition.
The problem this actually poses is in the case of restoring a production encrypted data backup to another instance. Currently, when this is the case, I tell PS to point to the kv Hashicorp Vault containing the production encryption keys but using a token that only has RO rights. With this operation, PS will try to create a key for the audit log in my production vault and will not have the rights and will crash.
We didn’t have this problem with the modules.
As per the documentation below, it is expected that if you have encryption enabled on the server and then you are trying to install the audit log filter, then it generates an initial password that is stored inside the keyring. So this is expected behaviour, and your vault should have the permission to write this key as well. Even if you have write permission to the vault, if your PS is still crashing, then we suggest that you please report this in jira.percona.com
Audit Log Filter compression and encryption - Percona Server for MySQL.
The audit log filter plugin generates the initial password, but you can use user-defined passwords after that. The plugin stores the passwords in the keyring, so that feature must be enabled.
Okay, that’s the whole problem. 
This behavior is strange even if expected and will prevent me from upgrading from PS 8.0 (which currently works very well with the audit_log plugin) to PS 8.4 due to my tests of restoring encrypted data.
Beyond that, the logic of this functionality seems strange to me. I install the audit component to have audit logs and I install the keyring component to manage different encryption-related functionalities. There is a priori no link between the two, unless I explicitly state it. In this case, if we want to follow this logic, PS should also automatically create the innodb encryption keys, binlogs etc… as soon as we deploy the keyring component.
It would have been interesting to continue maintaining the old plugins while we had the new stable components.
The audit_log_filter component is very annoying and even unusable because of this problem and that of the format of the events returned which I have already reported here: [PS 8.4.4] Audit component doesn't work as expected