3

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.

030
  • 13,235
  • 16
  • 74
  • 173

2 Answers2

2

Besides the transport layer you should first of all enable Access Control

to protect jenkins from public access.

smartmeta
  • 181
  • 1
  • 8
2

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), 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.

jayhendren
  • 2,952
  • 7
  • 15