Re: Stop logged in users from cancelling a queued job

[Diego Kober]

On my setup here, our users authenticate on Jenkins using AD, and i use the 
Role 
Strategy Plugin 
 to manage 
what each user can or can't do.
Follow this helpful link i've used, when first setting this 
up: 
https://medium.com/modern-stack/implementing-active-directory-based-security-in-jenkins-f78dbac929de


On Friday, May 17, 2019 at 9:59:28 AM UTC-3, Mahendra Tripathi wrote:
>
> Hi,
>
> I am able to see that one of my authenticated use(don't know which one) 
> kills the jobs in my Jenkins queue.
> I wanted to know if I can either get the system from which this request 
> was made IP or hostname or
> if I can stop the user from doing so altogether.
>
> I need urgent help on this.
>
> regards,
> Mahendra
>

-- 
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/a86d919d-88bf-43fb-b5ac-c9030f78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Stop logged in users from cancelling a queued job

[Mahendra Tripathi]

Hi,

I am able to see that one of my authenticated use(don't know which one) 
kills the jobs in my Jenkins queue.
I wanted to know if I can either get the system from which this request was 
made IP or hostname or
if I can stop the user from doing so altogether.

I need urgent help on this.

regards,
Mahendra

-- 
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/25b04a51-6aae-4272-ae5a-e0b5223383e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: node parameter makes pipeline fail even if it's unused

[Mark Waite]

I failed to mention that performing git operations over NFS is much slower
than performance those operations with a local file system.  I'd generally
recommend that file systems on static agents should be locally attached
file systems rather than network file systems if possible.

On Fri, May 17, 2019 at 4:59 AM Mark Waite 
wrote:

>
>
> On Thu, May 16, 2019 at 7:13 AM gbon  wrote:
>
>> Hi All,
>> Asking for advice on this weird behavior:
>>
>> I have a (declarative) pipeline that works perfectly fine and selects the
>> agent like so
>>
>> pipeline {
>>   agent {
>> node {
>>   label "SOME_LABEL"
>> }
>>   }
>>   ...
>> }
>>
>> If I edit the pipeline configuration to add a parameter of type Node (
>> which I'm still not using in the pipeline! )  the pipeline fails
>> immediately with the following error
>>
>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>> --progress g...@my-super-secret-gitlab-repository.git 
>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>> stdout:
>> stderr: Could not create directory '/export/homes/my_user/.ssh'.
>> Host key verification failed.
>> fatal: Could not read from remote repository.
>>
>>
>>
>> That I think has nothing to do with git since it works perfectly fine and
>> the label is still hardcoded.
>> Seems like the job isn't correctly dispatched or something but I can't
>> figure out what's happening.
>>
>>
> The declarative Pipeline includes an implicit checkout of the repository
> on each agent that will be performing a step.  When you add the `node`
> step, declarative Pipeline attempts to perform a checkout on that node.  If
> you don't need that default checkout, the `skipDefaultCheckout` option is
> available.
>
> If you need that default checkout, then you probably need to fix the file
> system permissions of the /export/homes/my_user/.ssh directory so that the
> user executing the Pipeline job can read the .$HOME/.ssh directory.
> Command line git uses `ssh` to authenticate and clone repositories using
> the secure shell protocol.
>
> If the `/export/homes/my_user` directory is accessed over NFS, then you
> may also need to assure that the agent process is not running as root. Root
> access over NFS is usually not allowed.
>
> You could check for those types of conditions in your environment with a
> Jenkinsfile something like this:
>
> pipeline {
>   options {
> skipDefaultCheckout()
>   }
>   agent {
> node {
>   label "!windows"
> }
>   }
>   stages {
> stage('Report username') {
>   steps {
> sh 'id'
>   }
> }
>   }
> }
>
>
>
>> Thanks!
>>
>> --
>> 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/0f7c8c1c-c1a8-4495-8be5-d00b5c5997ff%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Thanks!
> Mark Waite
>


-- 
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/CAO49JtGDDQkNQ72h5VyzhRO2_2GYfimE%3Da8UdVDo4aLW%3Di8yjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: node parameter makes pipeline fail even if it's unused

[Mark Waite]

On Thu, May 16, 2019 at 7:13 AM gbon  wrote:

> Hi All,
> Asking for advice on this weird behavior:
>
> I have a (declarative) pipeline that works perfectly fine and selects the
> agent like so
>
> pipeline {
>   agent {
> node {
>   label "SOME_LABEL"
> }
>   }
>   ...
> }
>
> If I edit the pipeline configuration to add a parameter of type Node (
> which I'm still not using in the pipeline! )  the pipeline fails
> immediately with the following error
>
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
> --progress g...@my-super-secret-gitlab-repository.git 
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> stdout:
> stderr: Could not create directory '/export/homes/my_user/.ssh'.
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
>
> That I think has nothing to do with git since it works perfectly fine and
> the label is still hardcoded.
> Seems like the job isn't correctly dispatched or something but I can't
> figure out what's happening.
>
>
The declarative Pipeline includes an implicit checkout of the repository on
each agent that will be performing a step.  When you add the `node` step,
declarative Pipeline attempts to perform a checkout on that node.  If you
don't need that default checkout, the `skipDefaultCheckout` option is
available.

If you need that default checkout, then you probably need to fix the file
system permissions of the /export/homes/my_user/.ssh directory so that the
user executing the Pipeline job can read the .$HOME/.ssh directory.
Command line git uses `ssh` to authenticate and clone repositories using
the secure shell protocol.

If the `/export/homes/my_user` directory is accessed over NFS, then you may
also need to assure that the agent process is not running as root. Root
access over NFS is usually not allowed.

You could check for those types of conditions in your environment with a
Jenkinsfile something like this:

pipeline {
  options {
skipDefaultCheckout()
  }
  agent {
node {
  label "!windows"
}
  }
  stages {
stage('Report username') {
  steps {
sh 'id'
  }
}
  }
}



> Thanks!
>
> --
> 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/0f7c8c1c-c1a8-4495-8be5-d00b5c5997ff%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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/CAO49JtFqxh-mHCxnLK_Rs-3WgXVkZWR8urCnPQ3k52pVDyzLRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Securing build scripts when building pull requests

[Mark Waite]

The pipeline library on ci.jenkins.io is a good example of a library
written to safely handle pull requests which might be malicious.  Refer to
isTrusted

and how it is used to safeguard operations.

I believe ci.jenkins.io jobs are also configured to not allow Jenkinsfile
to be used from the target branch even for pull requests.  That avoids the
risk of a pull request submitted which executes a malicious Jenkinsfile.

On Fri, May 17, 2019 at 1:03 AM Simon Richter 
wrote:

> Hi,
>
> On Thu, May 16, 2019 at 12:11:54PM -0700, Christopher Weaver wrote:
>
> > For a project I work on, we have set up Jenkins, using the GitHub Branch
> > Source Plugin, to do automatic builds for pushes to our repository,
> > including test builds for pull requests. This is all working, but I am
> > concerned about the security implications for the pull requests.
>
> Yes, that is a common problem. Most people either only test pull requests
> from trusted people, or configure Jenkins to test inside a container with
> no network access and strict resource limits that is discarded after the
> build.
>
>Simon
>
> --
> 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/20190517080348.GA17598%40psi5.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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/CAO49JtHAT5tbH9%3Df%2BZEYJ%3DsO-6RisYM0spTQH9PKgu31WMCpmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Securing build scripts when building pull requests

[Simon Richter]

Hi,

On Thu, May 16, 2019 at 12:11:54PM -0700, Christopher Weaver wrote:

> For a project I work on, we have set up Jenkins, using the GitHub Branch 
> Source Plugin, to do automatic builds for pushes to our repository, 
> including test builds for pull requests. This is all working, but I am 
> concerned about the security implications for the pull requests.

Yes, that is a common problem. Most people either only test pull requests
from trusted people, or configure Jenkins to test inside a container with
no network access and strict resource limits that is discarded after the
build.

   Simon

-- 
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/20190517080348.GA17598%40psi5.com.
For more options, visit https://groups.google.com/d/optout.