Cryptography

This explanation page provides an overview of the Canonical Kubernetes cryptography posture. From a high-level, Canonical Kubernetes uses industry-standard cryptographic algorithms to ensure authentication between components, secure data transfer, and data encryption at rest.

TLS certificates

All communications between core components, such as the API server and kubelets, are encrypted with TLS 1.3 (Transport Layer Security), providing robust protection for sensitive data in transit. By default, Canonical Kubernetes uses self-signed certificates, but users are able to use an intermediate CA or provide their own certificates instead.

Dqlite encryption at rest

Canonical Kubernetes uses AES-256-GCM (Advanced Encryption Standard - Galois/Counter Mode) to encrypt cluster data at rest.

Digital signatures

To securely authenticate API clients, Canonical Kubernetes uses X.509 certificates with support for both RSA-2048 and ECDSA (Elliptic Curve Digital Signature Algorithm). This ensures strong, standards-based authentication with options suited for both general-purpose and resource-constrained environments.

Configure cryptography in Canonical Kubernetes

Canonical Kubernetes provides various cryptographic tools that users can leverage to implement security controls for their workloads:

  • Kubernetes Secrets Encryption: Users are empowered to configure encryption providers for Secrets at rest, with AES-GCM as the preferred encryption algorithm for data confidentiality.

  • Kubernetes API Authentication: For secure API access, users can configure X.509 certificates, allowing them to implement secure, certificate-based authentication with support for RSA 2048 and ECDSA keys.

  • Service Mesh Encryption (Optional): When deploying service meshes like Istio with Canonical Kubernetes, users can enable mutual TLS (mTLS) to protect inter-service communications, ensuring data privacy and authenticity in multi-service environments.

    • Supported Algorithms for mTLS:

      • RSA-2048 or ECDSA: These options enable secure certificate-based authentication between services.

      • AES-GCM: Used for encrypted service-to-service communication.

Third party cryptographic packages and libraries

Canonical Kubernetes depends on a suite of cryptographic libraries and packages to implement its security functions:

  • OpenSSL: Canonical Kubernetes utilizes OpenSSL for a broad range of cryptographic operations, including TLS, certificate management, and secure key exchange. OpenSSL’s extensive cryptographic functionality and secure algorithms provide a reliable foundation for TLS and encryption operations.

    Source: Ubuntu Archive (Package: openssl)

  • Linux Kernel Cryptographic Modules: For network security and cryptographic operations at the kernel level, Canonical Kubernetes leverages cryptographic modules in the Linux kernel, such as IPsec for secure network communications.

    Source: Ubuntu Kernel (Package: linux-generic)

  • Go Cryptography Library: Since Kubernetes is written in Go, Canonical Kubernetes relies on the Go standard library’s cryptographic functions, implementing secure algorithms such as RSA, ECDSA, and AES, which are necessary for the secure operation of Kubernetes components.

    Source: Go Standard Library (x509, rsa, sha256, tls)