In the default setup of JENKINS 1.x, Jenkins does not play out any security checks. This implies the capacity of Jenkins to launch procedures and access local files are accessible to any individual who can get to Jenkins web UI and some more.

Securing Jenkins has TWO viewpoints to it.

1. Access control, which guarantees clients are verified when getting to Jenkins and their activities are approved.
2. Securing Jenkins against outer dangers

You should secure the entrance to Jenkins UI with the goal that clients are VALIDATED and suitable arrangement of authorizations are given to them. This setting is controlled for the most part in two ways:

• Security Realm, which decides clients and their passwords, just as what groups the clients have a place with.
• Approval Strategy, which figures out who approaches what.

You may utilize outside LDAP or Active Directory as the security domain, and you may pick "everybody full access once signed in" mode for approval methodology. Or then again you may let Jenkins run its very own client database, and perform access control dependent on the authorization/client grid.

Some important security considerations:

• Global security ought to be empowered.
• Jenkins ought to be incorporated with suitable modules.
• Automate the way toward setting rights and benefits.
• Limit the physical access to organizers.
• Intermittently run security REVIEWS.