Information security encompasses a variety of different working groups. These security best practices support the functions of business operations, infrastructure, and product development, to name a few. Everybody is responsible for maintaining a level of security to support compliance (available internal-only), while raising the bar of our security posture.
As part of raising that bar, GitLab is implementing Zero Trust, or the practice of shifting access control from the perimeter of the org to the individuals, the assets and the endpoints. You can learn more about this strategy from the Google BeyondCorp whitepaper: A New Approach to Enterprise Security.
In our case, Zero Trust means that all devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized. Because Zero Trust relies on dynamic, risk-based decisions, this also means that users must be authorized and validated: what department are they in, what role do they have, how sensitive is the data and the host that they are trying to access? We’re at the beginning stages in our Zero Trust roadmap, but as we move along in the journey, we’ll document our lessons learned, process and progress in our Security blog.
To learn more about the concept of Zero Trust and our roadmap for implementation, see this GitLab presentation from GoogleNext19: https://www.youtube.com/watch?v=DrPiCBtaydM
You can also check out our Zero Trust Networking (ZTN) blog series where we detail the ZTN implementation challenges we foresee ahead, some we've already managed to work through, and where we'll go from here:
Head over to the /r/netsec subreddit to see our October 29, 2019 Reddit AMA on Zero Trust where we fielded questions around our ZTN implementation, roadmap, strategy and more.
Identity is a critical element of the implementation of a ZTN framework. GitLab is moving forward with an implementation of Okta to allow us to standardise authentication for Cloud Application access and implement user-friendly SSO. See our Okta page for more details.
In many enterprise environments, virtual private networks (VPN) are used to allow access to less secured resources, typically also protected by an enterprise firewall. Adding corporate VPN connectivity only marginally improves the security of using those systems and assumes a network perimeter is in place. At GitLab, as an all remote company, we do most of our work using other Software-as-a-Service (SaaS) providers that we rely on to maintain confidentiality of communication and data.
In relation to Zero Trust, a corporate VPN is a perimeter, which ZTN architecture deemphasizes as a basis for making authorization decisions. Current access to critical systems is managed through alternative controls.
While a corporate VPN is not implemented at this time, there are other valid use cases for which individual team members may still wish to use a personal VPN, such as privacy or preventing traffic aggregation. Team members that wish to use a personal VPN service for any reason may still expense one.
For the use case of laptop usage in untrusted environments, such as coffee shops and coworking spaces, team members should prioritize a baseline of always-on host protections, such as up-to-date security patching, host firewalls, and antivirus, by following the system configuration guidelines at a minimum. That said, a personal VPN may provide additional protections in these situations. For more on personal VPNs see the Personal VPN page.
The GitLab Security Teams are available 24/7/365 and are ready to assist with questions, concerns, or issues you may have.
There are some common scenarios faced by GitLab team members:
To contact for any other reason, see Contacting the Team or Engaging the Security On-Call.
The CEO will not send you an email to wire cash, the CFO won't send you a text message to ask for gift cards, or anything else that feels like CEO fraud or CEO scam. These types of spear phishing events will be more common as we grow. Feel free to verify any unusual requests with a video call.
What should you do if you receive a potential phishing email or text from GitLab's CEO?
If you are wanting to implement a process, code, or some other procedure that could impact the security posture of GitLab or its products, something that the Security Team uses as a resource is Threat Modeling. The Security Team highly encourages change and improvements, and also ensure that changes and improvements are done securely. The Security Team uses a threat framework based upon the PASTA methodology. For more information including an issue template for doing your own threat modeling, check out the Threat Modeling page.
If you have a question or concern and need to speak with the Security Team, you can contact Security.
Users without 2FA enabled that are stale for
over 30 days will be blocked/suspended until resolved. This improves the
security posture for both the user and GitLab.
If any systems provide an option to use SMS text as a second factor, this is highly discouraged.
Phone company security can be easily subverted by attackers allowing them to take over a phone account.
(Ref: 6 Ways Attackers Are Still Bypassing SMS 2-Factor Authentication / 2 minute Youtube social engineering attack with a phone call and crying baby)The following instructions are for Apple (MacBook Pro or Air) users. Linux users please go to the Linux Tools section of the handbook.
When backing up data team members should use GitLab's Google Drive. Our deployment is regularly tested and data at rest is encrypted by default. For alternative options, please reach out to IT.
System Preferences -> Security & Privacy under the Firewall tab. If the option reads Firewall: Off, you will need to click on the lock at the bottom of the dialog box to make changes, and click on Turn Firewall On (see screenshot).
Sometimes a team member needs to test a particular scenario that requires bypassing of the firewall. If this is the case, ensure one of the following network scenarios/configurations is used for your laptop:
security Slack channel if you have questions about this.Refer to this guide for setting up a dedicated WiFi so that your work notebook is isolated from other personal devices in your home network.
Many services that team members use such as Slack and Zoom have mobile applications that can be loaded onto iOS or Android devices, allowing for use of those resources from a mobile phone. Refer to the acceptable use policy for more information on using a mobile device.
Most major applications (Slack, Zoom, Okta Verify) have been examined and vetted by the Security Team, but there are some applications which are not only of limited scope in the data they can access, but also have security issues. In such cases, use the mobile device's web browser for access to the resource. If you have a question about the security of a mobile app and want to know if you should be using it to access GitLab data, contact the Security Team via Slack in the #security-department channel.
Some Google Cloud resources, if deployed with default settings, may introduce risk to shared environments. For example, you may be deploying a temporary development instance that will never contain any sensitive data. But if that instance is not properly secured, it could potentially be compromised and used as a gateway to other, more sensitive resources inside the same project.
Below are some steps you can take to reduce these risks.
By default, Google will attach what is called the Compute Engine default service account to newly launched Compute Instances. This grants every process running on your new Compute Instance 'Project Editor' rights, meaning that if someone gains access to your instance they gain access to everything else in the project as well.
This default account should not be used. Instead, you should choose one of the following two options:
--no-service-account --no-scopes flags if using the gcloud command, or by selecting the following option in the web interface:
When permitting access to Compute Instances via firewall rules, you should ensure you are exposing only the minimum ports to only the minimum instances required.
When creating a new firewall rule, you can choose to apply it to one of the following "Targets":
All instances in the network: This is probably not the option you want. Selecting this option is a common mistake and may expose insecure services on instances other than your own.Specified target tags: This is probably the option you want. This allows you to limit the rule to instances that are marked with a specific network tag. You should create a descriptive tag name like "allow-https-from-all" so that it can be easily identified and used when needed.Specified service account: This is a less likely option, but perfectly viable if you have already done some design around custom service accounts. It is similar to a tag but will be assigned automatically to all instances using a specific service account.When choosing "Ports and Protocols" to expose, you should never select "Allow All" and should never manually enter entire ranges such as 1-65535. Instead, you should choose only the specific required TCP/UDP ports you need to expose.
GKE nodes are Compute Instances, and by default use the same Compute Engine default service account described above. Despite making it their default, Google specifically states "You should create and use a minimally privileged service account to run your GKE cluster instead of using the Compute Engine default service account.".
Whether deploying a GKE cluster manually or automatically via Terraform, you can follow these instructions to create and attach a service account with the minimum permissions required for a GKE cluster node to function.
In addition, you should enable Workload Identity and Shielded Nodes on all new clusters. This can be done by appending the --workload-pool=[PROJECT-ID].svc.id.goog --enable-shielded-nodes flags if using the gcloud command, or by selecting the following options in the web interface (located under the "Security" menu):
When creating a Cloud Function with a "trigger type" of HTTP, Google provides two layers of access control. The first is an identity check, via the following two options under Authentication:
The second is network-based access control, via the following options under Advanced Settings -> Connections -> Ingress Settings. You should choose the least permissive option that will still allow your function to work:
Some uses cases will prevent you from choosing the "best practice" when it comes to authenticating an inbound request. For example, you may wish to host a webhook target for an external service that doesn't support the use of Google Cloud credentials. For this use case, you can store a complex, machine-generated secrete as an environment variable inside your function and then ensure the requesting service includes that secret inside the request headers or JSON payload. More details and examples can be found here.
Similar to Compute Instances and GKE clusters, Cloud Functions also bind to a service account by default. And once again, Google states that "it's likely too permissive for what your function needs in production, and you'll want to configure it for least privilege access".
For most simple functions, this shouldn't an issue. However, it is possible that a complex function could be abused to allow the person invoking the function to impersonate that service account. For this reason, you'll want to configure a new service account with the bare minimum permissions required for your function to operate.
You can then choose to use this new service account via the option under Advanced Settings -> Advanced -> Service account.
#whats-happening-at-gitlab slack channel/security Slack command.Passwords are one of the primary mechanisms that protect GitLab information systems and other resources from unauthorized use. Constructing secure passwords and ensuring proper password management is essential. GitLab's password procedures are based, in part, on the recommendations by NIST 800-63B. To learn what makes a password truly secure, read this article or watch this conference presentation on password strength.
1Password is a password manager. Ideally you memorize one strong password - hence the name - and let 1Password generate and manage strong, unique passwords for every site for which you have a login.
Following this guide, it will be helpful to understand a few terms we'll be using throughout.
1Password can be used in two different ways - as a standalone application (by purchasing a standalone license) or as a hosted service (by subscribing). GitLab uses 1Password for Teams which is a hosted service.
GitLab is transitioning to use Okta as a primary entry and access point for SaaS and other company applications. This does not mean that 1Password will be deprecated completely, but it is preferred that, where possible, you use Okta as your primary entry point into applications. GitLab will be using Okta for SAML/SSO and passwordless authentication for many applications, so the need to store passwords in a password manager will diminish over time.
If you want to use 1Password for your private passwords not related to your work at GitLab, there are a few options.
Please note our 1Password for Business license agreement is an older 'Early adopter' agreement and does not include the 1Password for Families feature
gitlab-com/business-ops/itops in your onboarding
issue or in #it-ops on slack. For all other access, create an
access request issue.1Password for Teams stores all Vaults on the 1Password servers and allows for sharing between multiple people on the same team. Every GitLab Team Member who needs access to a shared vault should consult their departments for any shared vault information.
Each member of the team has a vault called Private which only you can see, and allows you to store personal credentials within the GitLab team's account.
To really get the full benefit of 1Password, you'll need to hook our Teams account up to one of the native apps.
This guide will cover setting up the macOS app. It's their lead platform and is the most up-to-date. These instructions may or may not work for the Windows version. If you use 1Password 6 without a 1Password.com account, make note of this.
Now you'll need the Emergency Kit PDF that 1Password told you to save when you registered your Teams account. Note: Store the Emergency Kit safely. Store a copy of the Emergency Kit on a USB flash drive or print a copy and store it in a vault at home or safe deposit box — somewhere not online or accessible by anyone other than yourself.
If you saved it as a digital PDF file:
If you printed the PDF:
@gitlab.com emailAfter the Team is added, you should see some notifications about vaults being added to 1Password. By default you'll have the Private vault, but may have access to others.
Read this section only if you could not follow the instructions in "Adding the GitLab Team to a 1Password app" section.
Because the Teams feature is not available in your current version of 1Password, we need to update the app to the latest version:
Click the Vault Selector in the upper-left corner of the window:
GitLab team members have access to a Private vault by default, which is your hosted, private vault that is part of the GitLab 1Password for Teams account. Since the Private vault is part of the GitLab Teams account, it should be thought of as company property (like the @gitlab.com email account), however the vault can not be viewed by anyone else on the team, including admins. If you choose to store truly personal information in the Private vault, it opens up the possibility that you would be separated from this information if you offboard. Such truly personal information is therefore better to store in your Primary vault, which is associated with you instead of with the GitLab Teams account, assuming that you added an individual account.
People may request access to other vaults such as shared vaults that their teams/departments have created.
Go to Browser extensions and install the extension for whatever browser you're using. You should not need a beta version here.
With the extension installed, you should be able to go to a site that you have credentials stored for in 1Password and log in:
If you don't see the site listed in the results window, make sure you're using the correct vault:
When 1Password detects a login form submission, it may ask if you want to save the login with a dialog like this:
If you do want to save it, make sure the appropriate Vault is selected first.
Starting with version 8, 1Password can operate as the single source of truth for your SSH keys. This includes generating private keys, storing them securely, filling your public keys in to sites like GitLab.com, and unlocking the keys automatically when performing git operations.
More information is available in the official documentation.
1Password CLI integration supports secure handling of secrets used in command line tools, config files, and scripts executed on your laptop. To setup the CLI integration, follow the getting started guide.
It is recommended to store secrets such as personal access tokens in 1Password. Avoid storing secrets in unencrypted files.
Example for configuring glab with 1Password CLI:
pat
and add a field api. Insert the value of your PAT into the newly created field api.
.env file:# format is op://vault-name/item-name/[section-name/]field-name
echo "GITLAB_TOKEN=op://Private/GitLab/pat/api" > $HOME/.gitlab-pat.env
glab with the PATalias glab="op run --env-file=$HOME/.gitlab-pat.env -- glab"
glab api version. This should print
the version of gitlab.com if the configuration succeeded.glab api version
{"version":"15.4.0-pre","revision":"3e84f577d51"}
Please refer to 1Password FAQ.
If you are planning to use both the GitLab team account and a separate individual account you should first add your separate individual account to the app first (Preferences > Accounts). By doing this you will be able to unlock the 1Password app using the Master Password of the individual account.
If you were using 1Password before joining GitLab, and you receive a prompt titled Migrate To Account, choose I'll move later. There is no harm in doing this, and it is easy to move items between vaults.
You are encouraged to use 1Password for your private passwords, not related to your work at GitLab. This makes it less likely for a security breach to occur. You can purchase a standalone license or start an individual subscription.
As stated in the GitLab Password Procedure, all GitLab team-members should use two factor authentication (2FA) whenever possible.
1Password provides an alternative solution that does not require using your smartphone: 1Password Time-based One Time Passwords (TOTP). 2FA codes are displayed directly in the 1Password app running on your laptop (Note: this can not be set up via 1Password browser extension or 1Password web app).
1Password TOTP is compatible with Okta, as it uses the same algorithm as Google Authenticator.
To enable TOTP for a saved account:
Please refer to demo video 1password TOTP setup
Please refer to the 1Password blog for more information on how TOTP works.
If scanning the QR code using the "transparent window" with the 1Password Mac app fails on a recent macOS, please consider using the 1Password iOS app instead. This mechanism works the same way, and supports Touch ID to login.
While the above 1Password default recommendation applies to all GitLab team-members, there are alternative, although more complex solutions that can also be used. Google Authentication is a TOTP solution that can be used to store tokens, for those who want to have separate application for password storage and token storage. However, be aware that using two applications is more complex, and not necessary. If unsure which mechanism to use, we recommend using 1Password as a TOTP for 2FA.
Follow this guideline when getting a new mobile device, if you are using Google Authenticator as a TOTP mechanism.
This is an example of how Robert, one of our developers, uses 1Password:
Once you fully commit to using 1Password to manage all of your security information, it really does make life easier.
I memorize one strong password and let the app generate everything else. Every site I use has a unique password that I can't compromise because I don't even know it, and a hacked site can't compromise it because the password is never re-used on another site.
I store my shipping and credit card info in 1Password and use the browser extension to quickly fill out shipping and billing information on shopping sites.
I store my passport data, along with a digital scan, in 1Password; driver's license info and scan; insurance info; software license keys; any important information that needs to be secure but still easily accessible when I need it, from anywhere. I sync my personal vault to my personal iCloud so it's available on my phone, tablet, laptop, and desktop.
Even my 1Password for Teams account information is stored in my personal Primary vault, with the Emergency Kit PDF as a secure attachment. I have no idea what the password is. I've never actually typed it. And that's the idea:
When traveling with a device that has access to the GitLab 1Password vaults, be sure to enable Travel Mode in 1Password. Travel Mode removes copies of any 1Password vaults that are not tagged as "safe for travel" from your mobile devices. None of the GitLab shared vaults are marked as safe for travel so you will need to either create a dedicated travel vault or mark your Private vault as safe for travel.
Once you have enabled Travel Mode open 1Password on each device you will be taking with you so that it can sync with 1Password.com and remove any vaults that cannot be used while traveling.
For more information on Travel Mode and how it works, see the AgileBits blog.
The GitLab Security Training is GitLab's security awareness presentation for new hires and annual training requirements that began in 2020. The purpose of the annual training is to mature our internal posture through regular training while satisfying external regulatory requirements. The New Hire training is part of the onboarding process, and needs to be completed by every new hire. We are trying to make it fun, engaging and not time-consuming.
Annual security training has been developed by GitLab Security's Governance Program. The goal of the training is to:
The New Hire Security Training is delivered through a pre-recorded presentation that is presented by a member of the Security Incident Response Team team. The following materials are made available for your consumption:
GitLab Security Awareness Training is a handbook first GitLab-customized training + annual policy reviews provided via ProofPoint.
/security Slack commandSecurity Training
You are strongly encouraged to engage the team behind the training and provide feedback, or ask any questions related to the content of the training. You can do that through:
GitLab conducts routine phishing tests at a minimum of once per quarter. All team members may occasionally receive emails that are designed to look like legitimate business-related communications but will in actuality be simulated phishing attacks. Real phishing attacks are designed to steal credentials or trick the recipient into downloading or executing dangerous attachments. No actual attempts will be made by GitLab to steal credentials or execute malicious code.
The goal of these campaigns is not to catch people clicking on dangerous links or punish those who do, but rather to get people thinking about security and the techniques used by attackers via email to trick you into running malicious software or disclosing web passwords. If you fall victim to one of these simulated attacks feel free to take the training courses again or to ask the security team for more information on what could've been done to recognize the attack. What you shouldn't do is feel any shame for having clicked on the link or entered any data, nor should you feel like you need to cop to the security team and let them know you made a mistake. Making a mistake online is practically the reason the Internet was invented.
When you receive an email with a link, hover your mouse over the link or view the source of the email to determine the link's true destination.
If you hover your mouse cursor over a link in Google Chrome it will show you the link destination in the status bar at the bottom left corner of your browser window.
In Safari the status bar must be enabled to view the true link destination (View -> Show Status Bar).
Some examples or methods used to trick users into entering sensitive data into phishing forms include:
When viewing the source of an HTML email it is important to remember that the
text inside the "HREF" field is the actual link destination/target and the text
before the </A> tag is the text that will be displayed to the user.
<a href="http://evilsite.example.org">Google Login!</a>
In this case, "Google Login!" will be displayed to the user but the actual target of the link is "evilsite.example.org".
After clicking on a link always look for the green lock icon and "secure" label that signify a validated SSL service. This icon alone is not enough to verify the authenticity of a website, however the lack of the green icon does mean you should never enter sensitive data into that website.
If you suspect that the email is targeted specifically at you or GitLab or you received an email from our testing platform please, select ONE of the options below:
PhishAlarm is a Gmail add-on that allows your users to alert security and incident response teams to suspected phishing emails. It will automatically notify GitLab security and the email will be further investigated. (PhishAlarm is found on the right side panel of Gmail. You can hide or show this panel by clicking on the > or < symbol on the bottom right corner of your browser window). OR
phishing@gitlab.com for it to be investigated. Forwarding as an attachment helps standardize the workflow to extract the contents of the email for easier analysis. ORTo submit an email via PhishAlarm to GitLab's Security Team using Gmail:
To forward the email as an attachment to GitLab's Security Team using Gmail:
phishing@gitlab.comGmail offers the option to report the email directly to Google as a phishing attempt, which will result in its deletion. Reporting the email in this manner will help the security team track phishing metrics and trends over time within Google Workspace.
To report the email as phishing via built-in Gmail reporting:
If you receive an email that appears to come from a service that you utilize, but other details of the email are suspicious – a private message from a sender you don't recognize, for example – do not click on any links in the email. Instead use your own bookmark for the site or manually type the address of the website into your browser.
Unsolicited email should be treated as phishing emails. For example, if you did not register for a site claiming to send you email, do not click on links in the email or visit the site.
The Security Team uses automated tooling to analyze your reported attachments.
If something is missing from your report, you may be contacted by mail@tines.io,
which is the tooling's no-reply notifyer address.
Phishing and other social engineering attacks aren't only sent via email.
You might receive a suspicious text / SMS message, a weird Direct Message on social
media platforms like LinkedIn, or a phone call. If it's work related, please
use the /security Slack command.
Even if you're unsure or it feels insignificant, you can always ask in the #security Slack channel.
Should a team member lose a device such as a thumb drive, YubiKey, mobile phone, tablet, laptop, etc. that contains their credentials or other GitLab-sensitive data they should report the issue using the /security command in Slack to engage SIRT.
GitLab provides a panic@gitlab.com email address for team members to use in situations when Slack is inaccessible and immediate security response is required.
This email address is only accessible to GitLab team members and can be reached from their gitlab.com or personal email address as listed in Workday. Using this address provides an excellent way to limit the damage caused by a loss of one of these devices.
Additionally if a GitLab team member experiences a personal emergency the People Group also provides an emergency contact email.