There are a suite of new generic HTTP connectors

[izgeri]

We currently have a directory for example generic HTTP connector configurations. In this epic, we will create many more.

Our goal is to demonstrate how easy it is to add support for new HTTP-based target services using the generic HTTP connector. You don't even have to write a new Secretless connector! You just structure your configuration so that Secretless knows where to inject the credentials your target service needs, and you can connect to your target service via Secretless with no code changes.

New generic HTTP connector configs to create:

• [x] Splunk - #1172
• [x] Oauth2 - #328 (TBD if this is possible)
• [ ] Google
  • [x] Google Maps - #1259
  • [x] Google Maps Geocoding
  • [ ] Google Cloud - #1262
• [x] JFrog Artifactory - #1263
• [x] Twitter - #1264
• [x] Facebook - #1265
• [x] Dropbox - #1266
• [x] Stripe - #1267
• [x] Twilio - #1268
• [x] Mailchimp - #1269
• [x] SendGrid - #1270
• [x] Slack - #1258
• [x] Docker
  • [x] Private Docker registries - #1271
• [x] Datadog - #1272
• [x] Sentry - #1273
• [x] New Relic - #1274
• [x] Loggly - #1275
• [x] Papertrail - #1276
• [x] Logentries - #1277
• [x] Tableau - #1278
• [ ] Jenkins -
• [ ] Circle CI
• [ ] Travis CI
• [ ] GitLab
• [ ] CyberArk APIs (see https://cybr.rocks/RESTAPI)
  • [ ] PVWA
  • [ ] PAS REST API
  • [ ] Privilege Cloud API
  • [ ] Alero API
  • [ ] EPM API
• [ ] Mattermost
• [ ] SonarQube Web
• [ ] Heroku -
• [ ] Rancher
• [ ] IBM Watson
• [ ] Kubernetes - #1279
• [ ] OpenShift

Notes

• Until work starts on an issue, there will be a TODO in the implementation plan where the engineer who pulls the card will review the target service and determine which authentication methods (if any) may be feasible to implement with the Secretless generic HTTP connector
• Not all targets in the list above may be possible to implement with the generic HTTP connector.
  • If the engineer reviews the authentication modes of the target service and it's not a good fit for the generic HTTP connector, they'll add notes on the card explaining what's missing.
  • If it looks like adding new functionality to the generic HTTP connector would enable support for the target service, that info will also be added to the card. For example, the Google Maps API supports adding the API key in the URL as a query parameter. At current the generic HTTP connector only supports adding headers, but we could look into adding support for appending query parameters as well.
• When the engineer creates the generic connector config for the target service, they'll validate it in a local environment. The README in the example dir will provide general high-level instructions for using Secretless with the target, but the pull request that adds the example will have detailed instructions for how the developer demonstrated that the connector works (locally or using their development accounts).

[boazmichaely]

A question came from a customer today asking if we support HTTPS or just HTTP. There are no stupid questions.. The answer was "yes and here is the link to the https documentation" So let's make it obvious that HTTPS is supported across the list and in the end blog

[boazmichaely]

For all the use cases, a real life example would be far more powerful than "I'm a developer who needs to connect my app to target X". Trying to find out these real life examples can lead us to real people who would want to try it out

[izgeri]

Added https://github.com/cyberark/secretless-broker/issues/1286 to reorganize the example dir README

[JakeQuilty]

Updated @izgeri comment to a list to keep track of which ones we've done