[MDEV-26851] Provide means to verify Galera using TLS from SQL level Created: 2021-10-18  Updated: 2024-01-17

Status: Stalled
Project: MariaDB Server
Component/s: Galera
Fix Version/s: 11.5

Type: New Feature Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Alexey
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It is possible to configure Galera to use SSL/TLS for communication between nodes, but especially with MariaDB 10.6, a node can be configured to support TLS, but still accept non-encrypted connections. This was added so that a cluster can be converted from non-encrypted to encrypted in a rolling restart

It would be good to have a way to confirm that all intra-node connections are indeed using encryption using SQL statements, so that compliance can be confirmed without having to capture and inspect actual network traffic.

As this would not be a single set of values for "encryption used at all?", tls version, certificate and cipher used, etc. but one tuple per node pair, this would probably not work out well using status variables, so exposing this information would rather require adding an INFORMATION_SCHEMA or PERFORMANCE_SCHEMA table ...



 Comments   
Comment by Jan Lindström (Inactive) [ 2021-11-11 ]

Firstly, the connections are allowed to fall back to tcp only if socket.dynamic=1. Whether the connection is using SSL is to look up connection established messages from log, like

2021-11-11T07:56:39.086454Z 0 [Note] [MY-000000] [WSREP] P: (e499200b-b0d0, 'tcp://0.0.0.0:13062') connection established to e68fc5e6-8866 tcp://127.0.0.1:13067

the peer address scheme in

tcp://127.0.0.1:13067

is either 'tcp' or 'ssl'.

I do not see real need for some INFORMATION_SCHEMA table or similar that you could query by SQL because current information can be easily found from log.

Comment by Hartmut Holzgraefe [ 2022-04-01 ]

Not everyone interested in this information may have access to the log. That's why I was asking for a SQL level solution: to be able to audit this by using an SQL client only ...

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