Answers: <p>The same rules apply to hardening Jenkins as for all other web applications:</p>
  
  <ul>
  <li>Put sensitive content behind an authentication/authorization barrier</li>
  <li>Use SSL for transport-layer encryption and verifying the identity of the server</li>
  <li>Restrict network-level access to only networks where clients should be connection from</li>
  </ul>
  
  <p>Regarding client authn/authz - that's pretty straightforward; there are lots of options with Jenkins for that.  I use a plugin that hooks into my org's Active Directory instance, for example.</p>
  
  <p>Regarding SSL - while it is possible to configure Jenkins to serve content over HTTPS rather than HTTP (<a href="https://wiki.jenkins.io/display/JENKINS/Starting+and+Accessing+Jenkins" rel="nofollow noreferrer">documentation here</a>), I don't find that to be the easiest way to configure SSL.  I think using a reverse proxy like you mentioned is a better choice.  Nginx and Apache are the two popular options here.  Some reasons for choosing one of these reverse proxies: can take advantage of existing tooling/resources for configuration and certificate management; easier and more flexible to configure to allow for common functionality like forwarding all HTTP traffic to HTTPS, rate limiting, or other QoS features; etc.</p>
  
  <p>Regarding network-level access control - this highly depends on the infrastructure you're running Jenkins on, but it may consist of host-level firewall rules, network-level ACLs, NATs, AWS security groups, etc. etc.  Generally speaking, standard stuff here - nothing special about Jenkins in this regard.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-09-18T18:12:55.957Z
Answers: My +1 for treating Jenkins as any other JEE application here in a nice manner :)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-09-18T18:07:52.383Z
Answers: 2017-09-18T18:07:52.383Z
Answers: jayhendren
Answers: <p>Besides the transport layer you should first of all enable
  <a href="https://wiki.jenkins.io/display/JENKINS/Securing+Jenkins" rel="nofollow noreferrer">Access Control</a></p>
  
  <p>to protect jenkins from public access.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-09-15T08:48:06.210Z
Answers: 2017-09-15T08:48:06.210Z
Answers: smartmeta
Body: <p>One of the options is to configure SSL in NGinx and to put this in front of Jenkins. Are there any other options for securing Jenkins? I am looking for an answer that is focused on best practices that harden the layer 6.</p>
  
Tags: <jenkins><ssl>
Title: What are best practices for implementing SSL on Jenkins?
UserDisplayName: 030
ThreadText: # What are best practices for implementing SSL on Jenkins?
  
  (Asked by: username_0 on 2017-09-15)
  
  One of the options is to configure SSL in NGinx and to put this in front of Jenkins. Are there any other options for securing Jenkins? I am looking for an answer that is focused on best practices that harden the layer 6.
  
  **Tags:** jenkins, ssl
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-09-18. Score: 2 | Accepted answer
  
  The same rules apply to hardening Jenkins as for all other web applications:
  
  * Put sensitive content behind an authentication/authorization barrier
  * Use SSL for transport-layer encryption and verifying the identity of the server
  * Restrict network-level access to only networks where clients should be connection from
  
  Regarding client authn/authz - that's pretty straightforward; there are lots of options with Jenkins for that. I use a plugin that hooks into my org's Active Directory instance, for example.
  
  Regarding SSL - while it is possible to configure Jenkins to serve content over HTTPS rather than HTTP ([documentation here](https://wiki.jenkins.io/display/JENKINS/Starting+and+Accessing+Jenkins)), I don't find that to be the easiest way to configure SSL. I think using a reverse proxy like you mentioned is a better choice. Nginx and Apache are the two popular options here. Some reasons for choosing one of these reverse proxies: can take advantage of existing tooling/resources for configuration and certificate management; easier and more flexible to configure to allow for common functionality like forwarding all HTTP traffic to HTTPS, rate limiting, or other QoS features; etc.
  
  Regarding network-level access control - this highly depends on the infrastructure you're running Jenkins on, but it may consist of host-level firewall rules, network-level ACLs, NATs, AWS security groups, etc. etc. Generally speaking, standard stuff here - nothing special about Jenkins in this regard.
  
  > **Comments:**
  > **username_2**: My +1 for treating Jenkins as any other JEE application here in a nice manner :)  
  
  ---
  
  ### Answer by username_3 on 2017-09-15. Score: 2
  
  Besides the transport layer you should first of all enable
  [Access Control](https://wiki.jenkins.io/display/JENKINS/Securing+Jenkins)
  
  to protect jenkins from public access.
  
  
  ---
  
  