No enforcement of Encryption in Transit, i.e. MicroCeph cluster allows plain text communication with clients

microceph 19.2.3+snapfd93b718e2 1701 squid/edge canonical✓ held

As you can see at:
https://bugs.launchpad.net/snap-openstack/+bug/2159005

MicroCeph side doesn't enforce secure connection to MicroCeph to encrypt data in transit. When clients connect to MicroCeph without careful consideration, the data written to Ceph RBD for example can be captured on the networking layer. MicroCeph should have a way to enforce modern and secure protocol. If the secure mode should be the default by eliminating legacy client or not requires some discussions maybe, but at least the secure enforcement mode should be there by tightening up the configs in the following page, in my opinion.
https://docs.ceph.com/en/squid/rados/configuration/msgr2/

In the meantime, the MicroCeph documentation give a false impression that encryption is used by default (it's enabled and available by default but that doesn't necessarily mean it's used always).

https://documentation.ubuntu.com/canonical-microceph/latest/snap/explanation/security/attack-surface/#network-protocols-and-endpoints
> Ceph Messenger protocol (v1/v2): Used for all internal Ceph communication (MON, OSD, MGR, MDS). Messenger v2 (default in newer Ceph versions) provides encryption capabilities for data in transit.

https://documentation.ubuntu.com/canonical-microceph/latest/snap/explanation/canonical-ceph-reference-architecture/data-encryption/
> Encryption in transit and at rest is enabled by default once Canonical Ceph is related to a Vault secrets-storage relation. Data encryption in transit is enabled via the Messenger V2 feature.

### How to reproduce and confirm the traffic in transit.

1. deploy a single node Sunbeam with control,compute,storage roles.
2. launch a VM
$ sunbeam launch ubuntu --name test
3. create and attach a volume backed by Ceph RBD, e.g.
$ openstack volume create --size 5 test-volume-1
$ openstack server add volume test test-volume-1
4. create a filesystem on top and mount it from the guest OS
$ sudo mkfs.ext4 /dev/vdb
$ sudo mount /dev/vdb /mnt
5. write some secret to the filesystem while capturing the network packets from/to Ceph OSDs on the host
$ printf 'MY_SECRET at %s\n' "$(date -Is)" | sudo tee /mnt/data.txt

```bash
$ sudo tcpdump -elnvA -i any tcp portrange 6800-7568
```
> 06:02:03.487182 lo In ifindex 1 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 4512: (tos 0x0, ttl 64, id 4824, offset 0, flags [DF], proto TCP (6), length 4492)
192.168.124.21.44348 > 192.168.124.21.6804: Flags [P.], cksum 0x8afa (incorrect -> 0xfbeb), seq 406:4846, ack 258, win 48025, options [nop,nop,TS val 2229140578 ecr 2229139105], length 4440
E.....@.@.....|...|..<....%/.8.9...........
...b......)........................._.%AA...............*.?. ....................e..................t.........=.l{...$.@...............................................................[PGju>....................................&...rbd_data.426631b4e736.0000000000000021...".....0.............................................................?MY_SECRET at 2026-07-03T06:02:03+00:00

^^^ MY_SECRET is visible in the network packet.

### Host configuration out of the box

```bash
$ sudo ceph mon dump
epoch 2
fsid 1541217c-0e77-4a6a-84fa-7d770c83f7f7
last_changed 2026-07-03T03:54:50.965430+0000
created 2026-07-03T03:54:47.204285+0000
min_mon_release 19 (squid)
election_strategy: 1
0: [v2:192.168.124.21:3300/0,v1:192.168.124.21:6789/0] mon.sunbeam-single-node
dumped monmap epoch 2

^^^ both msgr1 and msgr2 are enabled

$ sudo ss -tlnp | grep ceph-mon
LISTEN 0 512 192.168.124.21:6789 0.0.0.0:* users:(("ceph-mon",pid=52711,fd=28))
LISTEN 0 512 192.168.124.21:3300 0.0.0.0:* users:(("ceph-mon",pid=52711,fd=27))

^^^ both ports listens

$ sudo cat /var/snap/cinder-volume/common/etc/ceph/cinder-volume-ceph.conf
###############################################################################
# [ WARNING ]
# ceph configuration file maintained by the cinder-volume snap
# local changes may be overwritten.
###############################################################################
[global]
auth_supported = cephx
mon host = 192.168.124.21
log to syslog = true
err to syslog = true
clog to syslog = true

[client]
keyring = /var/snap/cinder-volume/common/etc/ceph/ceph.client.cinder-volume-ceph.keyring
```
^^^ no specification about msgr1 or msgr2

Start with the MicroCeph security documentation pages and the Ceph Messenger v1/v2 configuration reference linked in the issue, then reproduce the behavior with the listed Sunbeam, Ceph, tcpdump, and client-volume commands. Compare the configured monitor ports and client configuration with the intended secure-enforcement behavior. Done means plaintext client traffic is prevented or an explicit secure mode is available, and the documentation no longer implies encryption is always used.

Written by the indexing model from the issue text.