RUN-875: Add field/option to pull AWS Secret from Key Storage

[jsboak]

This PR adds a field to the Node Source configuration for retrieving the AWS Secret Key from Key Storage - rather than asking the user to "resubmit" their AWS Secret. This both reduces the number of steps to get setup with AWS resources, but also enables customers to limit the number of users who have direct access to AWS Credentials. This is similar to what has been done with the Azure Node Source plugin.

Behavior is that the plugin will use either the Key Storage Path or the Secret Key field - thereby being backwards compatible (this has been tested). If a user (mistakenly) provides inputs to both fields, then the plugin will use the one pulled from Key Storage.

[qualman]

Snyk error details:

PoC

File guavaTempDir = com.google.common.io.Files.createTempDir();
System.out.println("Guava Temp Dir: " + guavaTempDir.getName());
runLS(guavaTempDir.getParentFile(), guavaTempDir); // Prints the file permissions -> drwxr-xr-x
File child = new File(guavaTempDir, "guava-child.txt");
child.createNewFile();
runLS(guavaTempDir, child); // Prints the file permissions -> -rw-r--r--

For Android developers, it is recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime's java.io.tmpdir system property to point to a location whose permissions are appropriately configured. Remediation

There is no fix for com.google.guava:guava. However, in version 30.0 and above, the vulnerable functionality has been deprecated. In oder to mitigate this vulnerability, upgrade for version 30.0 or higher and ensure your dependencies don't use the createTempFile or createTempFile methods.

[qualman]

After discussion with Greg, we agreed that we could ignore this Snyk error, based on severity and the fact that we presently allow it in Rundeck Core. I will also create a PR to Core to update to a non-vulnerable version, but we don't need to wait for that here.

[qualman]

Everything functionally tests well here:

Valid Key Storage Key w/ Invalid Inline Key properly works

Invalid Key Storage Key w/ Valid Inline Key properly fails

Valid Key Storage Key w/ Valid Inline Key properly works

Role Assumption ARN Only properly works

Valid Key Storage Key only properly works

Valid Inline Key only properly works

[qualman]

With all that said, we should have at least a couple of tests to cover this new paradigm. I am going to add those.

[qualman]

Done with the test. Ready for review and merge.

[qualman]

All good!