[QA] Keeping secrets safe on Jenkins

Wed Aug 12 19:09:33 UTC 2015

Hey Chris! I'm happy to clarify our use cases. Is there something specific
I can detail?

We do have a private instance currently but do use JJB
(integration/config)[0]. Do we have any private instances at WMF? This
might be simplest and most secure.

--stephen

[0] We'll soon be running tests too
https://gerrit.wikimedia.org/r/#/c/230260/

On Wed, Aug 12, 2015 at 11:33 AM, Chris Steipp <csteipp at wikimedia.org>
wrote:

> Hi Michael / Stephen,
>
> Off the top of my head, I believe hashar setup something on our current
> Jenkins instance to handle passwords. But nothing extreemly secret goes
> there.
>
> There are a number of things we can do to mitigate common attacks. Let's
> chat about the particular needs and some possible countermeasures we can
> put into place.
>
> For background, is your team running its own jenkins instance currently?
>
>
> On Wed, Aug 12, 2015 at 7:54 AM, Michael Holloway <mholloway at wikimedia.org
> > wrote:
>
>> (adding the security team)
>>
>> On Tue, Aug 11, 2015 at 6:54 PM, Stephen Niedzielski <
>> sniedzielski at wikimedia.org> wrote:
>>
>>>   Hello all! I have one question: what is the recommend way to keep
>>> files, such as a Java keystore, safe on a WMF Jenkins machine?
>>>
>>>   The Android team is trying to automate as much as possible, especially
>>> when it comes to releasing software. Our reasons aren't novel: manual
>>> releases are time consuming, we worry about unintentionally shipping bad
>>> bits, and we don't like doing it. One thing that's been blocking this
>>> effort is a security concern over exposing confidential information, such
>>> as signing certificates, login credentials, certain lists of strings, etc,
>>> on a Jenkins server.
>>>
>>>   It might be helpful to describe some of our concrete use cases. I know
>>> them currently as:
>>>
>>>   1 Sign public jars with a private GnuPG key.
>>>   2 Upload public jars to OSSRH with private credentials (currently
>>> stored in a Gradle properties file but could be supplied on the command
>>> line).
>>>   3 Sign public Android apps with a private Java keystore.
>>>
>>>   Our future use cases are likely to include:
>>>
>>>   4 Supply a private list of strings to generate private Android apps.
>>>   5 Upload private and public Android apps to Google Drive (via
>>> gdrive[0], requires a private app token).
>>>   6 Upload public Android apps to the Google Play Developer Console
>>> (TBD, likely requires a private app token).
>>>   7 Upload public Android apps to the Amazon Appstore Developer
>>> Portal (TBD, likely requires a private app token).
>>>   8 Upload public Android apps to Caesium (via SCP).
>>>   9 Update public release notes to a public MediaWiki installation.
>>>   10 Publish public release notes to a mailing list.
>>>
>>>   We currently do all of this on our local dev machines and it's a bit
>>> scary. While generating the jars and apps on a build server as unsigned
>>> artifacts would be a big win in itself, there would still be a significant
>>> and error prone amount of signing and publishing we'd also prefer to live
>>> in a controlled, reproducible environment.
>>>
>>>   For simple strings, the Jenkins Mask Passwords Plugin[1] seems
>>> promising, and even supported by Jenkins Job Builder[2]. What's not clear
>>> is how to land files like our Java keystore and GnuPG keys on the server
>>> securely. It's also not clear how we can guard our private Android app
>>> artifacts mentioned in #4.
>>>
>>>   In summary, we want to automate build and release and we want to keep
>>> our private inputs and outputs secure. Surely other teams in the foundation
>>> must have the same or very similar problems. What is the best reference
>>> implementation?
>>>
>>>   Thank you for reading!
>>>
>>>
>>> --stephen
>>>
>>> [0] https://github.com/prasmussen/gdrive
>>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Mask+Passwords+Plugin
>>> [2]
>>> http://docs.openstack.org/infra/jenkins-job-builder/wrappers.html#wrappers.mask-passwords
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "android" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to android+unsubscribe at wikimedia.org.
>>> To post to this group, send email to android at wikimedia.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/wikimedia.org/d/msgid/android/CANMtf2cEOHTPiYtPyvTO3Z0TipO6eHBrE%3Ds6q3HGKaFb0ki8TA%40mail.gmail.com
>>> <https://groups.google.com/a/wikimedia.org/d/msgid/android/CANMtf2cEOHTPiYtPyvTO3Z0TipO6eHBrE%3Ds6q3HGKaFb0ki8TA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/qa/attachments/20150812/def060fb/attachment-0001.html>