Restrict credential retrieval to a specific slave
19 views
Skip to first unread message
Jhonny Oliveira
Sep 19, 2019, 6:21:07 AM9/19/19
to Jenkins Users
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
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
Mark Waite
Sep 19, 2019, 6:36:30 AM9/19/19
to Jenkins Users
On Thu, Sep 19, 2019 at 4:21 AM Jhonny Oliveira <jhonny....@gmail.com> 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-use...@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
Message has been deleted
Jhonny Oliveira
Sep 19, 2019, 8:29:54 AM9/19/19
to Jenkins Users
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?
Dirk Heinrichs
Sep 19, 2019, 8:32:13 AM9/19/19
to jenkins...@googlegroups.com
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: dhei...@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.
Mark Waite
Sep 19, 2019, 9:37:57 AM9/19/19
to Jenkins Users
On Thu, Sep 19, 2019 at 6:30 AM Jhonny Oliveira <jhonny....@gmail.com> 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-use...@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
Jhonny Oliveira
Sep 19, 2019, 10:41:20 AM9/19/19
to Jenkins Users
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-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}'"
}
}
}
}
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-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}'"
}
}
}
}
Mark Waite
Sep 19, 2019, 12:12:01 PM9/19/19
to Jenkins Users
On Thu, Sep 19, 2019 at 8:41 AM Jhonny Oliveira <jhonny....@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-use...@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
Jhonny Oliveira
Sep 20, 2019, 9:07:27 AM9/20/19
to Jenkins Users
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
Pietro Giannini
Oct 9, 2019, 4:55:16 AM10/9/19
to Jenkins Users
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
Mark Waite
Oct 9, 2019, 2:46:10 PM10/9/19
to Jenkins Users
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).
--
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-use...@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
Reply all
Reply to author
Forward
0 new messages