[Jenkins-infra] Per-plugin processes on ci.j.io

[R. Tyler Croy]

(replies inline)

On Tue, 20 Mar 2018, Daniel Beck wrote:

> Here's the problem: It's unclear to me how to properly implement this on ci.j.io. We have a CI setup there we _could_ reuse to generate some metadata (Jenkinsfiles with buildPlugin() from jenkins-infra/pipeline-library), but these plugins are in the minority -- and having specific metadata about plugins tied to the presence of a specific CI build seems unnecessarily restrictive. Additionally, the security model for ci.j.io wouldn't like the presence of credentials, even if just for the reports.j.io host.


So there are two problems, which we can address separately:

  1) Generating data for plugins which are not otherwise presently build in
     ci.jenkins.io

  2) Securely publishing/deploying user-visible content/data from ci.jenkins.io


I'll leave the first problem aside for now, and focus on the second. For the
context of this list, the current architectural design of ci.jenkins.io is such
that no "deployment" credentials are hosted in ci.jenkins.io where a
sufficiently clever, or sufficiently incompetent, Jenkinsfile contributor could
disclose credentials in the console log, or via archived artifacts. There are
however some folder-scoped credentials to the Infra folder which do have an
elevated level of trust, which is why everybody isn't accepted into that
organization :)

When we discussed this problem in the Infra weekly sync (Mondays at 19:30 UTC)
the concerns to address are:

  A) Disclosure of credentials results in abuse by a third party
  B) Usage of credentials allows forging data published, e.g. publishing an
     invalid/misleading report JSON file

Per olblak's suggestion, A could be reasonably solved with one-time or rapidly
expiring credentials, which might be feasible via the Azure Credentials plugin.

The other concern, B, requires some more research into what level of "binding"
we might be able to do with credentials in Pipelines.


Without investing significant time in "enhancing the security profile of
Jenkins Pipeline" in which the Pipeline team doesn't seem very interested, I
think our only reasonable approach to take is to use the Configuration as Code
plugin combined with the Job DSL plugin to create a series of
infrastructure-managed Pipelines in a separate folder, with folder-scoped
credentials, for performing these kinds of behaviors.


Of course, this doesn't solve the general problem, which is also going to affect
Jenkins Essentials, of publishing content from ci.jenkins.io/job/Plugins/, but
it would unblock your work Daniel :-/



This is my thinking on the problem thus far, I'm hoping that Andrew or somebody
else has a bright idea for how to more securely publish content from untrusted
Pipelines.


Cheers
- R. Tyler Croy

------------------------------------------------------
     Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>
     xmpp: rtyler at jabber.org

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.jenkins-ci.org/pipermail/jenkins-infra/attachments/20180321/5d843036/attachment.asc>