subject:"Restrict credential retrieval to a specific slave"

Re: Restrict credential retrieval to a specific slave

2019-10-09 Thread Mark Waite

I am not aware of anyone working to allow credentials to be limited to an
agent.  I believe the same capabilities are available by assigning the
credentials to folders and then limiting user access to specific folders.
Choose a credential name that should be the same in several different
folders, then define the credential with the value specific to the folder
that is using it.

The test jobs would reside in a "Test-Folder" and refer to a credential
named 'credential-2019-10-10'.  In that folder, the value of the credential
should be chosen so that it only allows access to things related to test.

The development jobs would reside in a "Development-Folder" and refer to a
credential named 'credential-2019-10-10'.  In that folder, the value of the
credential should be chosen so that it only allows access to things related
to development.

The jobs reference the same credential but since the credentials are
defined inside the folder, they are only accessible to jobs in that folder
(and below).

On Wed, Oct 9, 2019 at 12:55 AM Pietro Giannini  wrote:

> Hi!
>
> I just came across this post and realized this is exactly what we need. We
> are heavily using pipelines at our agency and being able to restrict
> credentials to a specific node would enable us to give total freedom the
> developers while keeping control of the passwords at infra level.
>
> Is there any chance we could get this feature onboard?
>
> Br,
> Pietro
>
>
>
> On Friday, September 20, 2019 at 3:07:27 PM UTC+2, Jhonny Oliveira wrote:
>>
>> Dear Mark,
>>
>> I understand your suggestion, however in such case you would have to
>> create multiple jobs, whereas, as it is right now, I only need one. No
>> parameters, no additional settings just the minimal configuration to pick
>> up the changes, build, test and deploy. I even get for free all the
>> statistics together.
>>
>> Nevertheless, I will try to come with an alternative solution. I believe
>> your input may be valuable in there.
>>
>> Thank you very much,
>> J Oliveira
>>
>> --
> 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/25d0de20-d7c4-4336-8645-d6302768d2db%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/CAO49JtFkgNGtp5KeMTC5aKtSBcDB8QmHkypF1DzfeFj39Vg_Qw%40mail.gmail.com.

Re: Restrict credential retrieval to a specific slave

2019-10-09 Thread Pietro Giannini

Hi!

I just came across this post and realized this is exactly what we need. We 
are heavily using pipelines at our agency and being able to restrict 
credentials to a specific node would enable us to give total freedom the 
developers while keeping control of the passwords at infra level.

Is there any chance we could get this feature onboard?

Br,
Pietro



On Friday, September 20, 2019 at 3:07:27 PM UTC+2, Jhonny Oliveira wrote:
>
> Dear Mark,
>
> I understand your suggestion, however in such case you would have to 
> create multiple jobs, whereas, as it is right now, I only need one. No 
> parameters, no additional settings just the minimal configuration to pick 
> up the changes, build, test and deploy. I even get for free all the 
> statistics together.
>
> Nevertheless, I will try to come with an alternative solution. I believe 
> your input may be valuable in there.
>
> Thank you very much,
> J Oliveira
>
>

-- 
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/25d0de20-d7c4-4336-8645-d6302768d2db%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

2019-09-20 Thread Jhonny Oliveira

Dear Mark,

I understand your suggestion, however in such case you would have to create 
multiple jobs, whereas, as it is right now, I only need one. No parameters, no 
additional settings just the minimal configuration to pick up the changes, 
build, test and deploy. I even get for free all the statistics together.

Nevertheless, I will try to come with an alternative solution. I believe your 
input may be valuable in there.

Thank you very much,
J Oliveira

-- 
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/ad651eb7-b8c1-4451-b92d-11bfe9dee911%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Mark Waite

On Thu, Sep 19, 2019 at 8:41 AM Jhonny Oliveira 
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-a1166a80’
> def WLS_CRED_TST=’222aaa11-a3a1-4aab-9a20-a1166a80 ‘
> (…)
> 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%

Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Jhonny Oliveira

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.

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-a1166a80’
def WLS_CRED_TST=’222aaa11-a3a1-4aab-9a20-a1166a80 ‘
(…)
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.

Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Mark Waite

On Thu, Sep 19, 2019 at 6:30 AM Jhonny Oliveira 
wrote:

> The idea is to have a self contained application (as in source repo),
> where you have everything you need to maintain its SDLC: source, build,
> tests (unit, regression, ...), continuous integration/automation
> (Jenkinsfile).
>
> The Jenkinsfile should be part of the source code and cover the entire
> process (end to end). Breaking it into pieces kind of defeats our main
> purpose of having everyone working together in the same source (developers,
> testers, operations, ...).
>
>
Yes, that's the right way to do it.  You've described the storage of the
definition of the application very well.  Keep it all in source code and
run it from source.

