[JIRA] (JENKINS-58339) Support new types of credentials

[chris+jenk...@chriskilding.com (JIRA)]

Title: Message Title

Chris Kilding edited a comment on JENKINS-58339   Re: Support new types of credentials Hi Enrique, Ah yes, I had overlooked that some plugins might only be able to handle certain credential types. The weight of legacy I suppose. I’m thinking of a way of supporting multiple credential types that would at least keep the important part of the credential (the Secret) compatible with non-Jenkins apps like it is today. Something like the following: * The secretString remains like it is now - a simple string (or byte array). Not JSON. * The extra fields (eg username for SSH key or X509 cert) are added as tags on the AWS Secret. This is fine, because most of those extra fields should be non-secret anyway. * The only secret extra field I’m aware of is a passphrase on a private key or cert. This, however, is only really relevant for local on-disk credentials stores - in a remote store like Secrets Manager the passphrase loses its protective power, as it would have to be stored inside... the key it’s protecting, so if an attacker got the key out of SM then they’d have got the passphrase with it. Therefore we’d just populate the passphrase field of the Credential constructor with blank or null. * When a Secret is loaded we determine the type by parsing the secretString and tags, maybe with a chain pattern or ADT: If the secretString contains the SSH ASCII armor construct an SSH key credential (get username from tags), if it contains the X509 header etc then construct a client cert credential (get username from tags), and so on. With this approach, the core bit of the Secret is still readable by any application using Secrets Manager (not just Jenkins), but the extra non-secret bits can be stored there for Jenkins’ sake. And we don’t need an artificial ‘type’ field/string to be stored either - the chain decoder doesn’t need it. Off the top of my head this should work for: * Secret text (there’s no extra fields to store) * SSH key (secretString format test + AWS tags) * Client cert (secretString format test + AWS tags) * Username / password (if doesn’t pass any secretString format tests, and there’s a username field in the AWS tags then it’s a username / password pair) Thoughts? (This is only a first take on the idea, and there might be other credentials types that I’ve overlooked.) Add Comment   This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200452.1562229894000.607.1564047360522%40Atlassian.JIRA.