Xiid Docs

Appearance

Gitlab SealedTunnel Integration ​

By using the SealedTunnel, you can secure your Gitlab servers and make them invisible to the outside world.

Overview ​

This guide will walk you through how to wrap your Gitlab instances with the SealedTunnel, allowing you to close down all inbound ports on your Gitlab server, triple-encrypt all traffic (including local git commands such as push and pull), and ensure that your code base and IP remain safe.

Prerequisites ​

You must already have:

This guide will use the domain name gitlab.example.com to reference to the domain name tied to your Gitlab instance.

This guide will use the loopback address 127.1.2.3 for all Entrypoint mappings, however you can use any loopback address as long as you consistently use that loopback address for all Gitlab Entrypoints.

Exitpoint Setup ​

  • Sign in to the Agent Configuration Portal (typically found at https://127.0.0.1:10458 on the Domain Controller).
  • Go to the Tunnels tab and select the Exitpoints subtab.
  • On the Exitpoints screen, click the + Add Exitpoint button in the top right.
  • Provide a description for the Exitpoint (such as Gitlab Server) and click the purple SAVE button.
  • Deploy the new Exitpoint/STLink on your Gitlab server.

HTTP/S Integration ​

  • Sign in to the Agent Configuration Portal.
  • Find your newly created Exitpoint in the table and click the purple Pencil button on the far left of the row.
  • On the Edit Exitpoint screen, click the + Add Mapping button.
  • The first mapping that you will need is the 443 mapping to the Gitlab Web Portal.
  • On the Add Mapping screen, enter a Description for the mapping (recommended: Gitlab Web Portal).
  • In the Map To field, enter a loopback address and provide 443 for the port. (i.e. 127.0.0.1:443)
    • This mapping will route traffic to and from port 443 on the Gitlab server via the STLink software.
    • If your Gitlab server is hosted on http, use port 80 instead
  • Make sure that the Application dropdown is set to None
  • Click the purple SAVE button.

You will be redirected to the Exitpoint screen and you will now see a row in the Mappings table for the Gitlab Web Portal.

SSH Integration ​

If you use SSH to clone Git repositories, you will additionally need to add SSH protocol access to the Exitpoint to route to the proper port on the Gitlab server.

  • Sign in to the Agent Configuration Portal.
  • Add a new mapping under your Gitlab Exitpoint by clicking the + Add Mapping button in the top right.
  • Provide a Description for the mapping. (recommended: Git SSH Command Access)
  • In the Map To field, enter a loopback address and provide 22 for the port. (i.e. 127.0.0.1:22)
  • Make sure that the Application dropdown is set to None
  • Click the purple SAVE button.

Entrypoint Configuration ​

Before continuing, if you have not deployed Entrypoint STLinks on client machines, please refer to the Entrypoint Setup Information.

There are a few ways that client-side access to the Gitlab Server can be configured.

This guide will walk through two methods that we recommend, Static Access and SSO Access, depending on preference, use-case and level of security:

  • Static Access allows for more convenience and is recommended for developers that use Git very regularly in day-to-day work. Static Access means that the developer's SealedTunnel access to Gitlab is always open and available.

  • SSO Access requires that users open the SealedTunnel via an SSO Portal to access the Gitlab Server, including Web Portal access and Git command access (git push, git pull, etc.).

SSO Access is recommended for customers that would like an additional layer of security and user authentication before interacting with their repositories. SSO Access requires Xiid IM.

Static Access Method ​

Repeat this for each client/Entrypoint that should have access to the Gitlab Server.

  • Sign in to the Agent Configuration Portal.
  • Click the purple Edit button next to the developer's Entrypoint to edit their mappings.
  • Click the + Add Mapping button to create the Gitlab Web Portal mapping.
  • Enter a Description (recommended: Gitlab Web Portal Access).
  • In the Bind field, enter 127.1.2.3:443.
    • If the client machine is running an HTTPS server, please refer to the network interface mapping to set up routing to a separate bind address.
    • Multiple services (e.g., web server and STlink) cannot bind to the same address/port and many web servers bind to the loopback addresses, so 127.1.2.3:443 will not be available for the STLink service to bind to, however the Git client will de-facto require port 443. You may also be able to modify the origin URL to include a new port as well.
    • If you are running an unsecured server, replace 443 with 80 in the Bind field.
  • Click the Exitpoint dropdown and select the Gitlab Server Exitpoint created earlier.
  • Select the HTTP/S Exitpoint Mapping in the table further down with the description Gitlab Web Portal.
  • Last, click the purple SAVE button.

For SSH Git Commands:

  • Repeat the above steps if you intend to have developers use the SSH protocol to back their Git commands, replacing the https port (443) in the Bind field with 22.
    • Be sure to use the same loopback address as the HTTP/S mapping!

SSO Access Method ​

  • Sign in to the Agent Configuration Portal.
  • Click the Applications tab on the left side.
  • Select the Choose button for the SealedTunnel card.
  • From the SealedTunnel Application List, click the purple + Add Application button in the top right.
  • Add SealedTunnel Application screen, select the SSO Portal you would like to add Gitlab access to in the Portals dropdown.
    • You can also use the Group Include/Group Exclude fields to limit the application to only your developers through Security Groups in the Directory.
    • If you can't see these fields, flip on Advanced Mode in the top right.
  • Provide a description in the Description field (recommended: Gitlab Access).
  • Click the purple SAVE button on the left.
  • Find the SealedTunnel application we just created and click the purple pencil button to edit the application.
  • On the Edit SealedTunnel screen, click the purple + Add Mapping button in the middle of the page.
  • Provide a description in the Description field (recommended: Gitlab Web Portal Access).
  • In the Bind field, enter 127.1.2.3:443.
    • The Application will not be able to open the SealedTunnels if port 443 is already in use on the client machine.
  • Click the Exitpoint dropdown and select the Gitlab Server.
  • In the Mappings table at the bottom of the page, select the web portal mapping (port 443) with the description Gitlab Web Portal.
  • Click the purple SAVE button.

For SSH Git Commands:

  • Repeat the above steps if you intend to have developers use the SSH protocol to back their Git commands, replacing the https port (443) in the Bind field with 22.
    • Be sure to use the same loopback address as the HTTP/S mapping!

Domain Name Override ​

TIP

If you configure gitlab.example.com to point to the Gitlab loopback address you used on all Entrypoints at the DNS level, the following local-only Domain Name configuration is unnecessary.

To create a seamless experience for your developers, modify the client's Hosts file to add your Gitlab Server domain name.

Modifying the Hosts file will override the domain name resolution for your Gitlab server, so that when your computer reaches out to a given domain name, the Hosts file will point the client machine back to the loopback address used by the SealedTunnel Gitlab mappings.

Follow these instructions to configure your host file with the domain name you wish to use for your Gitlab Server. If you changed the loopback address in the Entrypoint step prior to this, make sure to use your loopback address instead of 127.1.2.3.

Gitlab Runner Setup ​

For Gitlab Runners to leverage the SealedTunnel:

Copyright © 2024 Xiid Corporation