Upgrading the Anjuna Kubernetes Toolset for AWS EKS

Upgrading the Anjuna Kubernetes Toolset for AWS EKS will not affect running Confidential Pods, and new Confidential Pods can still be created during an upgrade.

Upgrades without downtime are only supported for Anjuna Kubernetes Toolset for AWS EKS versions 1.51 and later.
Upgrades as described on this page are only supported if the Toolset was deployed using Helm and following the instructions in Deploying to an existing cluster. For alternative installation methods, contact support@anjuna.io.
The Anjuna Kubernetes Toolset for AWS EKS is a global cluster component. Once the upgrade is done, all new Confidential Pods will use the upgraded version of the Toolset, across all namespaces. The upgrade will not affect EIFs and the version of the Seaglass Runtime inside the enclave.

Namespace

Set the namespace where the Toolset is installed. The instructions below assume the default Anjuna namespace, anjuna-system. Change accordingly to match your own cluster:

$ export NAMESPACE="anjuna-system"

When upgrading, you have to use the same namespace for the upgraded Toolset that you used for the previous version. You can use the already created TLS certificate for the Anjuna Webhook, and the K8s secret that was already created to hold that certificate.

Upgrade the Anjuna Nitro Kubernetes Toolset

To upgrade the Anjuna Kubernetes Toolset for AWS EKS, first download the desired version of the Anjuna Kubernetes Toolset for AWS EKS tarfile from the Anjuna Resource Center. Follow the instructions in Downloading the Anjuna Kubernetes Toolset for AWS EKS.

Change your directory to the directory containing the extracted Anjuna Kubernetes Toolset for AWS EKS of the newer version.

Follow the instructions in the Creating the Anjuna Docker images section.

If you want to reuse the TLS certificates for the Anjuna Nitro Webhook, go to the anjuna-tools directory of your previous version of the Anjuna Kubernetes Toolset for AWS EKS deployment. Then find the webhook-tls directory containing the Anjuna certificate and key, and copy it to the anjuna-tools directory of the new version of the Anjuna Kubernetes Toolset for AWS EKS deployment:

$ cp -r \
      [old deployment dir]/anjuna-tools/webhook-tls \
      webhook-tls

Create an environment variable to store a base64-encoded version of the CA certificate:

$ export CA_BUNDLE=$(cat webhook-tls/caBundle.txt)

Follow the Configure the Anjuna Nitro Kubernetes Toolset instructions in the Configuring the Anjuna Kubernetes Toolset for AWS EKS section.

Upgrade the Anjuna Kubernetes Toolset for AWS EKS using Helm:

$ helm upgrade \
    --atomic \
    -f helm-charts/anjuna-tools/values.yaml \
    --namespace "${NAMESPACE}" \
    anjuna-tools \
    helm-charts/anjuna-tools
The --atomic flag will automatically roll back the Anjuna Kubernetes Toolset for AWS EKS version in case of an error.

Verify that the upgrade was successful by inspecting the version of the Toolset reported by Helm:

$ helm list --namespace "${NAMESPACE}"

Also verify that the Toolset Pods were restarted in the toolset namespace, by inspecting their reported AGE:

$ kubectl get pods --namespace "${NAMESPACE}"

Inspecting the version of the Toolset and Confidential Pods

Refer to Querying Toolset and Confidential Pod versions to identify the Toolset version globally installed to your cluster, as well as the Toolset version and the EIF version used by a currently running Confidential Pod.

Rebuilding the EIFs with the new runtime version

After upgrading, the Confidential Pods running in this cluster are still running with an earlier version of the Anjuna Seaglass Runtime than the version used for running the Toolset.

You can consider rebuilding the EIFs with the new Runtime version to gain some of the following benefits of the newer version:

  1. New abilities.

  2. Fixes for bugs.

  3. Fixes for security vulnerabilities.

You can review the Anjuna Release Notes page to see the improvements in newer versions.

If you decide to rebuild the EIF of a Confidential Pod with a newer version of the Runtime, you should be aware of the following potential side effects:

  • If your KMS policy is based on the hash of the enclave’s software measurements (PCR0, PCR1, or PCR2), you should update the KMS policy before launching the Confidential Pod with the new EIF.

    • The software measurement will change due to the change in the Anjuna Runtime code, even if your container image did not change.

    • If you plan to run EIFs in parallel with the new one, while using the same KMS secret, extend the older PCR0-2 values in the KMS policy with the new values.

  • If your KMS policy is based on the hash of the EIF’s signing certificate (PCR8), be aware of the following:

    • If you use the same certificate, you do not need to change the KMS policy.

    • If you use a different signing certificate, update the KMS policy with the new PCR8 value before launching the Confidential Pod with the new EIF.

    • If you plan to run EIFs in parallel with the new one, while using the same KMS secret, extend the older PCR8 values in the KMS policy with the new PCR8 value.

  • When you stop using a version of an EIF in a Confidential Pod, remember to remove its PCR values from any KMS policy that uses these values.