The goal is to provide a supported and declarative method to add custom CA certificates to the Apicast pods (both staging and production) via the APIManager Custom Resource (CR). This will enable Apicast to securely connect to backend services that use certificates signed by a custom Certificate Authority (CA).

Problem Statement

Currently, Apicast pods do not have a built-in mechanism to trust custom CAs. This is a significant limitation for users who need to integrate 3scale with backend services that are not using certificates from a public, well-known CA. The current workaround involves manual intervention, which is not sustainable, scalable, or operator-friendly. Specifically, the workaround requires:

• Manually creating a ConfigMap containing the custom CA bundle.

• Manually patching the Apicast deployment to mount this ConfigMap at /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. This manual process is error-prone, doesn't persist across upgrades or pod restarts, and bypasses the declarative nature of the operator.

Proposed Solution

A new field should be added to the APIManager CR to allow users to specify a ConfigMap containing their custom CA bundle.

Example of Proposed APIManager CR:

apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  customCA:
    configMapRef:
      name: my-custom-ca-bundle

How it would work:

1. The user would create a ConfigMap containing the custom CA certificate(s) in a file named tls-ca-bundle.pem.

1. The user would then update their APIManager CR to reference this ConfigMap.

1. The 3scale operator would detect this change and automatically:

• • Update the Apicast staging deployment to mount the specified ConfigMap to the correct location (/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem).

• • Update the Apicast production deployment to mount the same ConfigMap.

• • Ensure the pods are restarted to apply the new trust bundle.

Benefits

• Declarative and Automated: The process becomes part of the declarative configuration, managed by the operator.

• Sustainable: Changes persist across upgrades and pod recreation.

• Security: This provides a standardized and secure way to handle internal or private CAs.

• Usability: Simplifies the configuration for users, removing the need for manual workarounds and kubectl patch commands.

Summary:

Implementing this feature would align the 3scale operator with best practices for managing trust stores in a Kubernetes environment. It's a crucial enhancement for enterprise users who rely on custom CAs for their internal services, making the product more robust and production-ready.