Support JSON format secrets

[pjdarton]

When using the AWS WebUI to create secrets, it guides you through the process but it creates the secret as a bit of JSON rather than raw unformatted text.
This plugin, however, currently expects the secret, e.g. the password of a username+password pair, to be the raw secret data with everything else stored in tags (which aren't secret).

This PR adds two JSON-based credentials:

• JSON containing a username and a password field
• JSON containing a username, privatekey and (optional) passphrase field.

Using JSON means that these secrets are easier to set up using the AWS Web UI (but harder to set up using the aws command-line), and also means that we can keep more things secret.
e.g. in both cases, the username is now also declared as being secret.

Note: this code could do with an integration test added ... and advice on how to do that would be appreciated.

[pjdarton]

I've just (interactively) tested the jsonUsernamePassword one and that seems to work just fine.

[pjdarton]

@chriskilding This code seems to work in practise ... but I'd like to know how to add an integration test for it (so it's as tested as the other credentials).
Can you advise on how I can do that?

...and let me know if there's anything else that needs doing to make this enhancement acceptable.

[pjdarton]

Note: There seem to be "infrastructure issues" on the JenkinsCI server - the build passed originally but, on a later (re)run, the CI tests ran so slowly that they didn't complete within an hour, causing the build to be timed out and aborted (which was then reported to github as a failure).
FYI the build on the main branch seems to have the same problem - CI builds are really slow.

[chriskilding]

Hi Peter,

I'm currently working on adding JSON secret support to the Secrets Manager SecretSource / Configuration As Code plugin, since that is a more tractable place to start. I think we've almost landed at a solution for that - if you're interested in testing, let me know and I'll send instructions.

Yep, the CI builds on ci.jenkins.io do flake out a bit - that seems to happen for any plugin so there's not much I can specifically do about that.

However this plugin in particular is heavy on integration tests, and unfortunately the testcontainers library is pretty slow at starting Docker images. The two combine to produce rather long build times. We used docker-maven-plugin before, which started a Secrets Manager container before the entire test suite, then shut it down afterwards, but that was not significantly faster - I think most of the time is eaten by the embedded Jenkins setup per-test.

I'd like to do something about this, but I don't know what.