[feature] Allow AWS static keypairs to be used for authN

[chriskilding]

trafficstars

Add a new Client CredentialsProvider configuration strategy which lets the Jenkins administrator specify an AWS static key pair for the plugin to use (accessKey and secretKey).

This is to support users who want to configure the plugin with a long-lived AWS access keypair, but who cannot modify the server that Jenkins is running on. (In this scenario, the normal methods of injecting the keypair - via the Jenkins environment or AWS profiles - are not available to them.)

Fixes #94

Standard tasks:

• [x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [x] Link to relevant issues in GitHub or Jira
• [x] Link to relevant pull requests, esp. upstream and downstream changes
• [x] Ensure you have provided tests - that demonstrates feature works or fixes the issue

Outstanding tasks:

• [ ] Decide whether accessKey and secretKey are the most appropriate terms for the variables.
• [x] Add Jenkins field validations to check that accessKey and secretKey are not empty/null
• [ ] Security review
  • [ ] Is the keypair adequately protected within the Jenkins config by Hudson encryption?
  • [ ] Is it okay to have accessKey be a plaintext field and secretKey be a protected field?
  • [ ] Will field validations expose the value of secretKey in an undesirable way? (They look like client-side validations, but are actually implemented as AJAX requests to validation functions on the server. This means the potential secretKey value is being transmitted to the server before the form submission that saves it.)
• [ ] Test it in a real Jenkins installation

[chriskilding]

In the Cloudbees AWS Credentials plugin, the accessKey is a String while the secretKey is a Hudson Secret:

https://github.com/jenkinsci/aws-credentials-plugin/blob/cbf183ce58b955f17d93fdc1ac4d19a8ebe693db/src/main/java/com/cloudbees/jenkins/plugins/awscredentials/AWSCredentialsImpl.java

Nobody has yet disputed that, so we should probably follow the convention that has been established there

[chriskilding]

@timja If a plugin author wants a security review of a new feature/bug fix before merging it, is there a particular process to follow for that, or is it just a case of looping in reviewers on the PR like usual?

[timja]

@timja If a plugin author wants a security review of a new feature/bug fix before merging it, is there a particular process to follow for that, or is it just a case of looping in reviewers on the PR like usual?

@jenkinsci/core-security-review might be able to take a look

[timja]

Or asking on the mailing list

[chriskilding]

Requesting a review from @Wadeck @jenkinsci/core-security-review team...

Please could you do a security review of the new feature in this PR, and let me know if it's satisfactory?

As a starter for ten, these are the security questions I can think of that need to be answered:

1. When the 'static' authentication option is chosen, the AWS keypair ends up stored in Jenkins plugin XML configuration on disk. So...
   1. Is the keypair adequately protected within the Jenkins config by Hudson encryption?
   2. Is it okay to have accessKey be a plaintext field and secretKey be a protected field? (I note that this was the approach used by the AWS Credentials type plugin.) Do we foresee any eventuality when the accessKey needs to be hidden too?
2. The Web UI has field validations to ensure that the accessKey and secretKey are not null. Will field validations expose the value of secretKey in an undesirable way? (I note that Jenkins validations look like client-side validations, but are actually implemented as AJAX requests to validation functions on the server. This means that depending on how password fields are transmitted, the potential secretKey value could be transmitted to the server before the form submission that saves it.)

[chriskilding]

Requesting a security review of this feature from @dwnusbaum, as Wadeck seems to be busy

[Kevin-CB]

Is the keypair adequately protected within the Jenkins config by Hudson encryption?

Your secret key will be stored encrypted, see https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials

Is it okay to have accessKey be a plaintext field and secretKey be a protected field? (I note that this was the approach used by the AWS Credentials type plugin.) Do we foresee any eventuality when the accessKey needs to be hidden too?

The accessKey is used for identifying the access key in logs, configuration, and so on. It could in some environments be considered sensitive data if you're looking to not release who accesses which systems and when, but it is not secret. You can find more information in the official docs (https://docs.aws.amazon.com/accounts/latest/reference/credentials-access-keys-best-practices.html)

The Web UI has field validations to ensure that the accessKey and secretKey are not null. Will field validations expose the value of secretKey in an undesirable way?

No, these form validations won't expose your credentials, it's an UI feature to improve user experience, it won't store your credentials anywhere.