Cryptography

This document describes cryptography used by Charmed MongoDB and Charmed Mongos. We discuss both charms since acknowledge that Charmed Mongos is a requirement for working clusters

Resource checksums

Charmed MongoDB and Charmed Mongos operators use a pinned revisions of the Charmed MongoDB snap. This provides reproducible and secure environments. The snap packages the workloads associated with both charms (percona-server-mongodb, mongodb-exporter, pbm, etc), see Charmed MongoDB snap contents.

Every artifact bundled into the Charmed MongoDB snap is verified against their MD5, SHA256 or SHA512 checksum after download. The installation of certified snaps into the rock is ensured by snap primitives that verify their squashfs filesystems images GPG signature. For more information on the snap verification process, refer to the snapcraft.io documentation.

Sources verification

Charmed MongoDB sources are stored in:

• GitHub repositories for snaps, rocks and charms
• LaunchPad repositories for the percona-server-mongodb, mongodb-exporter, and pbm upstream forks used for building their respective distributions

LaunchPad

Distributions are built using private repositories only, hosted as part of the SOSS namespace to eventually integrate with Canonical’s standard process for fixing CVEs. Branches associated with releases are mirrored to a public repository, hosted in the Data Platform namespace to also provide the community with the patched source code.

GitHub

All MongoDB artifacts built by Canonical are published and released programmatically using release pipelines implemented via GitHub Actions. Distributions are published as both GitHub and LaunchPad releases via the central-uploader repository, while charms, snaps and rocks are published using the workflows of their respective repositories.

All repositories in GitHub are set up with branch protection rules, requiring:

• new commits to be merged to main branches via pull request with at least 2 approvals from repository maintainers

Encryption

Charmed MongoDB can be used to deploy a secure database that provides encryption-in-transit capabilities out of the box for:

• mongod replica/shard communication
• mongos router communication
• External client connection

To set up a secure connections on Charmed MongoDB, the database must be integrated with TLS Certificate Provider charms, e.g. self-signed-certificates operator. CSRs are generated for every unit using tls_certificates_interface library that uses cryptography python library to create X.509 compatible certificates. The CSR is signed by the TLS Certificate Provider and returned to the units, and stored in a file with limited permisions and stored in Juju Secrets.

When encryption is enabled, hostname verification is turned on for existing connections, including clients, shards, replicas, and routers.

Encryption at rest is currently not supported, although it can be provided by the substrate (cloud or on-premises).

Authentication

In Charmed Apache MongoDB, authentication layers can be enabled for:

1. MongoDB replica/shard/router communication (i.e. Internal Membership)
2. Client authentication to MongoDB

Authentication from Charmed MongoDB to Charmed Mongos

MongoDB replica/shard/router communication (i.e. Internal Membership)

Internal Members authenticate using:

1. KeyFiles using SCRAM-SHA-256 protocols
2. x.509 certificates

Both KeyFiles and certificates are stored on files with minimal permissions. Note MongoDB disables support for TLS 1.0 encryption on systems where TLS 1.1+ is available.

These files needs to be readable and writable by root (as it is created by the charm), and be readable by the snap_daemon user running the Charmed MongoDB snap commands.

Client authentication to MongoDB

Clients can authenticate to MongoDB using:

1. username and password exchanged using SCRAM-SHA-256 protocols
2. client certificates or CAs (mTLS)

When using SCRAM, username and passwords are stored in Charmed MongoDB and Charmed Mongos to be used by the mongod and mongos processes, in peer-relation data and in external relation to be shared with client applications via Juju secrets.

When using mTLS, client certificates are loaded into a tls-certificates operator and provided to the Charmed MongoDB via the plain-text unencrypted relation. Certificates are stored in a file with minimal permissions. Note MongoDB disables support for TLS 1.0 encryption on systems where TLS 1.1+ is available.