[patch] Rename Facilities MREF AES Keystore Secret for gitops - #2597
AditIBM931 wants to merge 19 commits into
Conversation
mnivedithaa
left a comment
mnivedithaa
left a comment
There was a problem hiding this comment.
FACILITIES_LIBERTY_EXTENSIONS_SECRET should be updated to original instance level secret
|
re-ran pipeline successfully: https://cloud.ibm.com/devops/pipelines/tekton/39587f23-e891-42a3-ad41-da50d48e6693/runs/4f79c191-1e67-4295-a12d-207a83261aea?env_id=ibm:yp:us-south tested with a temporary aws secret: 
|
mnivedithaa
changed the title
|
Removed legacy secrets fallback, but restored libertyExtensionXML secret name validation enforcing. Relevant pipeline: https://cloud.ibm.com/devops/pipelines/tekton/39587f23-e891-42a3-ad41-da50d48e6693/runs/fc160451-ee7c-4046-bcbd-b81f02d5978b?env_id=ibm:yp:us-south |
whitfiea
changed the title
| # Set customer-level secret path (without trailing separator) | ||
| export FACILITIES_VAULT_SECRET="ibm-customer${SECRETS_KEY_SEPERATOR}${ICN}${SECRETS_KEY_SEPERATOR}facilities" | ||
| export FACILITIES_LIBERTY_EXTENSIONS_SECRET="ibm-customer${SECRETS_KEY_SEPERATOR}${ICN}${SECRETS_KEY_SEPERATOR}facilities" | ||
| export FACILITIES_LIBERTY_EXTENSIONS_SECRET="${ACCOUNT_ID}${SECRETS_KEY_SEPERATOR}${CLUSTER_ID}${SECRETS_KEY_SEPERATOR}${MAS_INSTANCE_ID}${SECRETS_KEY_SEPERATOR}facilities" |
There was a problem hiding this comment.
why was the FACILITIES_LIBERTY_EXTENSIONS_SECRET changed? it isn't mentioned in the issue or PR
There was a problem hiding this comment.
main-facilities-lexml--sn was restored to instance level due to issues in the Gitops pipeline, therefore FACILITIES_LIBERTY_EXTENSIONS_SECRET also needed to be restored to instance level for correct pathing in AWS
|
|
||
| # Get user-provided secret name from app spec (if any) | ||
| USER_PROVIDED_VAULT_SECRET=$(yq eval '.mas_appws_spec.settings.vaultSecret.secretName // ""' ${MAS_APPWS_SPEC_YAML_RESOLVED}) | ||
| USER_PROVIDED_LIBERTY_SECRET=$(yq eval '.mas_appws_spec.settings.libertyExtensionXML.secretName // ""' ${MAS_APPWS_SPEC_YAML_RESOLVED}) |
There was a problem hiding this comment.
we are not using the provided liberty secret name?
There was a problem hiding this comment.
Yes, the liberty secret name is taken directly from CR and validated against the format main-facilities-lexml--sn
There was a problem hiding this comment.
main-facilities-lexml--sn was originally an instance level secret and these changes caused an issue in the Gitops pipeline, so it was reverted
There was a problem hiding this comment.
The following is the slack thread is where the Gitops issue was reported, it might help put things better into context: https://ibm-mas.slack.com/archives/C0161LRJWDU/p1788890475858589
3 participants
Fix: Rename Facilities MREF AES Keystore Secret
Problem
The CLI stored the MREF keystore password in AWS SM under
manage-mref-keystore-passwordand setfacilities_vault_secret_nameto the same value. However, sincevaultSecret.secretNamewas never set in the FacilitiesWorkspace CR, Facilities ignored the CLI-managed secret and created its own K8s secret (main-facilities-vs--sn) with an independently generated password.This meant all MAS instances for a given customer (ICN) used different MREF passwords, defeating the purpose of the customer-level shared secret and causing backflow issues when moving data between environments.
Jira issue: https://jsw.ibm.com/browse/MASCORE-16222
Solution
Rename the secret to match the name Facilities natively uses (
{workspace_id}-facilities-vs--sn) so ArgoCD injects the CLI-managed password directly into the secret Facilities already reads — without requiring any Workspace CR update.The secret JSON key is also updated from
passwordtopwdto match what the Facilities operator expects.Changes
image/cli/mascli/functions/gitops_suite_app_configFACILITIES_VAULT_SECRET_NAMEdefault:manage-mref-keystore-password→${MAS_WORKSPACE_ID}-facilities-vs--snFACILITIES_AWS_SECRET_NAMEintroduced to separate the AWS SM secret name from the K8s secret name for use in validationmanage_customer_mref_password()call updated to passMAS_WORKSPACE_IDas new 5th argumentFACILITIES_AWS_SECRET_NAMEwith fallback toFACILITIES_VAULT_SECRET_NAMEfor user-provided secretspassword→pwdimage/cli/mascli/functions/gitops_utils—manage_customer_mref_password()New
MAS_WORKSPACE_IDparameter added as 5th argument (SECRETS_KEY_SEPERATORshifted to 6th)AWS secret name renamed:
manage-mref-keystore-password→{MAS_WORKSPACE_ID}-facilities-vs--snSecret JSON key changed from
password→pwd(read and write)added a fallback to ensure existing environments preserve their current password across the rename.:
{workspace_id}-facilities-vs--sn(new secret)manage-mref-keystore-password(customer-level){account}/{cluster}/{instance}/facilities/manage-mref-keystore-password(instance-level)image/cli/mascli/templates/gitops/appset-configs/cluster/instance/masapp/ibm-mas-masapp-config.yaml.j2#password→#pwdso ArgoCD resolves the correct key from AWS SM when creating the K8s secretTesting
successful run of the pipeline and creation of
{MAS_WORKSPACE_ID}-facilities-vs--sn: https://cloud.ibm.com/devops/pipelines/tekton/39587f23-e891-42a3-ad41-da50d48e6693/runs/682bb488-0d04-4e1b-9161-cfec266d42c5?env_id=ibm:yp:us-southverification of the secrets:
Additional Changes
FACILITIES_LIBERTY_EXTENSIONS_SECRETpath restored to instance-levelLiberty extensions XML is an instance-specific server configuration and must be stored per-instance, not shared across all instances of a customer and was thus restored back to instance-level.
Restored liberty secret name validation
The only allowed format is:
{workspace_id}-facilities-lexml--snIf a user sets a non-standard liberty secret name in the FacilitiesWorkspace CR, the pipeline will fail with a clear error message. It also fails if the liberty secret is missing.