On Thu, Sep 19, 2019 at 8:41 AM Jhonny Oliveira <jhonny.olive...@gmail.com>
wrote:

> Dear Mark,
>
> I agree with you, I'm relying on long-lived agents. I read your answer,
> but I'm not understanding your suggestion to use folders, I do not
> comprehend how they can help. I mean, with folders I can avoid cross
> application credential usage and that is great, but I can't prevent cross
> environment credential leakage within the same application.
>
>
My suggestion is

   - Dev-Folder defines a credential (scoped to Dev-Folder) with ID
   'weblogic-deploy-credential-2019-09-19'
      - Job inside Dev-Folder refers to credential
      'weblogic-deploy-credential-2019-09-19 ' and uses it to deploy to dev
   - Test-Folder defines a credential (scoped to Test-Folder) with ID '
   weblogic-deploy-credential-2019-09-19'
      -   Job inside Test-Folder refers to credential
      'weblogic-deploy-credential-2019-09-19 ' and uses it to deploy to test

The same source code can be used for the job inside Dev-Folder and the job
inside Test-Folder if the other things that vary between dev and test are
also parameterized in that job.  In the case you provided, rather than
URL_TST and URL_DEV, you would define a parameter DESTINATION_URL and would
pass in the test value.  The "folder properties" plugin looks like it may
be needed in that case so that each folder can have its own value for the
DESTINATION_URL without requiring that developers pass the parameter to the
job.

If a malicious developer in Dev-Folder modifies their Jenkinsfile to deploy
to test, it will be rejected because the credentials in the Dev-Folder
don't have permission to deploy to test.

If a malicious developer in Dev-Folder modifies their Jenkinsfile to
display the values of the credentials, only the credentials from the
Dev-Folder will be exposed.


> Please have a look at the code snippet below. As you will be able to see,
> with this implementation nothing prevents anyone with access to the source
> code from flipping the IDs around and getting the credentials in the wrong
> environment (mistake or malicious action). Furthermore, and to give a
> little extra context, the Pipeline is completely autonomous and will be
> triggered automatically on every (almost) pull request. It is also smart
> enough to detect a release and proceed towards production (with some
> approvals - of course - to adhere to release management).
>
> In such scenario, and considering that the agents only have access to
> their own environment, the only way to prevent a credential to be used or
> exposed in the wrong one would be to deliberately restrict it to that
> specific agent.
>
> Maybe I'm taking this idea of automation and complete SDLC from source to
> far! :-)
>
> I appreciate your answers, thanks you!
> J. Oliveira
>
> def WLS_CRED_DEV=’111aaa11-a3a1-4aab-9a20-a11666666a80’
> def WLS_CRED_TST=’222aaa11-a3a1-4aab-9a20-a11666666a80 ‘
> (…)
> stage ('Deploy to DEV') {
>             agent { label "${agent_dev}"}
>             steps {
>                         script {
>
> withCredentials([usernamePassword(credentialsId: "$WLS_CRED_DEV",
> usernameVariable: 'WL_USER', passwordVariable: 'WL_PASS')]){
>                                                 sh "mvn -U
> weblogic:redeploy -DskipTests=true -Dfailonerror=true -Duser='${WL_USER}'
> -Dpassword='${WL_PASS}' -Dname=${ARTIFACTID} -Dupload=true
> -Dsource=target/${ARTIFACTID}-${VERSION}.war -Dtargets=${ARTIFACTID}
> -Dadminurl='${URL_DEV}'"
>                                     }
>                         }
>             }
> }
> stage ('Deploy to TST) {
>             agent { label "${agent_tst}"}
>             steps {
>                         script {
>
> withCredentials([usernamePassword(credentialsId: "$WLS_CRED_TST",
> usernameVariable: 'WL_USER', passwordVariable: 'WL_PASS')]){
>                                                 sh "mvn -U
> weblogic:redeploy -DskipTests=true -Dfailonerror=true -Duser='${WL_USER}'
> -Dpassword='${WL_PASS}' -Dname=${ARTIFACTID} -Dupload=true
> -Dsource=target/${ARTIFACTID}-${VERSION}.war -Dtargets=${ARTIFACTID}
> -Dadminurl='${URL_TST}'"
>                                     }
>                         }
>             }
> }
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/ac762c3b-3488-4a4f-a8f5-2408aac38284%40googlegroups.com
> .
>


-- 
Thanks!
Mark Waite

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGpwuUf2yvsE7ztsgmvboBGfwbYPLn4dxDjrXdkUwQ1hQ%40mail.gmail.com.

Reply via email to