We’re pleased to announce that IP whitelisting and two-factor authentication are now generally available for all Codeship users -- this is especially exciting for our Codeship Enterprise hybrid cloud CI/CD feature set, as they were the last two pieces of that puzzle.
Over the last couple of months, we’ve added support for self-hosted GitHub Enterprise, GitLab Community Edition and Enterprise Edition, as well as Bitbucket Server. However, a missing piece for many has been how to grant Codeship infrastructure access to those internal systems in a limited way.
With our IP whitelisting feature released today, this is now a much more manageable problem -- you only need to open your firewall for traffic from eight fixed IP addresses.
A second piece of the puzzle has been to provide two factor authentication (2FA) for those who sign up by email or cannot authenticate via their self-hosted git server. Read more about 2FA at the bottom of this post.
What Is IP Whitelisting?
Our IP whitelisting feature is a way for you to tell Codeship to only contact your servers from a subset of IP addresses. Without this, requests from a Codeship-build infrastructure could come from virtually any IP address in the range assigned by AWS to their us-east-1 data centers. Granting access to such a large range of potential unknown sources presents an unacceptable security concern for many.
On a more technical level, enabling the IP whitelisting feature will force all outgoing traffic from Codeship services or build service through a proxy or network address translation (NAT). Codeship services (connecting to your SCM, sending build status back, etc.) will go through a proxy while all requests made from a build machine will go through NAT.
Why Should I Use IP Whitelisting?
There are a couple scenarios where you’d want to use the IP whitelisting feature, but honestly, most users will likely not need it. If you’re not hosting your git server behind a firewall or trying to access other services behind a firewall, you’ll most likely not need it.
The scenarios where you will want to enable to IP whitelisting are those where your git server is behind a firewall (ie, no publicly accessible IP address) or you’re using services that are not reachable via a public IP address. This could be deploying code to production servers in a VPC or your own data center, sending build artifacts to internal systems or file servers, running commands via SSH on servers behind a firewall, or probably a large range of other tasks that require the Codeship build server to communicate with something that doesn’t have a public IP address.
How Do I Enable IP Whitelisting?
Enabling the IP whitelisting feature is very simple.
Go to your organization’s Settings page.
Check the box next to Whitelisting.
If you don’t have access to the Settings page, contact the organization owner (usually the one who set up the account) and ask to have it enabled.
With whitelisting enabled, you'll see a list of IP addresses, which are the ones you’d want to allow access to your non-public systems. Exactly how to configure your firewall to allow access depends on your firewall, etc. so it’s best to work with your network administrator on that.
[caption id="attachment_6144" align="aligncenter" width="1354"]
Organization Settings[/caption]
When allowing access to the eight IP addresses listed in the box, you should also be mindful of what ports you want to give access to. For accessing a self-hosted git server, check the Self-hosted SCM documentation for details of the ports. For accessing other services, it really depends on your service, so unfortunately you’re a bit on your own there.
You’re welcome to ask for help in our community Slack channel though, and we’ll try our best to help you figure out what you need.
What Are the Risks of Whitelisting?
There are always some risks associated with allowing external traffic through a firewall. The firewall is there to keep internet traffic out, so naturally any “hole” through the firewall carries a risk.
In this particular case, the risk is extremely low. Only Codeship services can use the IP addresses listed, and even though another Codeship customer could theoretically call your firewall from their builds, they would still need to know what to call and how.
That said, the risk is there, so make sure that you secure your internal services adequately and don’t blindly trust any traffic that attempts to access your internal services. This is not specific to Codeship, but generally best practice when allowing outside traffic in through your firewall.
Two Factor Authentication
As mentioned earlier, one last piece of the hybrid cloud puzzle is making sure that users in a hybrid setup have the same security options as those on cloud git servers.
Two-factor authentication (or 2FA) is already a common feature and has been offered by GitHub, GitLab, and Bitbucket for some time. The main premise is that you’ll need your username and password, plus a temporary code that only you can access. This way, even if hackers were to get hold of your username and password, no one but you will be able to access your account.
At Codeship, we’ve decided to go the route of requiring an Authenticator app on your personal device (phone, tablet, etc.), which will generate unique, one-time-use codes that act as the second factor in authenticating you. To learn how to set up and configure 2FA for Codeship, see our 2FA documentation.