feat(grr): rebuild external client installers

[sujikathir]

Description of the change

Add explicit GRR client-builder address, port, and trusted-certificate values for
local and non-GCP deployments. Self-signed Fleetspeak certificates are reused
while their inputs remain unchanged and regenerated when the external
connection settings change. Client-builder Jobs are content-addressed so a
helm upgrade creates a new Job instead of patching its immutable pod template.
The builder also waits for the external endpoint to serve the current
certificate before repacking clients.

Document a reproducible KIND validation flow and add Helm rendering regression
coverage for the new value combinations.

Applicable issues

• fixes Test and create steps for manually building GRR clients for local setups #274

Additional information

Validated with:

• .github/scripts/test-grr-client-builder.sh
• helm lint charts/osdfir-infrastructure/charts/grr
• helm lint charts/osdfir-infrastructure
• A disposable KIND cluster, reproducing the fixed-name Job immutability error
  before this change and verifying successful upgrades, stable certificates for
  unchanged inputs, certificate rotation with the requested external DNS SAN,
  regenerated Job arguments, and completion of both builder init stages

Full installer artifact and GRR Admin UI validation still requires an amd64
Linux environment. The amd64-only GRR base image could not complete its Kaniko
unpack under Apple Silicon/Rosetta, so this PR does not claim that final
platform-specific check. Screenshots are not applicable because this changes
chart behavior and documentation rather than the UI.

Checklist

• Chart version bumped in OSDFIR Infrastructure Chart.yaml and the sub chart
  Chart.yaml according to semver. This is not necessary
  when the changes only affect README.md files.
• Run helm dependency update to pin updated Chart.yaml versions.
• Newly added variables are documented in the values.yaml
• Title of the pull request is descriptive

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[sujikathir]

@googlebot rescan

[wajihyassine]

Hi @sujikathir just getting around to this. Thank you for the contribution! This overall looks great, just one minor nit around the test you wrote.

Lastly, I've tested these changes and it all seems to work when using the Linux installer, but when I test with Windows, the connection back to Fleetspeak does not work. I think this may have to do with the config that gets written and referencing Linux file paths vs Windows. Is that something you would be able to test please? You could run Windows in dockur: https://github.com/dockur/windows

[wajihyassine]

I think there is a edge case where this could silently fail, could you change along the lines of

# Seperate the awk command from the helm template
changed_job_name="$(awk '/^  name: test-grr-client-builder-/ { print $2; exit }' <<<"$changed_render")"

# If statement for checking if job name was changed
if [ "$job_name" = "$changed_job_name" ]; then
  echo "Error: Job name did not change when clientBuilder inputs were modified!" >&2
  exit 1
fi
echo "Job name updated successfully on input change."

[sujikathir]

Thanks for the review, @wajihyassine. I addressed both points in 49ab62b:

• The render and awk extraction are now separate, and the test exits with an explicit error when changing clientBuilder inputs does not change the Job name.
• The Windows connection problem came from giving every target the same Fleetspeak filesystem persistence configuration, including Linux paths. Windows builds now select a separate config using registry_handler with HKEY_LOCAL_MACHINE\SOFTWARE\FleetspeakClient, matching GRR's Windows MSI integration fixture. Linux and Darwin continue to use the filesystem handler.

I reran the focused render test, both chart lints, Bash syntax, and git diff --check with Helm 3.12.1. I also completed an amd64 artifact-only build that produced release and debug Windows MSIs; the generated Fleetspeak config parses and is recognized as a registry handler.

I could not run the final client connection inside dockur/windows because this Docker Desktop host does not expose /dev/kvm. Could you please approve the new Lint and Test Charts and Markdown Linter workflow runs and re-review/retest the Windows connection?

[wajihyassine]

Hi @sujikathir thank you very much!

This is very close to done. Could you just check your logic for the Windows binary repack. It looks to be breaking and do not see the resulting windows binaries in the GRR UI.

ERROR:2026-08-28 21:15:59,589 49 MainProcess 139730063253504 MainThread repacking:189] Repacking template /client_templates/windows-installers/GRR_3.4.9.1_amd64.msi.zip failed:
Traceback (most recent call last):
  File "/usr/src/grr/grr/client_builder/grr_response_client_builder/repacking.py", line 186, in RepackTemplate
    result_path = builder_obj.MakeDeployableBinary(template_path,
  File "/usr/src/grr/grr/client_builder/grr_response_client_builder/repackers/windows.py", line 348, in MakeDeployableBinary
    with open(GetConfig("ClientBuilder.fleetspeak_client_config"),
FileNotFoundError: [Errno 2] No such file or directory: '/config/config.windows.textproto'
ERROR:2026-08-28 21:16:04,241 49 MainProcess 139730063253504 MainThread repacking:189] Repacking template /client_templates/windows-installers/GRR_3.4.9.1_amd64.msi.zip failed:
Traceback (most recent call last):
  File "/usr/src/grr/grr/client_builder/grr_response_client_builder/repacking.py", line 186, in RepackTemplate
    result_path = builder_obj.MakeDeployableBinary(template_path,
  File "/usr/src/grr/grr/client_builder/grr_response_client_builder/repackers/windows.py", line 348, in MakeDeployableBinary
    with open(GetConfig("ClientBuilder.fleetspeak_client_config"),
FileNotFoundError: [Errno 2] No such file or directory: '/config/config.windows.textproto'

[sujikathir]

Thanks for reproducing this. The missing Windows config came from mixing two revisions: the rendered chart supplied the updated server.local.yaml, but the builder Job cloned upstream main at runtime and built a context that did not contain config.windows.textproto.tmpl.

Fixed in 2914644. The chart now packages its exact client-builder Dockerfile and config files in a ConfigMap, copies that deterministic context into Kaniko, and no longer clones a moving branch during the Job. The render regression now checks that the Windows template is present in the mounted context and that Kaniko uses that context. I also merged current main in a5aa932, so the PR is conflict-free again.

Local validation with Helm 3.12.1:

• focused client-builder render regression passes
• GRR chart lint passes
• parent OSDFIR chart lint passes
• Bash syntax and git diff --check pass

The CLA, change-detection, and security checks on the new head have passed. Lint and Test Charts and Markdown Linter are waiting for fork-workflow approval. Could you please approve those runs and retry the Windows repack/UI check?