Place the limited use credential on a folder in Jenkins, then control who
is allowed to access that folder.  The jobs inside the folder will be able
to use the credential.  Jobs outside the folder won't have access to the
credential.

> Is there any chance such feature could be included in future releases? To
> whom can I address this question?
>
>
This is the right place to address the question.

I'm not aware of anyone working to add credentials to agents.  Since agents
are treated more and more as ephemeral workers that are exist only long
enough to perform their task and are then discarded, it seems unlikely that
anyone would add credential storage to agents.

There are still plenty of cases where agents live a long time (as in your
case), but Jenkins work now needs to consider both long-lived agents and
ephemeral agents.  Most capabilities that are being added are done so that
they can be used with all types of agents.

> --
> 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/fca0f38f-1b9a-4843-8572-fb77dc716aa7%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/CAO49JtFWwo4vp2sHhF5Og-N%2Bt4FoH6QaGNF%3DoCGuZsCE_0QUYg%40mail.gmail.com.

Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Dirk Heinrichs

Am Donnerstag, den 19.09.2019, 05:26 -0700 schrieb Jhonny Oliveira:

What do you mean with agents?

Jenkins people have stopped using the word "slave" some time ago.

Bye...

Dirk

Dirk Heinrichs
Senior Systems Engineer, Delivery Pipeline
OpenText ™ Discovery | Recommind
Phone: +49 2226 15966 18
Email: dhein...@opentext.com
Website: www.recommind.de
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht
gestattet.

--
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/935083deb1d09f9bca2fb321c9a9e5be49b341c6.camel%40opentext.com.

Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Jhonny Oliveira

The idea is to have a self contained application (as in source repo), where you 
have everything you need to maintain its SDLC: source, build, tests (unit, 
regression, ...), continuous integration/automation (Jenkinsfile).

The Jenkinsfile should be part of the source code and cover the entire process 
(end to end). Breaking it into pieces kind of defeats our main purpose of 
having everyone working together in the same source (developers, testers, 
operations, ...).

Is there any chance such feature could be included in future releases? To whom 
can I address this question?

-- 
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/fca0f38f-1b9a-4843-8572-fb77dc716aa7%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Jhonny Oliveira

What do you mean with agents?

The idea is to have a self contained application (as in source repo), where you 
have everything you need to maintain its SDLC: source, build, tests (unit, 
regression, ...), continuous integration/automation (Jenkinsfile). The 
Jenkinsfile should be part of the source code and cover the entire process (end 
to end). Breaking it into pieces kind of defeats our main purpose of having 
everyone working together in the same source (developers, testers, operations).

-- 
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/8f589383-dfca-40d5-b5ef-1296997bf006%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Mark Waite

On Thu, Sep 19, 2019 at 4:21 AM Jhonny Oliveira 
wrote:

> Hi!
>
> is it possible to limit the usage of a credential to a specific slave?
>

Not with Jenkins as far as I know.  Credentials can be defined on the
Jenkins master, on folders, and on multibranch Pipelines.  They can't be
defined on Freestyle jobs or on agents.


> With this restriction, I could fully empower developers to create their
> own Pipelines (Jenkinsfile) while avoiding passwords to be leaked in the
> wrong slaves/environments.
>

Could you attach the credentials to a folder and then limit access to the
folders instead?  Those with access to the folder can use the credential
attached to that folder.  Those without access to the folder could not use
that credential.


>
> Just for further context, in my scenario and at infrastructure level, only
> specific slaves are allowed to deploy to specific environments. E.g.:
> dev_slave -> deploy to DEV; tst_slave -> deploy to TST and so on.
>
> Cheers,
> Jhonny Oliveira
>
> --
> 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/2540cf8f-0413-4ec1-ae4a-136f2eeaf894%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/CAO49JtFCvn4k-DW%2BY5ew30bLAhaNBc-UHgaFx6dDTn17qAoyRQ%40mail.gmail.com.

Restrict credential retrieval to a specific slave

2019-09-19 Thread Jhonny Oliveira

Hi!

is it possible to limit the usage of a credential to a specific slave?

With this restriction, I could fully empower developers to create their own 
Pipelines (Jenkinsfile) while avoiding passwords to be leaked in the wrong 
slaves/environments.

Just for further context, in my scenario and at infrastructure level, only 
specific slaves are allowed to deploy to specific environments. E.g.: dev_slave 
-> deploy to DEV; tst_slave -> deploy to TST and so on.

Cheers,
Jhonny Oliveira

-- 
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/2540cf8f-0413-4ec1-ae4a-136f2eeaf894%40googlegroups.com.

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Re: Restrict credential retrieval to a specific slave

Restrict credential retrieval to a specific slave

11 matches

Site Navigation

Mail list logo

Footer information