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.
Add a comment
|
2 Answers
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.
-
My +1 for treating Jenkins as any other JEE application here in a nice manner :)– TensibaiCommented Sep 18, 2017 at 18:12
Besides the transport layer you should first of all enable Access Control
to protect jenkins from public access.
