> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/data-security-documentation/cortex-data-security-data-sources-and-connectors/cloud-posture-and-runtime-security-data-sources/container-registry-scanning/connect-gitlab-container-registry.md). # Connect GitLab container registry Configure Cortex Cloud to scan your GitLab Container Registry without using administrator credentials. Use a GitLab Personal Access Token (PAT) to authenticate Cortex to access the GitLab Container Registry. This allows Cortex to list all container registries or images, and secure them from vulnerabilities, malware, and secrets. ### How to connect GitLab registry Follow the wizard to connect the GitLab Container Registry connector in Cortex Cloud. 1. Navigate to **Settings → Data Sources & Integrations**. 2. On the **Add Data Sources** **or Integrations** page, click **+ Add New**, search for **GitLab Container Registry**, then hover over it and click **Add.** 3. The **Instance Name** is automatically populated. You can change it to a more meaningful name. 4. Choose the **Scan Mode**, and then follow the steps provided for that mode to configure the connection.
Cloud Scan Security scanning is done in the Cortex Cloud environment when you select this mode. 1. Select the appropriate **Cloud Provider** and **Region** for the Cortex environment to use for registry scanning. As a best practice, choose the region closest to your registry deployment to achieve the best scanning throughput and potentially reduce cloud costs. 2. (Optional) Enable **Allow access by IPs** to specify a static IP address for the scanner to use. Make sure the static IP is allowed through your firewall so the scanner can access the registry during the scanning process. 3. Choose the relevant **Account Type** for GitLab deployments: **GitLab Cloud (Saas)** 1. (Optional) Enter the **Group Id**. You can enter a single group ID or a list of group IDs separated by a comma. The group ID is used to locate all the registries within a specific group. 2. (Optional) Enter the **Project Id**. You can enter a GitLab Project ID or a list of project IDs separated by a comma. The project ID is used to locate all the registries located within a specific project.
3. Under **Authentication Method**, enter your GitLab **Access Token**. **GitLab Self-Hosted** 1. Enter the **Registry URL**. If you are using a CA certificate, enter the server IP address instead of the registry url. 2. (Optional) Enter the **Group id**. You can enter a single group ID or a list of group IDs separated by a comma. The group ID is used to locate all the registries within a specific group. 3. (Optional) Enter the **Project Id**. You can enter a GitLab Project ID or a list of project IDs separated by a comma. The project ID is used to locate all the registries located within a specific project.
4. Enter the **Api Domain**. Include the GitLab API base URL with the **https\://** prefix (for example, `https://gitlab.example.dev`). 5. Under Authentication Method, enter your GitLab **Access Token**. 6. (Optional) Expand **Show Advanced Settings**, and then enter the **CA certificate** in PEM format for Cortex to validate the GitLab registry. 4. Select **Next.**
Scan with Outpost Security scanning is done on infrastructure deployed to a cloud account that you own. This mode requires additional cloud provider permissions and may incur extra costs. {% hint style="warning" %} #### Prerequisite Ensure an [Outpost](broken://pages/IBQJG3OTOvA9OFwj8C7J) is connected to your tenant. {% endhint %} 1. Choose a **Cloud Provider** to initialize registry scanning.

Note

If you choose Azure as the Cloud Provider, you must also select the Tenant Id. The Tenant Id is required to approve Cortex as an enterprise application in your Azure tenant.

