Securing the Build Server
Build Server Basics
The simplest point to start is with access. Even in modern times, a common attack against build infrastructure is to guess credentials and gain access. Whenever you see a Jenkins server out in the wild, you would be surprised how many times jenkins:jenkins would do the trick!
To secure our build server, we want to restrict access to it. You would often find that multiple members have access to the same build server. In these cases, we need to apply granular access to ensure that a compromise of one user would not lead to the compromise of all builds. Furthermore, we want to restrict the likelihood of a user being compromised by using multifactor authentication.
Protecting the Build Server
The following steps can be followed to protect both your build server and build agents:
Build Agent Configuration: Configure build agents to only communicate with the build server, avoiding external exposure.
Private Network: Place build agents within a private network, preventing direct internet access.
Firewalls: Employ firewalls to restrict incoming connections to necessary Build server-related traffic.
VPN: Use a VPN to access the build server and its agents securely from remote locations.
Token-Based Authentication: Utilize build agent tokens for authentication, adding an extra layer of security.
SSH Keys: For SSH-based build agents, use secure SSH keys for authentication.
Continuous Monitoring: Regularly monitor build agent activities and logs for unusual behavior.
Regular Updates: Update both the build server and agents with security patches.
Security Audits: Conduct periodic security audits to identify and address vulnerabilities.
Remove Defaults and Harden Configuration: Make sure to harden your build server and remove all default credentials and weak configurations.
Last updated