Open monitz87 opened 1 year ago
I just had this problem today following the docs
I'm going to shamelessly bump this.
I know fixing the bug is not trivial (lots of moving parts, updating the image, helm chart, tests, making sure everything works, etc etc).
On the other hand, adding a simple note in the docs explaining the bug and how to work around it should take less than 5 minutes, and it would save countless hours of dev time for users.
I'll happily submit a PR for the docs, but I'm not sure if you'd rather present it as a bug or intended behavior.
I've got the same issue and so I also had to double encode 1password-credentals.json.
cat 1password-credentials.json|base64| tr -d \\n|base64
If anyone from the team can tell me whether they want to present this in the docs as intended behavior or a bug with its corresponding workaround, I will gladly submit a PR that addresses the issue.
I too have ran into this issue when attempting to create a sealed secret for the credentials. It's a bit confusing how to go about this with the double encoding. Should I create the secret with --from-literal=1password-credentials.json=<base64 encoded 1password-credentials.json>
?
@heliochronix , I assume you've just given up by now... But for future seekers of information: The key I finally stumbled across after way too long is to remove the line wraps base64 adds by default. If your chart is deployed to the namespace onepassword-whatever
, which would be weird, and you're using the other helm chart defaults:
mv 1password-credentials.json 1password-credentials.json.pre-encode
base64 -w 0 < 1password-credentials.json.pre-encode > 1password-credentials.json
kubectl --namespace onepassword-whatever create secret generic op-credentials --from-file 1password-credentials.json
Another option for that middle step is cat 1password-credentials.json.pre-encode | base64 | tr -d \\n > 1password-credentials.json
, though there are probably lots of other options too.
Either way, when you use the base64 CLI, you need to stop it from inserting newlines every 80 chars, because the second encode includes those newlines and results in a broken file. It shouldn't break, since most base64 decode implementations ignore newlines. I'd argue that's a bug. But this whole behavior is a little sketchy to begin with, so what's one more quirk? :D
Same issue here deploying 1password-connect do kubernetes managed by flux OS. After 2 days trying make a deploy works. Finally done just encoding 1password-credentials.json to base64 after store it as a secret on ks8.
Please, update documentation or fix the bug!
This might be because my use case is weird, but still.
I'm using Kustomize with the
helmCharts
option to inflate the 1password connect charts, but I'm deploying the secret that contains1password-credentials.json
using the command in the kubernetes example.This is the command I'm referring to
That produces the following secret:
The problem is that what gets assigned to the
OP_SESSION
env variable in theconnect-api
container is already decoded, so it's the plain JSON contents of the file (I quadruple checked by opening an ssh tunnel into the container), but apparently the container expects the value to still be base64 encoded, and tries to decode it again.This causes 500 errors when making requests to the API, which look like this in the service logs:
I managed to make things work by encoding the JSON to base64, encoding that base64 value to base64 AGAIN, and then manually creating the secret manifest file and assigning that doubly-encoded value to the
data.1password-credentials.json
key.There's a chance that this is caused by a combination of the kubernetes (v1.25.4) and chart (non-specified, so I assume latest) versions I'm using. The images for both
connect-api
andconnect-sync
are at version 1.5.7.It feels more like either a bug in the container or an error in the example docs, although my money is on the bug, I see no sensible reason why the file should be encoded/decoded twice.
I'm equal parts frustrated and proud for having finally figured this out.
Cheers