On 26.02.2016, at 16:08, Travis <[email protected]> wrote: > Naturally apache mod_proxy and some basic auth should be a simple solution.
The Reverse Proxy Auth Plugin allows using the Apache authentication information for authorization in Jenkins. > So the solution is to remove this filter, fix this design or squash the basic > auth headers after apache has processed them, but before proxying to jenkins: I expect this will completely break API access, as it needs a way to authenticate with HTTP headers that is available to Jenkins for authorization. I'm not aware of a way to chain authentications, so reusing the Basic authentication you have for the application, as described above, seems to be the way to go. > Currently you can enable auth and enable all the security you want, but > jenkins still exposes to much functionality/attack surface. The TCP agent listener port can be disabled in the security configuration, and between that and locking down HTTP(S), you should be safe from the vast majority of potential attacks that don't require user interaction. Of course, this will remove your ability to use slaves/distributed builds, and makes use of the CLI more difficult/fragile. FWIW I only remember one "medium" vulnerability in Jenkins configured to have no Overall/Read permission for anonymous users (CVE-2015-5321), that would be prevented by having all URLs protected using basic auth by a reverse proxy. If you know of more, please let us know: https://wiki.jenkins-ci.org/display/JENKINS/Security+Advisories#SecurityAdvisories-ReportSecurityProblems -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1EFCB067-7BC6-4AB2-B11F-99CB7D293F0B%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
