It seems source-controller v0.26.0 and later are doing some query parameter manipulation that breaks using SAS tokens in a HelmRepository URL to access a private Azure Blob.
Example:
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
name: example-helm-repo
namespace: flux-system
spec:
interval: 1m0s
provider: generic
timeout: 60s
url: https://(STORAGE ACCOUNT NAME).blob.core.windows.net/helm?(SAS TOKEN)
The HelmRepository resource reconciles fine and returns:
$ flux get source helm
NAME REVISION SUSPENDED READY MESSAGE
example-helm-repo (SHA) False True stored artifact for revision '(SHA)'
HelmReleases referencing this HelmRepository however end up failing:
$ flux get helmrelease -A
NAMESPACE NAME REVISION SUSPENDED READY MESSAGE
(NS) (CHART) (CHART-VERSION) False False HelmChart 'flux-system/(NS)-(CHART)' is not ready
The HelmChart resource itself shows an error wherein the SAS token has been mangled and includes a bunch of !!(MISSING) strings after any spot where there was a urlencoded %(whatever) code and gets a 403 back from Azure: (wordwrapped slightly for readability)
$ flux get source chart
NAME REVISION SUSPENDED READY MESSAGE
(NS)-(CHART) False False chart pull error: failed to download chart for remote reference:
failed to fetch https://(STORAGE ACCOUNT NAME).blob \
.core.windows.net/helm/(CHART)-(CHART-VERSION).tgz?(MANGLED SAS) :
403 Server failed to authenticate the request. Make sure the value
of Authorization header is formed correctly including the signature.
This exact same configuration works fine on source-controller v0.25.11 and earlier.
It seems source-controller v0.26.0 and later are doing some query parameter manipulation that breaks using SAS tokens in a HelmRepository URL to access a private Azure Blob.
Example:
The HelmRepository resource reconciles fine and returns:
HelmReleases referencing this HelmRepository however end up failing:
The HelmChart resource itself shows an error wherein the SAS token has been mangled and includes a bunch of
!!(MISSING)strings after any spot where there was a urlencoded%(whatever)code and gets a 403 back from Azure: (wordwrapped slightly for readability)This exact same configuration works fine on source-controller v0.25.11 and earlier.