feat: add Windows 2019 and Windows 2022 infrastructure bundle images(NR-528123)

[nravada]

No description provided.

To fix the problem, explicitly define GITHUB_TOKEN permissions in the workflow, restricting them to the minimum needed. Since none of the jobs in .github/workflows/build.yml appear to require write access to the repository (they only check out code, set up QEMU/Buildx/Go, build images, and run validation), a safe and minimal configuration is to set permissions: contents: read at the top (workflow) level. This applies to all jobs that do not override permissions, including build-windows-2022.

Concretely, in .github/workflows/build.yml, add a permissions block between the name: Container build line and the on: block. For example:

name: Container build
permissions:
  contents: read
on:
  push:
  ...

No additional imports or methods are needed because this is purely a YAML configuration change. We do not need per-job permissions blocks unless a specific job needs different permissions; based on the provided snippet, that is not required.

In general, the fix is to add an explicit permissions block that restricts the GITHUB_TOKEN to the minimal access the job needs, typically contents: read when the job only needs to check out code. This block can be added at the workflow root (affecting all jobs without their own permissions) or specifically on the flagged job.

To fix this workflow without changing its behavior, add permissions: contents: read at the top level, just after name: Nightly build (line 1). All jobs in this workflow only appear to need read access to repository contents (checkout operations); they push Docker images using registry credentials from secrets, not GITHUB_TOKEN. A root-level permissions block will therefore satisfy CodeQL’s requirement and apply the least privilege consistently across nightly, nightly-fips, nightly-windows-2019, and nightly-windows-2022, without altering any existing steps.

Concretely:

• Edit .github/workflows/nightly.yml.
• Insert:

permissions:
  contents: read

between the existing name: and on: keys. No additional imports, methods, or other definitions are required.

In general, the fix is to explicitly restrict GITHUB_TOKEN permissions in the workflow to the minimum required, instead of relying on repository/organization defaults. For this workflow, the jobs only need to read repository contents (for actions/checkout); no job appears to require write access to the GitHub API.

The best, non-invasive fix is to add a root-level permissions block just under the name: (and before on:) that applies to all jobs. Set it to contents: read, which is sufficient for actions/checkout while preventing unnecessary write permissions. No other functionality is changed, and no additional imports or methods are needed because this is a pure YAML configuration update in .github/workflows/on-demand.yml.

Concretely, in .github/workflows/on-demand.yml, insert:

permissions:
  contents: read

after line 1 (name: On demand build). No per-job overrides are required.

To fix the problem, explicitly define a permissions block to restrict the default GITHUB_TOKEN permissions instead of relying on inherited repository defaults. Since the jobs only need to read the repository contents (for actions/checkout) and do not appear to require write access to issues, pull requests, or contents, we can safely set contents: read at the workflow level. This will apply to all jobs (container-release, container-release-fips, container-release-windows-2019, and container-release-windows-2022) and avoids duplicating the same permissions for each job.

The single best change, without altering existing behavior, is to add a top-level permissions block right after name: Container release (before on:). This keeps the jobs intact and simply constrains the GITHUB_TOKEN. No imports or external packages are needed, as this is purely a YAML configuration change inside .github/workflows/release.yml.

In general, the fix is to add an explicit permissions: block that grants only the minimal required scopes for GITHUB_TOKEN. Since these jobs just build and scan images, check out code, and validate markdown, they only need read access to repository contents; no write scopes are required.

The best minimal fix without changing existing functionality is to add a workflow‑level permissions: block after the name: (or after on:) setting contents: read. This will apply to all jobs (build, build-fips, build-windows-2019, build-windows-2022) since none of them define their own permissions:. No additional imports or definitions are needed; this is a pure YAML configuration change in .github/workflows/build.yml.

Concretely:

• Edit .github/workflows/build.yml.
• Insert:

permissions:
  contents: read

right after the name: Container build line (line 2 in the snippet). This constrains GITHUB_TOKEN for all jobs, resolving the CodeQL finding for the build-windows-2019 job and the workflow as a whole.

In general, fix this by explicitly setting a permissions block either at the workflow root (applies to all jobs without their own permissions) or on each job, granting only the scopes actually required (usually contents: read for build jobs that just check out code). For the shown workflow, the nightly-windows-2019 and nightly-windows-2022 jobs only need to read repository contents and use external credentials (via secrets) to log into Docker Hub; they don’t appear to call GitHub APIs that require write access. The simplest, least-disruptive fix is to define a single workflow-level permissions block with contents: read, which will apply to all jobs here (including the reusable-workflow jobs, unless they override it). This both satisfies CodeQL and enforces least privilege going forward.

Concretely, edit .github/workflows/nightly.yml to add:

permissions:
  contents: read

near the top of the workflow, after the name: and before on:. No imports or additional definitions are needed, since this is just YAML configuration. This change should not affect existing functionality, as the jobs already behave correctly with at least contents: read (required by actions/checkout).

In general, you fix this by explicitly setting permissions for the GITHUB_TOKEN either at the workflow root (applies to all jobs without their own permissions) or on each job, and restricting it to the minimal scope needed, typically contents: read for build/publish workflows that don’t modify repo state.

For this workflow, the best minimal change without altering existing functionality is to add a root-level permissions: block right under the workflow name: (before on:). None of the jobs require write access to the repository with GITHUB_TOKEN; they use actions/checkout, Docker-related actions, Trivy, and Docker Hub credentials via secrets, all of which work with contents: read. Therefore, we set:

permissions:
  contents: read

This will cover all jobs (build, build-fips, build-windows-2019, build-windows-2022) without needing per-job edits. Concretely, in .github/workflows/on-demand.yml, insert the permissions: block between line 1 (name: On demand build) and line 2 (on:). No imports or other definitions are required.

In general, fix this by explicitly defining a permissions block that grants only the scopes the workflow actually needs, either at the workflow root (applies to all jobs) or per job. Here, none of the jobs appear to need to write back to the GitHub repository; they only read the release event and source code. Therefore contents: read is a safe minimal permission set.

The best fix with minimal functional change is to add a single top-level permissions block after the on: section, e.g. on a new line after line 4. This will apply to all jobs (container-release, container-release-fips, container-release-windows-2019, and container-release-windows-2022) that don’t override permissions, satisfying CodeQL’s requirement and constraining GITHUB_TOKEN to read-only repository contents. No additional methods, imports, or definitions are needed; this is a pure YAML configuration change.