SYS.1.6.A14

[sluetze]

No description provided.

[sluetze]

When creating the concept for patch and change management in accordance with OPS.1.1.3 Patch and change management, it SHOULD be decided when and how the updates to the images or the software or service operated will be rolled out.

This requirement must be solved organizationally.

Note: Best practices use multiple environments (either separate clusters or multiple namespaces on a cluster) to support this process and enable automated testing (e.g. via OpenShift Pipelines or Jenkins ).

For persistent containers, it SHOULD be checked whether, in exceptional cases, an update of the respective container is more suitable than completely re-provisioning the container.

Note: “Persistent” containers contradict the cloud native principle and do not represent “good practice”. There is also a contradiction with APP.4.4.A21 “Regular restart of pods”. Accordingly, OpenShift does not support updates at the container level. Changes to the container image always result in the pod stopping and a new pod being restarted. With the recommended use of GitOps, this is a reprovisioning of the changed elements and also documents the status of the application at a given point in time. Due to the high level of automation, this usually does not represent any increased effort.

[sluetze]

ComplianceAsCode#12441 merged upstream