feat: support generic secret in docker auth

[quixoten]

Overview

currently, the webhook only supports unwrapping the value of the auth key if it's in a specific user:pass format. this limitation prevents the webhook from working correctly for other valid formats of the auth value, e.g., _json_key.

[csatib02]

This approach is rather forgiving, as it treats all cases where the authentication is not via username and password, as _json_key right away, without verification. This is quite error-prone.

[quixoten]

I probably should have avoided using the specific _json_key as the example. The implementation should actually cover any case. Let me see if i can explain better given the following example:

    {
        "auths": {
            "https://index.docker.io/v1/": {
                "auth": "vault:secret/data/dockerrepo#ANY_VALUE"
            }
        }
    }

(showing the auth value base64 decoded for clarity)

previously, the webhook would make no attempt to unwrap this auth value, because it doesn't match the user:pass format it expects, i.e., vault:secret/data/creds#USER:vault:secret/data/creds#PW. instead, it would fail with the splitting auth credentials failed error. there are certainly issues with the previous implementation. one being that it is restrictive, and another being that it doesn't support transit values, i.e., vault:v1:aGkK:vault:v1:YnllCg== could be a valid username:password but will fail with the same splitting auth credentials failed error.

my goal with this change is to leave the previous functionality (including assumptions) in tact, but opening up the possibility for the user to put whatever they need to inside of the auth value. instead of failing with the splitting auth credentials failed error, it will now make an attempt to unwrap the value (we've already verified it starts with the vault prefix at this point) and, if successful, swap it in. this gives the user full control of the auth value. it could be a _json_key or it could be user:pass or anything else.

[csatib02]

Your observation is astute. Indeed, the main issue here is that using len(split) for control flow can be quite misleading for someone reading the code. It's not immediately clear how the length of the split array relates to the logic being implemented, which can make the code harder to understand and maintain. A more explicit and self-explanatory approach to control flow would likely improve code readability and reduce potential confusion for other developers working with this code.

The thing I wrote about verification, is for the same reason. If someone sees a verification function being called e.g.:

json.Valid(auth) // verifying JSON format
isValidPrefix(string(auth)) // verifying whether a string is a valid Vault path that can be consumed by the injector.

Immediately knows what is happening, and what values can be used.

[csatib02]

Hey @quixoten,
First of all thank you for your contribution!
Vault-Secrets-Webhook, will no longer be maintained in the near future, because it will be replaced with our new Webhook project.
I already added this feature to that one, but adding an e2e test-case for json_key handling seems reasonable, may I ask you to please take a look at Secrets-Webhook and if you have the time for it incorporate your changes regarding the e2e tests on that project?

In the meanwhile I left a few comments.
Also, please sign your commits, there are instructions if you click on the failed DCO check.