### Summary This epic aims to standardize and unify Cloudflare configuration management across all GitLab offerings. The project involves creating reusable Terraform modules that will provide a self-service approach for teams to manage their Cloudflare resources. By reducing implementation complexity for teams across GitLab when adopting Cloudflare functionality we can codify and scale our Cloudflare expertise to provide a compliant and secure edge network. ### Problem We currently have a number of internal customers using the `cloudflare-waf-rules` module (examples from [dedicated](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/instrumentor/-/blob/main/aws/configure/pre_ansible/domains.tf?ref_type=heads#L5), [cloud connect](https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/blob/main/environments/cloud-connect-prd/rules.tf#L65), [dotcom](https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/blob/main/environments/gprd/cloudflare-about-gitlab-com.tf#L44), [ops](https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/blob/main/environments/ops/cloudflare-rate-limits-waf-and-rules.tf#L10)) to create WAF rules for zones hosted in Cloudflare. There are also uses of Cloudflare terraform resources directly from across our infrastructure (e.g. [dotcom](https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/blob/main/environments/gprd/cloudflare-transform-rules.tf), [instrumentor](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/instrumentor/-/blob/main/aws/onboard/domains.tf?ref_type=heads#L48), [amp](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/amp/-/blob/main/modules/cloudflare/main.tf?ref_type=heads#L8)). Additionally, we have had requests for Cloudflare implementations from internal customers who otherwise need to build implementations themselves. This presents a risk, where multiple disparate implementations can cause confusion and additional maintenance burden. We want to empower our engineers to use our preferred Edge networking provider, Cloudflare, and to do so in a supported and maintainable manner. ### Background As we move to a more mature GitLab platform in which we standardize all the GitLab offerings, we should standardize on our manage of Cloudflare. This will provide us with a single point to make changes across our Cloudflare IaC estate, allowing for a faster response to security threats, compliance risks and feature requirements. By providing a "golden path" Cloudflare entrypoint we'll also be well positioned to simplify Cloudflare implementation for our internal customers. This directly aligns with the team's mission and vision to provide excellence in our networking infrastructure, with a focus on ongoing, sustainable maintenance. We want to ensure that our internal customers are able to leverage our expertise in Cloudflare configuration to configure the edge of our infrastructure for their use-case. This also aligns with our overall platform strategy, providing a consistently compliant and secure edge for our platform. By focusing on testing and documentation for all internal audiences we will also help reduce the amount of ongoing maintenance required to operate our edge network by allowing users to self-serve usage and upgrades of their Cloudflare usages. This also provides a single place for us to perform the upgrades required to the Cloudflare v5 provider. This helps us to de-risk the upgrade and provide a smoother, more iterative upgrade process for our customers. ### Exit Criteria - [x] A [design document](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cloudflare-standardization/) exists describing the interfaces and design principles for a terraform-based Cloudflare module set - [x] A common terraform entrypoint is available for Cloudflare consumers - [x] Modules implementing common subsets of Cloudflare functionality exist, e.g. DNS, WAF - [x] The modules are being consumed by our internal customers - We will primarily focusing on adopting these modules in our existing `config-mgmt` usages - [x] Operator and consumer documentation exists for the modules - [x] All modules have implemented comprehensive testing, reducing risk and future maintenance burden ## DRI @jcstephenson ### Participants - @ayeung - @donnaalexandra - @sarahwalker #### Decision Log <details> [2025-07-07: Move the canonical for modules to `gitlab.com` instance](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/27036#note_2609013555) </details> ## Issue admin ``` /epic https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1561 /label ~"group::Foundations" ~"workflow-infra::Triage" ~"Foundations::Project work" ``` <!-- STATUS NOTE START --> ## Status 2025-09-16 We've complete the remaining exit criteria for this project over the past week, safely applying changes across `gstg`, `ops` and `gprd`, whilst completing our initial documentation. See our [closing status update](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1561#note_2758792531) for more details. :tada: **achievements:** - :chart_with_upwards_trend: Migrate the WAF configurations for `gstg`, `ops` and `gprd` environments to the `entrypoint` module, completing the internal adoption. - :google_docs: Complete initial operator and user documentation - :checkered_flag: See [closing status update](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1561#note_2758792531) :tada: _Copied from https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1561#note_2752674212_ <!-- STATUS NOTE END -->