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.

Defining the problem

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.

What we want

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:

Expected challenge areas

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:

Our network

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.

Our apps and our data

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.

It’s not just us

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.

Scaling

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.

Our customers are global

There are contractual obligations, and as well as regulatory and compliance issues, across the globe for our customers that need to be observed.

Our team members are also global

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.

Coming next

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.

Photo by beasty on Unsplash

30天免费试用极狐GitLab专业版

极狐GitLab不仅是源代码管理或CI/CD工具,它是一个覆盖完整软件开发生命周期和DevOps的开放式一体化平台。

免费试用
Git为Software Freedom Conservancy的注册商标,GitLab为GitLab B.V.的注册商标,我们已获授权使用“极狐GitLab”。 鄂ICP备2021008419号-1

免费试用极狐GitLab 30天

有疑问? 联系我们

Gitlab x icon svg