Closed saprette closed 4 years ago
@saprette Thank you for filing this issue and with enough detail to make it very easy to reproduce! This repo is maintained by developers that live in IL and it is currently their weekend (they work Sun-Thr) so it may be a few days until you get a response. It looks like the input might just need json encoding before the patching over K8s API is done but I'm not familiar enough with the codebase to speculate much. Let me know if you don't hear anything from the repo devs by mid-next week.
CC: @orenbm
Hi @saprette, looking into this issue now. Thanks for logging it - the detail logged will certainly help us reproduce. Will respond back once I have an answer for you!
Hello, this fix works for me https://github.com/cyberark/secrets-provider-for-k8s/pull/78 I'll use my custom build for now as it works for my use cases, let me know what you plan to do as I'll need a fix from you before I go to production.
Hello,
cyberark/secrets-provider-for-k8s seems to have issues understanding complex secrets such as ssh keys or json documents.
Some details on the environment I'm using :
Setup the required policies to be able to use the authenticator kubernetes-authenticator-client in the namespace argocd.
A variable someenv/hf333ocp/artifactory-pull-secret/dockerconfigjson is set ->
Using this test secret as starting state of the secret, and this simple job.
In that case, simple password works and the K8 secret is correctly updated with the secret value from Conjur
However, if I set the secret value with a more complex json document ->
In that case cyberark/secrets-provider-for-k8s fails with the following parsing error. Note that the same kind of parsing error occurs for an ssh key (but this time complaining about a \r character).
Describe the solution you would like
cyberark/secrets-provider-for-k8s should support retreiving secrets as complex as it is possible to add in Conjur.
Describe alternatives you have considered
Encoding the json document or ssh key in base64 prior storing to Conjur removes the issue however it removes the main added value of cyberark/secrets-provider-for-k8s as in that case the workload using the secret must process it to make it a standard ssh key or document, which is not always possible when you don't own the binaries of that workload (what I see as the main use case of cyberark/secrets-provider-for-k8s).