Skip to content
Kong Logo | Kong Docs Logo
search
  • We're Hiring!
  • Docs
    • Kong Gateway
    • Kong Konnect
    • Kong Mesh
    • Plugin Hub
    • decK
    • Kubernetes Ingress Controller
    • Insomnia
    • Kuma

    • Docs contribution guidelines
  • Plugin Hub
  • Support
  • Community
  • Kong Academy
Get a Demo Start Free Trial
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Plugin Hub
  • decK
  • Kubernetes Ingress Controller
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 2.1.x (latest)
  • 2.0.x
  • 1.9.x
  • 1.8.x
  • 1.7.x
  • 1.6.x
  • 1.5.x
  • 1.4.x
  • 1.3.x
  • 1.2.x
  • 1.1.x
  • 1.0.x
    • Introduction to Kong Mesh
    • What is Service Mesh?
    • How Kong Mesh works
    • Deployments
    • Version support policy
    • Stability
    • Release notes
    • Installation Options
    • Kubernetes
    • Helm
    • OpenShift
    • Docker
    • Amazon ECS
    • Amazon Linux
    • Red Hat
    • CentOS
    • Debian
    • Ubuntu
    • macOS
    • Windows
    • Explore Kong Mesh with the Kubernetes demo app
    • Explore Kong Mesh with the Universal demo app
    • Standalone deployment
    • Deploy a standalone control plane
    • Multi-zone deployment
    • Deploy a multi-zone global control plane
    • License
    • Overview
    • Data plane proxy
    • Data plane on Kubernetes
    • Data plane on Universal
    • Gateway
    • Zone Ingress
    • Zone Egress
    • CLI
    • GUI
    • Observability
    • Inspect API
    • Kubernetes Gateway API
    • Networking
    • Service Discovery
    • DNS
    • Kong Mesh CNI
    • Transparent Proxying
    • IPv6 support
    • Non-mesh traffic
    • Secure access across Kong Mesh components
    • Secrets
    • Kong Mesh API Access Control
    • API server authentication
    • Data plane proxy authentication
    • Zone proxy authentication
    • Data plane proxy membership
    • Dataplane Health
    • Fine-tuning
    • Control Plane Configuration
    • Upgrades
    • Requirements
    • Introduction
    • General notes about Kong Mesh policies
    • Applying Policies
    • How Kong Mesh chooses the right policy to apply
    • Understanding TargetRef policies
    • Protocol support in Kong Mesh
    • Mesh
    • Mutual TLS
    • Traffic Permissions
    • Traffic Route
    • Traffic Metrics
    • Traffic Trace
    • Traffic Log
    • Locality-aware Load Balancing
    • Fault Injection
    • Health Check
    • Circuit Breaker
    • Proxy Template
    • External Service
    • Retry
    • Timeout
    • Rate Limit
    • Virtual Outbound
    • MeshGateway
    • MeshGatewayRoute
    • Service Health Probes
    • MeshAccessLog (Beta)
    • MeshCircuitBreaker (Beta)
    • MeshFaultInjection (Beta)
    • MeshHealthCheck (Beta)
    • MeshHTTPRoute (Beta)
    • MeshProxyPatch (Beta)
    • MeshRateLimit (Beta)
    • MeshRetry (Beta)
    • MeshTimeout (Beta)
    • MeshTrace (Beta)
    • MeshTrafficPermission (Beta)
    • Overview
    • HashiCorp Vault CA
    • Amazon ACM Private CA
    • cert-manager Private CA
    • OPA policy support
    • MeshOPA (beta)
    • Multi-zone authentication
    • FIPS support
    • Certificate Authority rotation
    • Role-Based Access Control
    • UBI Images
    • Windows Support
    • Auditing
    • HTTP API
    • Annotations and labels in Kubernetes mode
    • Kong Mesh data collection
      • Mesh
      • CircuitBreaker
      • ExternalService
      • FaultInjection
      • HealthCheck
      • MeshGateway
      • MeshGatewayRoute
      • ProxyTemplate
      • RateLimit
      • Retry
      • Timeout
      • TrafficLog
      • TrafficPermission
      • TrafficRoute
      • TrafficTrace
      • VirtualOutbound
      • Dataplane
      • ZoneEgress
      • ZoneIngress
      • kuma-cp
      • kuma-dp
      • kumactl
    • Kuma-cp configuration reference
    • Open source License
    • Contribute to Mesh

github-edit-pageEdit this page

report-issueReport an issue

enterprise-switcher-iconSwitch to OSS

On this page
  • Overview
  • Usage
Kong Mesh
2.1.x (latest)
  • Home
  • Kong Mesh
  • Features
  • Certificate Authority rotation

Certificate Authority rotation

Overview

Kong Mesh lets you provide secure communication between applications with mTLS. You can change the mTLS backend with Certificate Authority rotation, to support a scenario such as migrating from the builtin CA to a Vault CA.

