Enhance `setup.sh` to Support Pre-baked Binary & Custom Download Command

[dmytro-trainych-flutter]

Summary

The current setup.sh always downloads the jfrog-credential-provider binary via curl from JFROG_CREDENTIAL_PROVIDER_BINARY_URL. In restricted environments (no/limited egress, private endpoints, authenticated artifact stores), this is brittle. It would be nice to upgrade the script/chart to support:

1. Using a pre-baked/local binary path (skip download entirely)
2. Using a custom download command/template (support auth + non-HTTP sources like S3, Artifactory with access tokens, etc.)

Motivation

• Clusters with restrictive egress rules often cannot reach public URLs.
• Many orgs pre-bake required binaries into node images or ship them via internal artifact stores.
• Authenticated downloads (e.g., Artifactory requiring API key/token, AWS S3 presigned URLs, private endpoints) can’t be expressed cleanly with the current hardcoded curl -L -f.

Current Behavior

• setup.sh builds an arch-specific URL and runs:
  • curl -L -f -o ${KUBELET_MOUNT_PATH}${JFROG_CREDENTIAL_PROVIDER_BINARY_DIR}/{{ .name }} "${JFROG_CREDENTIAL_PROVIDER_BINARY_URL}"
• If download fails, it sleeps and exits to trigger pod restart.

Proposed Changes

1) Add “local/pre-baked binary” option

Allow specifying a local source path (inside the container image or host-mounted path) and copy it into ${JFROG_CREDENTIAL_PROVIDER_BINARY_DIR}/{{ .name }}.

New values (example):

• values.yaml
  • binary.source: download|local
  • binary.localPath: /opt/jfrog/jfrog-credential-provider (inside the injector container), or optionally from a mounted volume
  • binary.skipChmod: false (optional)

Behavior:

• If binary.source == local:
  • Validate file exists and is executable (or chmod it)
  • Copy to target location
  • Skip all URL/arch logic and download flow

2) Add “custom download command” option

Allow users to provide a full download command template used to fetch the binary.

New values (example):

• binary.downloadCommand: >
curl -L -H "Authorization: Bearer ${ARTIFACT_TOKEN}" -f -o "{{TARGET}}" "{{URL}}"
• Alternative examples:
  • S3: aws s3 cp "s3://my-bucket/path/{{NAME}}-{{ARCH}}" "{{TARGET}}"
  • Artifactory CLI: jfrog rt dl ...
  • Curl with mTLS, proxy, custom CA bundle, etc.

Behavior:

• If binary.downloadCommand is set, use it instead of the hardcoded curl invocation.
• Provide well-defined placeholders/variables:
  • {{TARGET}} → ${KUBELET_MOUNT_PATH}${JFROG_CREDENTIAL_PROVIDER_BINARY_DIR}/{{ .name }}
  • {{URL}} → resolved URL (including arch suffix if applicable)
  • {{ARCH}} / {{ARCH_SUFFIX}}
  • {{NAME}} → {{ .name }}
• Keep existing retry/sleep/exit behavior on failure.

Backwards Compatibility

• Default behavior remains unchanged if:
  • binary.source is not set (defaults to download)
  • binary.downloadCommand is not set (defaults to current curl -L -f ...)

Implementation Notes (Suggested)

• Extend Helm values + template to render new env vars into the setup container:
  • JFROG_CREDENTIAL_PROVIDER_BINARY_SOURCE
  • JFROG_CREDENTIAL_PROVIDER_BINARY_LOCAL_PATH
  • JFROG_CREDENTIAL_PROVIDER_DOWNLOAD_COMMAND
• Update setup.sh:
  • Compute TARGET_PATH once
  • Branch:
    • local copy flow
    • download flow (either custom command or curl)

Example Use Cases

1. Air-gapped / no egress: binary shipped in image, set binary.source=local.
2. Private Artifactory with token: set binary.downloadCommand using Authorization header.
3. S3 bucket with IAM: set binary.downloadCommand using aws s3 cp.

[RobinDuhan]

Makes sense. For pre-baked machine images, You will be able to replace the downloadUrl with a file://<path-to-your-file>, and it should work since curl accepts local paths.

I do agree on needing a custom download command for other sources. I'll add it as a feature request.