Answers: <p>If you use the <a href="https://wiki.jenkins.io/display/JENKINS/Swarm+Plugin" rel="nofollow noreferrer">Self-Organizing Swarm Plug-in</a> to connect your build agents to your master, you can spin agents up/down without having to make any changes on your master. Agents will automatically register themselves with the master. You will have to supply credentials to the agents to self-register. I would suggest using SSM Parameter Store to store them and then retrieve them in userdata.</p>
  
  <p>Your agents can then be completely ephemeral, and updates performed in userdata or by updating the AMI.</p>
  
  <p>See <a href="https://github.com/aarongorka/terraform-aws-jenkins/" rel="nofollow noreferrer">this Terraform module</a> for a more detailed example of implementing this.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-05-21T02:41:51.450Z
Answers: Why use swarm over kubernetes? This plugin is also displaying a vulnerability warning "XXE vulnerability via UDP broadcast response in Swarm client"
Answers: casey vega
Answers: CC BY-SA 4.0
Answers: 2019-05-21T04:51:17.560Z
Answers: The plugin is unrelated to Docker swarm. It can use normal EC2 instances without Docker. AWS does not support broadcast, I wonder if it's not vulnerable in AWS.
Answers: user2640621
Answers: CC BY-SA 4.0
Answers: 2019-05-21T02:13:15.363Z
Answers: 2019-05-21T02:13:15.363Z
Answers: user2640621
Body: <p>I've been working on an automated patching solution for some infrastructure in one of our AWS accounts. This AWS happens to host the Jenkins instance we use for CI/CD actions, among other things. </p>
  
  <p>Our instance runs off AWS EC2 instances and are persistent - basically they live long enough that they would be out of compliance if we never patched them. </p>
  
  <p>I have patched Jenkins slaves manually in the past, where the workflow looked something like this:</p>
  
  <ul>
  <li>Log into Jenkins instance</li>
  <li>Make sure there are no running jobs on the target node</li>
  <li>Mark the target node as offline</li>
  <li>Patch the target node</li>
  <li>Log into Jenkins instance</li>
  <li>Mark the node as online again</li>
  </ul>
  
  <p>This process involves interacting with the Jenkins instance itself. Since I want this solution to be automated, I don't want to have to manually log in and facilitate this process before and after patching. Right now, I have the ability to execute arbitrary bash code from the target node locally and I've been working on a way of using the target node to mark itself offline in some way, and right now my best bet looks like using the environment variables that Jenkins sets while it is running a job to determine whether or not the node is busy. </p>
  
  <p>That will solve the problem of the making sure the node isn't busy, but I have no idea how I will prevent it from accepting new jobs while automation patches the machine. I don't want to use API calls because I believe that would require me to put credentials on all of the Jenkins machines, which I am adverse to doing (Secrets management is a pain). Another possible method could be to prevent the Jenkins master from assigning the slave more tasks by shutting off the slave's SSH, but that sounds like a terrible idea.</p>
  
  <p>Anyone have any ideas as to how I could mark Jenkins slaves offline and online, with my only real tool being local bash execution on the slave itself? </p>
  
Comments: CC BY-SA 4.0
Comments: 2019-05-20T18:18:50.193Z
Comments: Have you thought about using ephemeral agents? Doing so typically eliminates the issue you're describing because the nodes are discarded when not in use. Now you can update the EC2 AMI whenever you want without worrying about agents and it also gives you the flexibility to roll out and back as needed.
Comments: casey vega
Comments: CC BY-SA 4.0
Comments: 2019-05-21T22:58:54.037Z
Comments: Hey casey thanks for responding. Unfortunately, I do not have control of our Jenkins instance. We have planned on building a pipeline for Jenkins instances so we can just kill one and reboot from a fresh patched image but that’s too far down the road to not consider patching now. So to answer, yes I have considered it, but no I do not have the ability to enact that change right now.
Comments: drewto
Tags: <jenkins><amazon-web-services><jenkins-pipeline><operations>
Title: How to automate the process of patching Jenkins Slave instances in AWS
UserDisplayName: drewto
ThreadText: # How to automate the process of patching Jenkins Slave instances in AWS
  
  (Asked by: username_0 on 2019-05-17)
  
  I've been working on an automated patching solution for some infrastructure in one of our AWS accounts. This AWS happens to host the Jenkins instance we use for CI/CD actions, among other things.
  
  Our instance runs off AWS EC2 instances and are persistent - basically they live long enough that they would be out of compliance if we never patched them.
  
  I have patched Jenkins slaves manually in the past, where the workflow looked something like this:
  
  * Log into Jenkins instance
  * Make sure there are no running jobs on the target node
  * Mark the target node as offline
  * Patch the target node
  * Log into Jenkins instance
  * Mark the node as online again
  
  This process involves interacting with the Jenkins instance itself. Since I want this solution to be automated, I don't want to have to manually log in and facilitate this process before and after patching. Right now, I have the ability to execute arbitrary bash code from the target node locally and I've been working on a way of using the target node to mark itself offline in some way, and right now my best bet looks like using the environment variables that Jenkins sets while it is running a job to determine whether or not the node is busy.
  
  That will solve the problem of the making sure the node isn't busy, but I have no idea how I will prevent it from accepting new jobs while automation patches the machine. I don't want to use API calls because I believe that would require me to put credentials on all of the Jenkins machines, which I am adverse to doing (Secrets management is a pain). Another possible method could be to prevent the Jenkins master from assigning the slave more tasks by shutting off the slave's SSH, but that sounds like a terrible idea.
  
  Anyone have any ideas as to how I could mark Jenkins slaves offline and online, with my only real tool being local bash execution on the slave itself?
  
  **Tags:** jenkins, amazon-web-services, jenkins-pipeline, operations
  
  > **Comments:**
  > **username_1**: Have you thought about using ephemeral agents? Doing so typically eliminates the issue you're describing because the nodes are discarded when not in use. Now you can update the EC2 AMI whenever you want without worrying about agents and it also gives you the flexibility to roll out and back as needed.  
  > **username_0**: Hey username_1 thanks for responding. Unfortunately, I do not have control of our Jenkins instance. We have planned on building a pipeline for Jenkins instances so we can just kill one and reboot from a fresh patched image but that’s too far down the road to not consider patching now. So to answer, yes I have considered it, but no I do not have the ability to enact that change right now.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-05-21. Score: 1
  
  If you use the [Self-Organizing Swarm Plug-in](https://wiki.jenkins.io/display/JENKINS/Swarm+Plugin) to connect your build agents to your master, you can spin agents up/down without having to make any changes on your master. Agents will automatically register themselves with the master. You will have to supply credentials to the agents to self-register. I would suggest using SSM Parameter Store to store them and then retrieve them in userdata.
  
  Your agents can then be completely ephemeral, and updates performed in userdata or by updating the AMI.
  
  See [this Terraform module](https://github.com/aarongorka/terraform-aws-jenkins/) for a more detailed example of implementing this.
  
  > **Comments:**
  > **username_1**: Why use swarm over kubernetes? This plugin is also displaying a vulnerability warning "XXE vulnerability via UDP broadcast response in Swarm client"  
  > **username_2**: The plugin is unrelated to Docker swarm. It can use normal EC2 instances without Docker. AWS does not support broadcast, I wonder if it's not vulnerable in AWS.  
  
  ---
  
  