You can define many backends in the mtls section of the Mesh configuration. The data plane proxy is configured to support certificates signed by the CA of each defined backend. However, the proxy uses only one certificate, specified by the enabledBackend tag. For example:

Kubernetes
Universal
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  mtls:
    enabledBackend: ca-1
    backends:
    - name: ca-1
      type: builtin
    - name: ca-2
      type: provided
      conf:
        cert:
          secret: ca-2-cert
        key:
          secret: ca-2-key
type: Mesh
name: default
mtls:
  enabledBackend: ca-1
  backends:
  - name: ca-1
    type: builtin
  - name: ca-2
    type: provided
    conf:
      cert:
        secret: ca-2-cert
      key:
        secret: ca-2-key

Usage

Start with mTLS enabled and a builtin backend named ca-1:

Kubernetes
Universal
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  mtls:
    enabledBackend: ca-1
    backends:
      - name: ca-1
        type: builtin
type: Mesh
name: default
mtls:
  enabledBackend: ca-1
  backends:
  - name: ca-1
    type: builtin

Then, follow the steps to rotate certificates to a new provided backend named ca-2. Each step can take some time, but Kong Mesh provides validators to prevent you from continuing too soon.

Kubernetes
Universal
  1. Add a new backend to the list of backends:

    apiVersion: kuma.io/v1alpha1
    kind: Mesh
    metadata:
      name: default
    spec:
      mtls:
        enabledBackend: ca-1
        backends:
        - name: ca-1
          type: builtin
        - name: ca-2
          type: provided
          conf:
            cert:
              secret: ca-2-cert
            key:
              secret: ca-2-key
    

    After the configuration finishes, all data plane proxies support CAs from ca-1 and ca-2. But the data plane proxy certificates are still signed by the CA from ca-1.

  2. Change enabledBackend to the new backend:

    apiVersion: kuma.io/v1alpha1
    kind: Mesh
    metadata:
      name: default
    spec:
      mtls:
        enabledBackend: ca-2
        backends:
        - name: ca-1
          type: builtin
        - name: ca-2
          type: provided
          conf:
            cert:
              secret: ca-2-cert
            key:
              secret: ca-2-key
    

    After the configuration finishes, the data plane proxy certificates are signed by the CA from ca-2. The data plane proxies still support CAs from ca-1 and ca-2.

  3. Remove the old backend:

    apiVersion: kuma.io/v1alpha1
    kind: Mesh
    metadata:
      name: default
    spec:
      mtls:
        enabledBackend: ca-2
        backends:
        - name: ca-2
          type: provided
          conf:
            cert:
              secret: ca-2-cert
            key:
              secret: ca-2-key
    

    After the configuration finishes, the data plane proxy certificates should still be signed by the CA from ca-2. But the data plane proxies no longer support the CA from ca-1.

  1. Add a new backend to the list of backends:

    type: Mesh
    name: default
    mtls:
      enabledBackend: ca-1
      backends:
      - name: ca-1
        type: builtin
      - name: ca-2
        type: provided
        conf:
          cert:
            secret: ca-2-cert
          key:
            secret: ca-2-key
    

    After the configuration finishes, all data plane proxies support CAs from ca-1 and ca-2. But the data plane proxy certificates are still signed by the CA from ca-1.

  2. Change enabledBackend to the new backend:

    type: Mesh
    name: default
    mtls:
      enabledBackend: ca-2
      backends:
      - name: ca-1
        type: builtin
      - name: ca-2
        type: provided
        conf:
          cert:
            secret: ca-2-cert
          key:
            secret: ca-2-key
    

    After the configuration finishes, the data plane proxy certificates are signed by the CA from ca-2. The data plane proxies still support CAs from ca-1 and ca-2.

  3. Remove the old backend:

    type: Mesh
    name: default
    mtls:
      enabledBackend: ca-2
      backends:
      - name: ca-2
        type: provided
        conf:
          cert:
            secret: ca-2-cert
          key:
            secret: ca-2-key
    

    After the configuration finishes, the data plane proxy certificates should still be signed by the CA from ca-2. But the data plane proxies no longer support the CA from ca-1.

Thank you for your feedback.
Was this page useful?
  • Kong
    THE CLOUD CONNECTIVITY COMPANY

    Kong powers reliable digital connections across APIs, hybrid and multi-cloud environments.

    • Company
    • Customers
    • Events
    • Investors
    • Careers Hiring!
    • Partners
    • Press
    • Contact
  • Products
    • Kong Konnect
    • Kong Gateway
    • Kong Mesh
    • Get Started
    • Pricing
  • Resources
    • eBooks
    • Webinars
    • Briefs
    • Blog
    • API Gateway
    • Microservices
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Solutions
    • Decentralize
    • Secure & Govern
    • Create a Dev Platform
    • API Gateway
    • Kubernetes
    • Service Mesh
Star
  • Terms•Privacy
© Kong Inc. 2023