Charmed MongoDB + Mongos Hardening Guide - K8s

charm
1

Security Hardening Guide

This document provides guidance and instructions to achieve a secure deployment of Charmed MongoDB K8s and Charmed Mongos K8s. We discuss both charms since acknowledge that Charmed Mongos K8s is a requirement clustered deployments. Additionally, we include guidance and instructions for setting up and managing a secure environment. The document is divided into the following sections:

  1. Environment, outlining the recommendation for deploying a secure environment
  2. Applications, outlining the product features that enable a secure deployment of Charmed MongoDB
  3. Additional resources, providing any further information about security and compliance

Environment

The environment where applications operate can be divided in two components:

  1. Kubernetes
  2. Juju

Kubernetes

Charmed Apache Kafka can be deployed on top of several Kubernetes distributions. The following table provides references for the security documentation for the main supported cloud platforms.

Cloud Security guide
Charmed Kubernetes Security in Charmed Kubernetes
AWS EKS Best Practices for Security, Identity and Compliance, AWS security credentials, Security in EKS
Azure Azure security best practices and patterns, Managed identities for Azure resource, Security in AKS

Juju

Juju is the component responsible for orchestrating the entire lifecycle, from deployment to Day 2 operations, of all applications. Therefore, it is imperative that it is set up securely. Please refer to the Juju documentation for more information on:

Cloud credentials

When configuring the cloud credentials to be used with Juju, ensure that the users have the correct permissions to operate at the required level on the Kubernetes cluster. Juju superusers responsible for bootstrapping and managing controllers require elevated permissions to manage several kinds of resources. For this reason, the K8s user used for bootstrapping and managing the deployments should have full permissions, such as:

  • create, delete, patch, and list:
    • namespaces
    • services
    • deployments
    • stateful sets
    • pods
    • PVCs

In general, it is common practice to run Juju using the admin role of K8s, to have full permissions on the Kubernetes cluster.

Juju users

It is very important that the different Juju users are set up with minimal permissions depending on the scope of their operations. Please refer to the User access levels documentation for more information on the access level and corresponding abilities that the different users can be granted.

Juju user credentials must be stored securely and rotated regularly to limit the chances of unauthorized access due to credentials leakage.

Applications

In the following, we provide guidance on how to harden your deployment using:

  1. Base images
  2. Security upgrades
  3. Encryption
  4. Authentication
  5. Monitoring and auditing

Base images

Charmed MongoDB K8s and Charmed Mongos K8s run on top of rockcraft-based image shipping the percona-server, mongodb-exporter, and pbm distribution binaries built by Canonical with its images are based on Ubuntu 22.04. The images that can be found in the Charmed MongoDB rock Github repository are used as the base images for the different pods providing MongoDB services. The following table summarise the relation between the component and its underlying base image.

A new version of the Charmed MongoDB image may be released to provide patching of vulnerabilities (CVEs).

Security upgrades

Charmed MongoDB K8s and Charmed Mongos K8s install a pinned revisions of the Charmed MongoDB snap, to provide reproducible and secure environments. New versions of Charmed MongoDB K8s and Charmed Mongos K8s may be released to provide patching of vulnerabilities (CVEs). It is important to refresh the charm regularly to make sure the workload is as secure as possible. For more information on how to refresh the charm, see the how-to upgrade guide.

Encryption

In both Charmed MongoDB K8s and Charmed Mongos K8s, encryption is not a requirement to use the database or router, but is a requirement of a hardened system. To do that, you need to relate Charmed MongoDB K8s and Charmed Mongos K8s to one of the TLS certificate operator charms. Please refer to the Charming Security page for more information on how to select the right certificate provider for your use case.

For more information on encryption setup, see the How to enable encryption guide.

Authentication

Charmed MongoDB K8s supports the following authentication layers:

  1. MongoDB replica/shard/router communication (i.e. Internal Membership)
    1. KeyFile or TLS
  2. SASL authentication to MongoDB (SCRAM-based)

Monitoring and Auditing

Charmed MongoDB K8s provides native integration with the Canonical Observability Stack (COS). To reduce the blast radius of infrastructure disruptions, the general recommendation is to deploy COS and the observed application into separate environments, isolated one another. Refer to the COS production deployments best practices for more information.

Refer to How-To user guide for more information on:

Additional Resources

For further information and details on the security and cryptographic specifications used by Charmed MongoDB K8s, please refer to the Security Explanation page.