Add or update a CA certificate for a MITM proxy using API

When you enable a man-in-the-middle (MITM) proxy access to a MOSK cluster, your proxy requires a trusted CA certificate. This section describes how to manually add the caCertificate field to the spec section of the Proxy object. You can also use this instruction to update an expired certificate on an existing cluster.

You can also add a CA certificate for a MITM proxy using the MOSK management console through the Proxies tab. For details, refer to the cluster creation procedure described in Create a MOSK cluster.

Warning

Any modification to the Proxy object, for example, changing the proxy URL, NO_PROXY values, or certificate, leads to cordon-drain and Docker restart on the cluster machines.

To add or update a CA certificate for a MITM proxy using API:

Encode your proxy CA certificate. For example:
```
cat ~/.mitmproxy/mitmproxy-ca-cert.cer | base64 -w0
```
Replace ~/.mitmproxy/mitmproxy-ca-cert.cer with the path to your CA certificate file.
Open the existing Proxy object for editing:

Warning

The kubectl apply command automatically saves the applied data as plain text into the kubectl.kubernetes.io/last-applied-configuration annotation of the corresponding object. This may result in revealing sensitive data in this annotation when creating or modifying the object.

Therefore, do not use kubectl apply on this object. Use kubectl create, kubectl patch, or kubectl edit instead.

If you used kubectl apply on this object, you can remove the kubectl.kubernetes.io/last-applied-configuration annotation from the object using kubectl edit.
```
kubectl --kubeconfig <pathToManagementClusterKubeconfig> -n <projectName> edit proxy <proxyName>
```
In the system response, find the spec section with the current proxy configuration. For example:
```
spec:
  httpProxy: http://172.19.123.57:8080
  httpsProxy: http://172.19.123.57:8080
```

In the spec section, add or update the spec.caCertificate field with the base64-encoded proxy CA certificate data. For example:

spec:
  caCertificate: <BASE64_ENCODED_CA_CERTIFICATE>
  httpProxy: http://172.19.123.57:8080
  httpsProxy: http://172.19.123.57:8080

Save the Proxy object and proceed with the MOSK cluster creation.

If you update an expired certificate on an existing MOSK cluster, wait until the machines switch from the Reconfigure to Ready state to apply changes.
Strongly recommended. Back up MKE as described in Mirantis Kubernetes Engine documentation: Back up MKE.

Since the procedure above modifies the cluster configuration, a fresh backup is required to restore the cluster in case further reconfigurations fail.
Important

Because the MKE restoration process is complicated, we strongly recommend contacting Mirantis support for assistance.

If you still decide to restore MKE from a backup on your own, you must scale down helm-controller on the cluster being restored if the MKE version of the affected cluster after the restore will differ from the MKE version in the ClusterRelease object that is set in MOSK Cluster objects in the management cluster:
- If you are restoring MKE on a management cluster: before starting the restore, scale down helm-controller on each affected MOSK cluster. This prevents unintended Ceph and OpenStack downgrades on MOSK clusters after the management cluster is restored.
- If you are restoring MKE on a MOSK cluster: immediately after the restore completes, scale down helm-controller. Because the restore rolls the cluster back to an older release, this prevents it from triggering a premature upgrade of Helm releases.