I'm trying to build a Helm Chart. There's a value (db.password) that sometimes should be passed as plain text, and other times as XOR+Base64.
I don't want to set two values, one for plain and another for encoded password, so I was trying do code a template function to do the encoding. Since sprigs already has base64 encoding, I've figured all I'd have to do was a XOR function... I already have a shell script for that, how hard could it be to port it to my template right?
I'm trying to iterate throught every charater of the string and XORing it:
{{- define "encrypt.decrypt" -}}
{{- $key := 95 -}}
{{- range $k,$v := splitList "" .password }}
{{- printf "%s" (add (atoi (quote $v)) $key | toString) -}}
{{- end }}
{{- end }}And then I'd call it like that:
{{include "encrypt.decrypt" (dict "Values" .Values "password" .Values.db.password) }}But all it does is print is 95 a lot of times. The convertion of an non-numeric character to int is not working and defaulting to 0.
atoi (quote $v)) is just returning 0.
I suspect you need a couple of pieces that aren't in either the core text/template functionality or Sprig and this turns out to not be reasonably possible.
The two big shortcomings I see:
splitList "" .password produces a list of single-character strings. That's useful, but there's no way to further reduce that to a list of Unicode code point values. Of note atoi $v will try to read a string as a number; it would understand the string "17" but doesn't know that "a" should become 97.
The only arithmetic functions available come from Sprig but those don't include any bitwise operations.
If you're only dealing with printable ASCII, one hacky thing you could do is build a static map from each character to its XOR:
{{- $xorMap := dict "!" "~" "~" "!"
"\"" "{" "{" "\""
"#" "|" "|" "#" ... -}}Then inside your range loop, index each character into this lookup map. If you have another way to validate the obfuscation, it's worth double-checking this (via helm template, for example).
If you already have a shell script that can do this it might be easier to configure the Docker container that eventually gets run to do this at startup time.