chore: sanitize CI inputs via env var

[dreamorosi]

Summary

Changes

Please provide a summary of what's being changed

This PR updates several workflows to use environment variables to temporarily store workflow inputs, before passing them to the command and expanding them as a string. For example, ${{ input.version }} now becomes $VERSION with the variable being stored under env.

The PR also adds double quotes in multiple places to ensure string expansion works as intended.

Please add the issue number below, if no issue is present the PR might get blocked and not be reviewed

Issue number: closes #4529

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[Copilot]

Pull Request Overview

This PR sanitizes CI workflow inputs by replacing direct GitHub Actions input references in shell commands with environment variables, improving security by preventing potential injection attacks.

• Replaces ${{ inputs.* }} expressions in shell commands with environment variables
• Adds env blocks to define environment variables from workflow inputs
• Updates shell commands to reference environment variables instead of direct inputs

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
.github/workflows/update_ssm.yml	Sanitizes SSM parameter names using PREFIX and PACKAGE_VERSION env vars
.github/workflows/run-e2e-tests.yml	Sanitizes PR number input for GitHub CLI checkout command
.github/workflows/reusable_publish_docs.yml	Sanitizes version input and replaces inline GitHub expressions in jq commands
.github/workflows/publish_layer.yml	Sanitizes CDK context parameter using LAYER_VERSION env var
.github/workflows/layers_partitions.yml	Sanitizes layer version inputs and environment checks
.github/workflows/layers_partition_verify.yml	Sanitizes version and partition version inputs
.github/workflows/layer_balance.yml	Sanitizes region and start_at inputs for balance command
.github/workflows/bootstrap_region.yml	Sanitizes region input for CDK bootstrap and balance commands

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

To fix the problem, replace dynamic secret access with static mapping so that each job only receives the secret(s) it requires. Instead of ${{ secrets[format('AWS_ACCOUNT_{0}', steps.transform.outputs.CONVERTED_REGION)] }}, declare environment-specific and region-specific secrets explicitly for each region/partition combination you intend to use. Then, in your workflow matrix or steps, use conditional logic (if) to select the correct secret and expose it only when needed.

The recommended approach is:

• Predefine a matrix for all supported regions.
• For each region, create explicit environment variables or conditional blocks, mapping the correct region to its static secret name, e.g., secrets.AWS_ACCOUNT_CN_NORTH_1, secrets.AWS_ACCOUNT_US_GOV_WEST_1, etc.
• Use if: blocks or environment mapping to set the correct secret value per region.
• Replace all usages of secrets[format(...)] with the correct explicit secret variable, i.e., ${{ secrets.AWS_ACCOUNT_CN_NORTH_1 }}.
• Similar mapping for role-to-assume.

This can be done either by:

• mapping the secret at the matrix level via include, or
• using env per step/job with conditionals.

Edit only lines using dynamic secret access in the file .github/workflows/layers_partition_verify.yml. No additional imports or method definitions are needed beyond YAML syntax.

To fix this problem, avoid dynamic (runtime) references to secrets. Instead, enumerate the possible environment/partition/region combinations and statically assign secrets for each one, ensuring that only the necessary secret is referenced in a given job or matrix entry. In a matrix job, you can "branch" on known values (e.g., matrix.region) and set the required secret in static env: blocks. For example, have an explicit mapping:

env:
  AWS_ACCOUNT: ${{ secrets.AWS_ACCOUNT_CN1 }}

for region cn-north-1, and so on for each allowed region value.

For this file, replace the dynamic ${{ secrets[format(...)...] }} with static secret references, using the if: conditional on steps so that only the relevant secret is used for each region. This requires one step per unique region, each with its explicit secret reference, rather than a single, dynamic step.

Steps:

1. For each possible value that steps.transform.outputs.CONVERTED_REGION could produce, add a separate - name: step with an explicit (static) secret reference for that region.
2. Use if: conditional to select the step based on the steps.transform.outputs.CONVERTED_REGION output and/or on the matrix.region.
3. For each explicit region, use the appropriate ${{ secrets.AWS_ACCOUNT_REGION_NAME }}.
4. Optionally, if there are many regions, you can group similar ones or use reusable workflows, but always via static secret names.

Files/regions to change:

• Only .github/workflows/layers_partitions.yml, specifically the step at line 194, must be modified to avoid dynamic secret referencing.

What's needed:

• Multiple steps (one per region), each referencing the correct secret explicitly and gated by an if: clause.
• Or, if matrix is small, set an environment variable in the matrix/strategy definition (with explicit mapping).

---

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dreamorosi]

@sdangol you worked on the secrets access last, can you please check if Copilot's suggestions are appropriate? If not we can dismiss them together with the findings that might pop up after merging.

[sdangol]

@dreamorosi Those are the same ones that we had discussed last time about the issue being mitigated by the use of environment specific secrets. So, the findings are a false positive.

[dreamorosi]

Yes, I know, we had to revert them because the solution we came up with didn't work.

I was wondering if Copilot's solution is better and might work.

[sdangol]

The suggested solution will need some adjustments to make it work like the checking for the CONVERTED_REGION value is wrong. Nonetheless, including the regions even just for the china and the gov cloud regions would make it very verbose.

[dreamorosi]

Ok, thanks for checking - I remember you mentioning this in the previous iteration as well.

Happy to ignore the suggestions and merge whenever you're ready to approve (tomorrow after the release is fine).