Creation of GitLab Runners
The objective of this policy is to establish clear guidelines for the use and creation of runners in GitLab, ensuring security, efficiency, and consistency in the CI/CD infrastructure.
Scope
This policy applies to all teams and domains that own projects in the corporate GitLab code repository and require the use of runners.
Types of Runner Configuration
- Default Runners: Domains will have available runners published and maintained by the platform team in the GKE1 clusters defined for this purpose. These runners are configured to meet the general requirements of most projects. For more information on Gitlab Runners see Services > Gitlab > Runners.
- Domain-Specific Runners: Each team may implement their own runners depending on their needs or workload. To implement their own runners, they must comply with the specifications provided in the following sections of this policy.
- Public Runners:
Gitlab Shared Runners
The use of public Gitlab runners is not allowed.
Comparison Chart
| Default Runners | Domain-Specific Runners | |
|---|---|---|
| Administration | Platform Team | Managed by Domain |
| Billing | Centralized by Technology | Billing Control by Domain |
| Infrastructure Management | - Shared Nodepool (default) - Independent Nodepool (by request) | Managed by Domain |
| Security Hardening | Security Team | Managed by Domain |
| Runner Updates | Platform Team | Managed by Domain |
| Cache Configuration | Centralized Storage | Storage in Domain GCP Project |
| Pipeline Artifacts | Managed by team | Storage in Domain GCP Project |
Allowed Infrastructure for Runner Use
- To implement a Runner using independent infrastructure, the template that the platform team must keep available in gitlab with the necessary code to deploy a GKE cluster with a runner using terraform must be used.
- This project must contain references to the terraform modules used for deployment which will be detailed on the Services > Gitlab > Runners page.
Use of Authorized Images and Charts
- Authorized Images: GitLab runners must exclusively use images authorized by the
platform team.
- These images will be stored in the LATAM Airlines GCP Artifactory repository.
- Default Executor Image: Gitlab runners must exclusively use images published in the LATAM Airlines Corporate GCP repository.
- Runner Helm Chart: The helm chart used to deploy gitlab runners must be the one published by the platform team and third-party helm charts may not be used.
- Updates: The platform team will be responsible for updating and maintaining the docker images and helm charts necessary for the deployment and execution of Gitlab Runners.
Centralized Runners or implement own for the domain
- When to choose Centralized Runners
- They are the default runners, no configuration is needed.
- There is no team available to manage and maintain the runners.
- The pipeline needs or Capacity are covered by the default runners.
- Domain Runners
- When compute instance specifications are required.
- When administration availability exists.
- When there are specific requirements regarding performance, security, or access that cannot be covered by centralized runners.
Security
Runners must be configured following the security best practices established by the LATAM Airlines Cybersecurity Architecture team.
Deployments on GKE
| id | Control | Type |
|---|---|---|
| 1 | Private GKE with internet access or egress for downloading packages, Docker images, and communication between GitRunner and Gitlab SaaS pending job queues. | Required |
| 2 | GKE with Workload Identity enabled | Required |
| 3 | Gitlab Runner must run within its own namespace and must run with an identity that is impersonating the SA in GCP. | Required |
| 4 | GKE must have the CSPM agent installed | Required |
| 5 | GKE must be dedicated for Gitlab Runners | Required |
| 6 | GKE must have node AutoScaling bounded or limited as convenient | Recommended |
| 7 | Artifacts generated in the different pipeline stages must not persist for more than 30 minutes | Recommended |
| 8 | GKE Gitlab-Runners for PCI projects must be exclusive | Required |
| 9 | GKE must have VPC and Subnets bounded and defined for Node Pools and workloads | Required |
| 10 | The general security configurations that GKE must comply with are documented in the GKE Hardening Standard (GRT.EST.014 - GKE Hardening Standard - v1.5) | Required |
| 11 | Every Gitlab Runner must have a TAG that identifies it; pipelines cannot be run without associated runner "tagging" | Required |
Deployments on GCE2
| id | Control | Type |
|---|---|---|
| 1 | Enable protection and security posture services defined at the corporate level through CSPM. | Required |
| 2 | Compute instances must be deployed as Shielded VM (PCI environment). | Required |
| 3 | Virtual machine disks must have encryption at rest. | Required |
| 4 | Hardened OS base images must be used for deployment. | Required |
| 5 | Network isolation must be implemented through Network Security Group and firewall rules. | Required |
| 6 | Remote access to virtual machines must be done through a pivot server, bastion host, or by granting access via IAP. | Required |
| 7 | The instance must not have a public IP, its remote access must be done through an IAP Tunnel, and its internet egress must be guaranteed through a Cloud NAT plus a Router. | Recommended |
| 8 | Ensure SSH (TCP 22) and Telnet (TCP 23) access is restricted from the Internet (0.0.0.0/0). | Required |
| 9 | Ensure SMB (TCP/UDP 445) access is restricted from the Internet (0.0.0.0/0). | Required |
| 10 | Ensure FTP (TCP 21) access is restricted from the Internet (0.0.0.0/0). | Required |
| 11 | Ensure RDP (TCP 3389) access is restricted from the Internet (0.0.0.0/0). | Required |
| 12 | For workloads under PCI Compliance, a file integrity monitoring (FIM) capability must be implemented, generating alerts on unauthorized modifications or changes to critical system files. | Required |
| 13 | For workloads under PCI Compliance, host-based firewalls or port filtering tools must be implemented on end systems or at the network level, with a default deny rule that drops all traffic except for explicitly allowed services and ports. | Required |
| 14 | Every Gitlab Runner must have a TAG that identifies it; pipelines cannot be run without associated runner "tagging". | Required |
Review and Update
This policy will be reviewed and updated periodically by the platform team to ensure its validity and suitability to the organization's needs.
Change History
1.0.0 - 2024-07-08
Initial document publication.
- Authors:
- Carlos Herrera: General document.
- Raul Linares: Security considerations.
- Approvals:
- Delivery CI/CD: Mario Young on 2024-07-05.
- DevOps Platform: Ronald Ponce on 2024-07-05.
- Cloud Foundation: Cristian Herrera on 2024-07-05.
- Cybersecurity Architecture: Raul Linares on 2024-07-08.
- Emantto Platform: Roberto Esparza on 2024-07-09.