[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI

8 Feb 2018

      This is a multi-part message in MIME format...

------------=_1518096517-16706-206
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

    [ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35768#comment-35768 ] 

Barak Korren commented on OVIRT-1867:
-------------------------------------

Here is an implementation scheme that can meet [~rmohr@redhat.com]'s UX requirements while still allowing STDCI projects to be portable between CI systems.

First, we adopt or setup an online credentials storage service that has the following features:
# It has a UI where users can login and upload or download credentials
# It has functionality where it can generate key pairs while storing the private key and making the public key visible.
# It supports a oAuth-like flow where a system can request access to certain credentials and the user can confirm or deny it.

Second, we write a secrets provider that allows the user to refer to a set of credentials in the service above (As well as the service itself). When trying to provide the secrets, the system would request access via the credentials storage service.

Third, we write an STDCI service that encapsulates the special-case flow where we get a private key from the secrets provider and use it tio decrypt files from the Git repo.
...
Allow embedded secrets inside the source repo for CI
----------------------------------------------------
Key: OVIRT-1867
                URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867
            Project: oVirt - virtualization made easy
         Issue Type: New Feature
         Components: Standard CI (Pipelines), STDCI DSL
           Reporter: Roman Mohr
           Assignee: infra
             Labels: credentials
In order to improve the self-service capabilities of standard-ci it is
important for projects, that they can add their own secrets to projects (to
reach external services, e.g. docker hub, ...).
Travis has a very nice system which helps engineers there:
https://docs.travis-ci.com/user/encryption-keys/
Basically the CI system needs to generate a public/private key pair for
every enabled git repo. The engineer simply fetches the public key via a
well know URL and encrypts the secrets. Then the encrypted secret can be
made part of the source repo. Before the tests are run the CI system
decrypts the secrets. Than can play together pretty well with Jenkinsfiles
too.
Benefit:
 * Less manual intervention from CI team to add secrets to jobs
 * Strengthen the config-in-code thinking
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100079)

------------=_1518096517-16706-206
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

<html><body>
<pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.p... ]</pre>
<h3>Barak Korren commented on OVIRT-1867:</h3>
<p>Here is an implementation scheme that can meet [~rmohr@redhat.com]'s UX requirements while still allowing STDCI projects to be portable between CI systems.</p>
<p>First, we adopt or setup an online credentials storage service that has the following features: # It has a UI where users can login and upload or download credentials # It has functionality where it can generate key pairs while storing the private key and making the public key visible. # It supports a oAuth-like flow where a system can request access to certain credentials and the user can confirm or deny it.</p>
<p>Second, we write a secrets provider that allows the user to refer to a set of credentials in the service above (As well as the service itself). When trying to provide the secrets, the system would request access via the credentials storage service.</p>
<p>Third, we write an STDCI service that encapsulates the special-case flow where we get a private key from the secrets provider and use it tio decrypt files from the Git repo.</p>
<blockquote><h3>Allow embedded secrets inside the source repo for CI</h3>
<pre>     Key: OVIRT-1867
     URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867
 Project: oVirt - virtualization made easy
         Issue Type: New Feature
         Components: Standard CI (Pipelines), STDCI DSL
Reporter: Roman Mohr
Assignee: infra
  Labels: credentials</pre>
<p>In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …). Travis has a very nice system which helps engineers there: <a href="https://docs.travis-ci.com/user/encryption-keys/">https://docs.travis-ci.com/user/encryption-keys/</a> Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit:</p>
<pre>* Less manual intervention from CI team to add secrets to jobs
* Strengthen the config-in-code thinking</pre></blockquote>
<p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100079)</p>

<img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3t..." alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>

------------=_1518096517-16706-206--

Barak Korren (oVirt JIRA)

tags

participants (1)