Upgrade notices

Some Anjuna Kubernetes Toolset for AWS EKS versions need more than the standard upgrade procedure. Read the notices below that apply to the version you are upgrading from, and follow them before you run helm upgrade.

Upgrading from Anjuna Kubernetes Toolset for AWS EKS 1.58 or earlier

These versions ran the Launcher as root, exposed only the launcherPodSecurityContext Helm chart value for the Launcher security context, and needed no certificate for the Anjuna Metrics Server.

Issue a certificate for the Anjuna Metrics Server

This step applies if the Anjuna Metrics Server is enabled, which is the default (metricsServer.enabled).

The TLS certificates for the Anjuna Nitro Webhook and the Anjuna Metrics Server are stored in the cluster as Kubernetes secrets. They are not part of the Helm release, so an upgrade normally does not touch them. This notice is the exception: the version you are upgrading to needs a certificate for the Anjuna Metrics Server, signed by the same CA as the Webhook’s certificate.

Because that CA’s private key is not kept, adopting it means regenerating both certificates. Follow the TLS certificates instructions and record the new caBundle in your values.yaml file. Replace both certificate Secrets and proceed with the upgrade.

While the Secrets and the caBundle field do not match, the API server cannot reach the Webhook, and creating a Confidential Pod fails. Anjuna recommends replacing the Secrets right before running the Helm upgrade command to minimize downtime.

Update the security context settings in your values.yaml file

Newer versions harden the Launcher container through Helm chart values that did not exist before. The Anjuna Kubernetes Toolset for AWS EKS applies no security context of its own when those values are absent, so a values.yaml file carried over from an earlier version leaves the Launcher container without any of the hardening. Add the recommended values to your file to adopt it:

nitroDeviceGID: 75
launcherContainerSecurityContext:
    allowPrivilegeEscalation: true
    capabilities:
        drop: ["ALL"]
        add: ["CHOWN", "MKNOD", "FOWNER", "DAC_OVERRIDE"]
    seccompProfile:
        type: Unconfined
launcherContainerSecurityContextDefaults:
    runAsNonRoot: true
    readOnlyRootFilesystem: true

nitroDeviceGID: Carries the group ID (gid) that allows access to /dev/nitro_enclaves and /dev/vsock. The Webhook adds it to the .spec.securityContext.supplementalGroups field of the Launcher Pod. Must match the gid used during enclave Node setup. Defaults to 75.
launcherContainerSecurityContext: Specifies the fields enforced on all Anjuna Launcher containers in the cluster. The recommended set of values carries the settings that allow the Launcher container to function properly as a non-root user. The values set here override the .spec.containers[].securityContext field of the original Pod specification (i.e. pre-mutation) of Confidential Pods.
launcherContainerSecurityContextDefaults: Specifies the default fields for all Anjuna Launcher containers in the cluster. The recommended set of values carries optional hardening that is not required by the Launcher, and can therefore be overridden by the .spec.containers[].securityContext field of the original Pod specification (i.e. pre-mutation) of Confidential Pods.

If you defined launcherPodSecurityContext in your values.yaml file, port its values to the fields above and remove it. It still applies otherwise, and it applies to the entire Launcher Pod rather than to the Launcher container, so anything left in it is enforced and a Confidential Pod cannot set those fields for itself. A Seccomp profile left in it has no effect at all once launcherContainerSecurityContext sets one, because Kubernetes gives the container profile precedence over the Pod one.

Refer to Configuring and deploying the Anjuna Kubernetes Toolset for AWS EKS for the complete configuration and examples.

Review the Confidential Pods that set a security context

Newer versions stop removing the security context from the Pod specification. A Confidential Pod that sets .spec.securityContext or .spec.containers[].securityContext now carries those fields through to the Launcher, except where the Anjuna Kubernetes Toolset for AWS EKS enforces a different value. Review the Confidential Pods that set either field before you upgrade.

Check the ownership of data on persistent volumes

The Anjuna Nitro Launcher runs as a non-root user after the upgrade, so take particular care with Confidential Pods that use persistent volumes: the files already on the volume were written as root. The Launcher still reaches them through the privilege escalation it is granted by default.

If you disable privilege escalation, as described in When the Launcher needs privilege escalation, adjust the ownership of the existing files first. Set fsGroup in the Pod specification so that the kubelet re-owns the volume when it attaches it, or change the file permissions on the volume directly. Refer to File ownership on AnjunaFS mounts for more information.