Published on August 9, 2019
6 min read
We map out our Zero Trust goals, the challenges we expect to encounter along the way, and how we plan to address them.
Update: This is part 2 of an ongoing Zero Trust series. See our next post: Zero Trust at GitLab: The data classification and infrastructure challenge.
Zero Trust is the practice of shifting access control from the perimeter of the organization to the individuals, the assets and the endpoints. For GitLab, Zero Trust means that all devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized. This is part two of a multi-part series. Read the first post, The evolution of Zero Trust.
The benefits of Zero Trust Networking (ZTN) on paper are ideal and many rush to implement it with no idea exactly what it is (or how to get there). We previously discussed the evolution of ZTN and have been working on ways to implement things since then.
Vendors have appeared left and right, trying to sell their own versions of ZTN, but curiously no two seem to have the same interpretation. All of them say they have a product that does ZTN and it is “easy to use,” but of course if you nail them down on the implementation they all seem to fall short in one area or another.
I alluded to this above, but let’s clearly restate the problem – how does a diverse company implement Zero Trust when no one can seem to agree on any of it? The most common issue for those trying to roll out a ZTN is that, to be successful, everything must work together. The basic principles of Zero Trust – positively identify the user, positively identify the device accessed as managed and secure, ensure the user and the device are allowed to get into the asset they are trying to access, and do all of this in real time – are somehow very hard for most people to understand.
We probably should have clearly stated in our last blog post that the biggest problem with the BeyondCorp solution outlined by Google is that it is tailored for Google. This series of blog posts will take a closer look at the issues we are trying to solve, along with our working approach. It is tailored for GitLab and won’t necessarily work everywhere else. Hopefully it will provide insight into our thought process, encourage some discussion, and possibly help others along their own paths.
Implementing ZTN at GitLab involves determining what we want out of this, which is really an extension of our objectives for GitLab security in general. What we want to do is the following:
We’ve laid out what we want to do, and it was pleasant to discover in quite a few cases we are already doing just that. We just lacked either the real-time component or we simply had some type of inconvenient workaround to protect data that inhibited team members from doing their jobs easily. Based upon that knowledge and what we want to achieve, we’ve devised a list of potentially challenging areas we may encounter:
We are a company that has no perimeter to speak of, as all team members are remote. In a way this is good, since we don’t have a corporate VPN and therefore don't have to face dismantling it. But we do have to ensure that we maintain some semblance of control so we are assured that as a team member authenticates, it is done in a safe way and is independent of the network they are using.
We use a number of products, including our own DevOps offering. While we can control our own product and alter it to better serve our needs (and subsequently release said changes to our customers for their own needs), this does not address the public cloud offerings our infrastructure is based on and that we use on a regular basis: GCP, AWS, Azure, and Digital Ocean. Nor does it consider the variety of controls (and their variations) used to administer and secure these platforms. Solutions that present themselves as working just fine on one cloud offering may not work the same (or at all) on another platform, which causes its own challenges. It also does not address additional services such as Slack, Expensify, BambooHR, Zendesk, and others that contain data we have to protect. Therefore, we need to extend our protection to cover our data no matter where it resides.
We sell services to customers including private groups and projects on GitLab.com that need protecting from the public and whose access is restricted from us on a need-to-know basis.
We’re growing at a rather accelerated rate, in terms of both customers and team members. All solutions to problems have to scale, including security solutions such as ZTN.
There are contractual obligations, and as well as regulatory and compliance issues, across the globe for our customers that need to be observed.
There are unique issues across our diverse team member base, residing in more than a quarter of all countries on the planet. Each country has its own regulations, standards, and needs.
We think some of these challenge areas might look familiar to many of you, and while we hope this post has been useful we're definitely heading into some deep and murky water going forward! In the next post, we’ll take a dive into the deep end of this far-from-straightforward issue in to one of the more challenging areas: our data and the infrastructure it resides upon.
Special shout-out to the entire security team for their input on this entire blog series.
Find out which plan works best for your team
Learn about pricingLearn about what GitLab can do for your team
Talk to an expert