In Kubernetes and OpenShift, updating secrets created from files lacks a direct command. This article outlines the issue and workarounds.

The Challenge

Secrets from --from-file are immutable key-value pairs. Re-running creation commands fails for updates, requiring alternatives.

A commonly used workaround is as follows:

1. Create a new Secret using the updated file.

2. Update the reference to the new Secret in the Custom Resource (CR), for example using the lombardi_custom_xml_secret_name parameter in Workflow Runtime.

3. Apply the updated CR.

While functional, this approach introduces additional operational steps and requires changes to the CP4BA CR YAML, which may not always be desirable.

Available Solutions

There are, in fact, two practical workarounds that allow updating Secrets without fully recreating and re-referencing them.

Workaround 1: Update the Key Within the Existing Secret

In the existing Secret:

1. Create a new key with the same name as the current key and upload the updated file content.

2. Remove the old key.

This approach preserves the Secret name and avoids any changes to the CR references.

Workaround 2: Re-apply the Secret Using oc apply

Another effective method is to recreate the Secret manifest from the updated file and apply it, allowing Kubernetes to update the existing Secret in place.

Example 1: Updating Workflow Authoring Liberty Configuration:

oc create secret generic custom-liberty-xml --from-file=sensitiveCustom.xml=./custom.xml --dry-run=client -o yaml | oc apply -f -

Example 2: Updating Workflow Runtime Liberty Configuration:

oc create secret generic custom-liberty-xml \
  --from-file=sensitiveCustomConfig=./custom.xml \
--dry-run=client -o yaml | oc apply -f -

Conclusion

This approach is clean, repeatable, and does not require modifying the CR, making it well-suited for operational and automation use cases.

------------------------------
Peter Victor
------------------------------