2. Choose Outpost account to use for this instance. If no Outposts are shown, you can Create a new one. For more details, see [Outposts](broken://pages/QYEpb2yUhAnk65LXlkaq#phase-2-creating-the-outpost).

Note

If you choose Azure as the cloud provider, only Outposts associated with the selected tenant ID are displayed.

3. Select the **Region** where the registry is hosted. 4. (Optional) Enable **Allow access by IPs** if you want to specify a static IP address for the scanner to use. Make sure the static IP is allowed through your firewall so that the scanner can access the registry during the scanning process. 5. Choose the relevant **Account Type** for GitLab deployments: **GitLab Cloud (Saas)** 1. (Optional) Enter the **Group Id**. You can enter a single group ID or a list of group IDs separated by a comma. The group ID is used to locate all the registries within a specific group. 2. (Optional) Enter the **Project Id**. You can enter a GitLab Project ID or a list of project IDs separated by a comma. The project ID is used to locate all the registries located within a specific project.
3. Under **Authentication Method**, enter your GitLab **Access Token**. **GitLab Self-Hosted** 1. Enter the **Registry URL**. If you are using a CA certificate, enter the server IP address instead of the registry url. 2. (Optional) Enter the **Group id**. You can enter a single group ID or a list of group IDs separated by a comma. The group ID is used to locate all the registries within a specific group. 3. (Optional) Enter the **Project Id**. You can enter a GitLab Project ID or a list of project IDs separated by a comma. The project ID is used to locate all the registries located within a specific project.
4. Enter the **Api Domain**. Include the GitLab API base URL with the **https\://** prefix (for example, `https://gitlab.example.dev`). 5. Under Authentication Method, enter your GitLab **Access Token**. 6. (Optional) Expand **Show Advanced Settings**, and then enter the **CA certificate** in PEM format for Cortex to validate the GitLab registry. 6. Select **Next.**
Scan with Broker VM Security scanning in private networks is performed using broker VM infrastructure when you select this mode. {% hint style="warning" %} #### Prerequisite Ensure one of the following is configured: * [Set up and configure Broker VM](broken://pages/sMiiS7bJAcvJCX4UPkEg). * [Configure High Availability Cluster](broken://pages/g5TSWmm4QQlW31hfwhjh). {% endhint %} 1. Choose a **Scan with Broker VM** mode to initiate registry scanning. You can select either a standalone **Broker VM** or a High Availability (HA) **Cluster**. 2. Select **Applicable Broker VMs**. Choose the appropriate **Broker VM** or **Cluster** from the list configured in your tenant.

Note

If the list does not display any **Broker VMs** or **clusters**, **Add New Broker VM** or A**dd New Cluster**. For more details, see [Set up and configure Broker VM](broken://pages/sMiiS7bJAcvJCX4UPkEg). 3. Choose the relevant **Account Type** for GitLab deployments: **GitLab Cloud (Saas)** 1. (Optional) Enter the **Group Id**. You can enter a single group ID or a list of group IDs separated by a comma. The group ID is used to locate all the registries within a specific group. 2. (Optional) Enter the **Project Id**. You can enter a GitLab Project ID or a list of project IDs separated by a comma. The project ID is used to locate all the registries located within a specific project.
3. Under **Authentication Method**, enter your GitLab **Access Token**. **GitLab Self-Hosted** 1. Enter the **Registry URL**. If you are using a CA certificate, enter the server IP address instead of the registry url. 2. (Optional) Enter the **Group id**. You can enter a single group ID or a list of group IDs separated by a comma. The group ID is used to locate all the registries within a specific group. 3. (Optional) Enter the **Project Id**. You can enter a GitLab Project ID or a list of project IDs separated by a comma. The project ID is used to locate all the registries located within a specific project.
4. Enter the **Api Domain**. Include the GitLab API base URL with the **https\://** prefix (for example, `https://gitlab.example.dev`). 5. Under Authentication Method, enter your GitLab **Access Token**. 6. (Optional) Expand **Show Advanced Settings**, and then enter the **CA certificate** in PEM format for Cortex to validate the GitLab registry. 4. Select **Next.**
5. In the **Initial Scan Configuration**, set your scanning process to focus on recently added or modified container images and exclude older ones that do not align with your current scanning objectives. This setting helps avoid unnecessary scans. Choose one of the following options: * **All:** Scans all container images, including all versions (tags), in all discovered repositories. * **Latest Tag**: Scans only images tagged **'latest'** in all discovered repositories. * **Days Modified**: Scans container images that have been created in the last few days. You can select a range of up to **90** days for the scan. 6. Select **Save**. When the GitLab data source is saved successfully, a new data connector is created, and the initial discovery scan is started. The connection process may take up to 15 minutes. 7. To check connector status and scan results, follow these steps: 1. Navigate to **Settings → Data Sources & Integrations**. 2. Find the **GitLab Container Registry** instance from the list of **3rd Party Data Sources** connectors, or use **Search**. 3. In the **GitLab Container Registry** instance row, select **View Details**. The **GitLab Instances** page appears. 4. On the **GitLab Instances** page, you can filter results by any heading and value. 5. Select an instance name to open the details pane. The details pane contains the following granular information: | Instance Details | Description | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Status** | Shows the status of the connector: Connected, **Error**, **Warning**, **Disabled**, or **Pending**. | | **Applet Status on Broker VM** | Shows the status of the **Registry Scanner** applet on the **Broker VM** page. This status is visible only when the **Scan with Broker VM** mode is selected. | | **Repositories** | Shows the number of scanned repositories in the registry. | | **Scan Mode** | Shows the selected scan mode for the data connector, such as **Cloud Scan**, **Scan with Outpost**, or **Scan with Broker VM**. | | **Security Capabilities** | Shows a breakdown of the security capabilities enabled on the instance and their individual statuses. For example, select **Registry Scanning** when it shows a **warning** or **error** status to see the open errors and issues that contributed to the status. | 8. **Next Steps**. * After the scan is complete, you can view the scanned images on the **Container Images Inventory** page. For more details, see [Container Images assets](broken://pages/GNlH7mRlMR2f5S4YvwPc). * If you have selected the **Scan with Broker VM** option, then a **Registry Scanner applet** is created on the selected **Broker VM** or **Cluster**. For details, see [Verify Registry Scanner connection](broken://pages/AznCpVx4A5RlGLMjN5WD#verify-registry-scanner-connection).

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/data-security-documentation/cortex-data-security-data-sources-and-connectors/cloud-posture-and-runtime-security-data-sources/container-registry-scanning/connect-gitlab-container-registry.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.