Security

This document provides an overview of security features and guidance for hardening the security of Charmed Apache Kafka K8s deployments, including setting up and managing a secure environment.

Environment

The environment where Charmed Apache Kafka K8s operates can be divided into two components:

  1. Kubernetes

  2. Juju

Kubernetes

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

Kubernetes

Security guides

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. For more information on Juju security hardening, see the Juju security page and the How to harden your deployment guide.

Cloud credentials

When configuring cloud credentials to be used with Juju, ensure that 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 for bootstrapping and managing the deployments should have full permissions, such as:

  • create, delete, patch, and list:

    • namespaces

    • services

    • deployments

    • statefulsets

    • 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 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 levels and corresponding abilities.

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

Applications

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

  1. Base images

  2. Charmed operator security upgrades

  3. Encryption

  4. Authentication

  5. Monitoring and auditing

Base images

Charmed Apache Kafka K8s runs on a Rockcraft-based image built on Ubuntu 24.04 LTS. This image includes Apache Kafka distribution binaries built and maintained by Canonical, which are available on the Apache Kafka release page.

The image that can be found in the Charmed Apache Kafka rock GitHub container repository is used as the base images for pods providing Apache Kafka services.

Charmed operator security upgrades

Charmed Apache Kafka K8s operator installs a pinned revision of the image outlined in the previous section to provide a reproducible and secure environment. New versions of Charmed Apache Kafka K8s operator may therefore be released to provide patching of vulnerabilities (CVE). 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 refresh user guide.

Encryption

Charmed Apache Kafka K8s must be deployed with encryption enabled. To do that, you need to integrate Charmed Apache Kafka K8s with 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, see the Cryptography explanation page and How to enable encryption guide.

Authentication

Charmed Apache Kafka K8s supports the following authentication layers:

  1. SCRAM-based SASL Authentication

  2. certificate-based Authentication (mTLS)

  3. OAuth Authentication using Hydra or Google

Each combination of authentication scheme and encryption is associated with the dedicated listener and it maps to a well-defined port. See the listeners reference documentation for more information.

Monitoring and auditing

Charmed Apache Kafka 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 from one another. Refer to the COS production deployments best practices for more information.

For instructions, see the How to integrate the Charmed Apache Kafka K8s deployment with COS and How to customise the alerting rules and dashboards guides.

External user access to Apache Kafka is logged to the kafka-authorizer.log that is pushed to a Loki endpoint and exposed via Grafana, both components being part of the COS stack.

Access denials are logged at the INFO level, whereas allowed accesses are logged at the DEBUG level. Depending on the auditing needs, customise the logging level either for all logs via the log-level configuration option or only tune the logging level of the authorizerAppender in the log4j.properties file. See the file system paths for further information.

Additional resources

For details on the cryptography used by Charmed Apache Kafka K8s, see the Cryptography explanation page.