AAKE update to 24.4.4hf1 fails with PodSecurity "restricted" violation.

Products

CA Automic Workload Automation - Automation Engine

Issue/Introduction

When updating Automic Automation Kubernetes Edition (AAKE) from version 24.4.2hf1 to 24.4.4hf1, the install-operator job fails. Specifically, the cust-aa-ready job is unable to create its pods.

Checking the job controller events or describing the failing pod reveals an error similar to the following:

Warning FailedCreate 5m59s job-controller Error creating: pods "cust-aa-24-4-4-0-ready-xxxxxxx-xxxxx" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "wait-for-jcp-ws" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "wait-for-jcp-ws" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "wait-for-jcp-ws" must set securityContext.runAsNonRoot=true)

Environment

Product: Automic Automation Kubernetes Edition (AAKE)
Version: 24.4.4hf1
Kubernetes Configuration: Namespace configured with Pod Security Admission enforcing the restricted profile.

Cause

Starting with AAKE 24.4.4hf1, the cust-aa-ready job introduces a new init container named wait-for-jcp-ws. In the current template, this container lacks the explicit securityContext declarations (such as allowPrivilegeEscalation: false, capabilities: drop: ["ALL"], and runAsNonRoot: true) required by the Kubernetes restricted Pod Security standard.

Consequently, the Kubernetes API server blocks the creation of the pod in namespaces where the restricted policy is enforced.

Defect ID: DE189085

Resolution

This issue is under investigation by Engineering for a permanent fix in a future release to include the necessary security context in the container template.

Automic Automation Engine 24.4.5 - TBA

Public Title:
A bug was fixed for AAKE install where the system wouldn't install on hardened k8s instances

Public Description:
A bug was fixed where the AAKE would fail to install in case either:
1. the cluster wouldn't have access to the public docker registry to download busybox
2. the cluster would be hardened and the security context wouldn't allow running containers as root.

Workaround

To allow the installation or update to proceed, temporarily relax the Pod Security enforcement for the affected namespace to the baseline profile. The baseline profile prevents known privilege escalations but does not require the strict explicit declarations that the restricted profile demands.

Apply the following label to your namespace:

This command will make changes to your system. Review it carefully before running.

After applying this change, the install-operator job should be able to successfully create the cust-aa-ready pods and complete the update.

Additional Information

For more details on Kubernetes Pod Security standards and namespace labeling, refer to the .

Related known issues for the wait-for-jcp-ws pod in AAKE 24.4.4hf1:

Additional Information

Article title: How to register to Broadcom Software Product updates and Critical Alerts

https://knowledge.broadcom.com/external/article?articleId=133819