Using the GitLab Pages chart

The gitlab-pages subchart provides a daemon for serving static websites from GitLab projects.

Requirements

This chart depends on access to the Workhorse services, either as part of the complete GitLab chart or provided as an external service reachable from the Kubernetes cluster this chart is deployed onto.

Configuration

The gitlab-pages chart is configured as follows: Global settings and Chart settings.

Global Settings

We share some common global settings among our charts. See the Globals Documentation for details.

Chart settings

The tables in following two sections contains all the possible chart configurations that can be supplied to the helm install command using the --set flags.

General settings

Pages specific settings

Configuring the ingress

This section controls the GitLab Pages Ingress.

Chart configuration examples

extraVolumes

extraVolumes allows you to configure extra volumes chart-wide.

Below is an example use of extraVolumes:

extraVolumes: |
  - name: example-volume
    persistentVolumeClaim:
      claimName: example-pvc

extraVolumeMounts

extraVolumeMounts allows you to configure extra volumeMounts on all containers chart-wide.

Below is an example use of extraVolumeMounts:

extraVolumeMounts: |
  - name: example-volume
    mountPath: /etc/example

Configuring the networkpolicy

This section controls the NetworkPolicy. This configuration is optional and is used to limit Egress and Ingress of the Pods to specific endpoints.

Example Network Policy

The gitlab-pages service requires Ingress connections for port 80 and 443 and Egress connections to various to default workhorse port 8181. This example adds the following network policy:

• Allows Ingress requests:
  • From the nginx-ingress pod to port 8090
  • From the prometheus pod to port 9235
• Allows Egress requests:
  • To kube-dns on port 53
  • To the webservice pod to port 8181
  • To endpoints like AWS VPC endpoint for S3 172.16.1.0/24 on port 443

Note the example provided is only an example and may not be complete

The example is based on the assumption that kube-dns was deployed to the namespace kube-system, prometheus was deployed to the namespace monitoring and nginx-ingress was deployed to the namespace nginx-ingress.

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: monitoring
            podSelector:
              matchLabels:
                app: prometheus
                component: server
                release: gitlab
        ports:
          - port: 9235
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: nginx-ingress
            podSelector:
              matchLabels:
                app: nginx-ingress
                component: controller
        ports:
          - port: 8090
  egress:
    enabled: true
    rules:
      - to:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: kube-system
            podSelector:
              matchLabels:
                k8s-app: kube-dns
        ports:
          - port: 53
            protocol: UDP
      - to:
          - ipBlock:
              cidr: 172.16.1.0/24
        ports:
          - port: 443
      - to:
          - podSelector:
              matchLabels:
                app: webservice
        ports:
          - port: 8181

TLS access to GitLab Pages

To have TLS access to the GitLab Pages feature you must:

1. Create a dedicated wildcard certificate for your GitLab Pages domain in this format: *.pages.<yourdomain>.

2. Create the secret in Kubernetes:

   kubectl create secret tls tls-star-pages-<mysecret> --cert=<path/to/fullchain.pem> --key=<path/to/privkey.pem>

3. Configure GitLab Pages to use this secret:

   gitlab:
     gitlab-pages:
       ingress:
         tls:
           secretName: tls-star-pages-<mysecret>

4. Create a DNS entry in your DNS provider with the name *.pages.<yourdomaindomain> pointing to your LoadBalancer.

Pages domain without wildcard DNS

1. Enable namespaceInPath in the global Pages settings.

   global:
     pages:
       namespaceInPath: true

2. Create a DNS entry in your DNS provider with the name pages.<yourdomaindomain> pointing to your LoadBalancer.

TLS access to GitLab Pages domain without wildcard DNS

1. Create a certificate for your GitLab Pages domain in this format: pages.<yourdomain>.

2. Create the secret in Kubernetes:

   kubectl create secret tls tls-star-pages-<mysecret> --cert=<path/to/fullchain.pem> --key=<path/to/privkey.pem>

3. Configure GitLab Pages to use this secret:

   gitlab:
     gitlab-pages:
       ingress:
         tls:
           secretName: tls-star-pages-<mysecret>

Configure access control

1. Enable accessControl in the global pages settings.

   global:
     pages:
       accessControl: true

2. Optional. If TLS access is configured, update the redirect URI in the GitLab Pages System OAuth application to use the HTTPS protocol.

Rate limits

You can enforce rate limits to help minimize the risk of a Denial of Service (DoS) attack. Detailed rate limits documentation is available.

To allow certain IP ranges (subnets) to bypass all rate limits:

• rateLimitSubnetsAllowList: Sets the allow list with the IP ranges (subnets) that should bypass all rate limits.

Configure rate limits subnets allow list

Set the allow list with the IP ranges (subnets) in charts/gitlab/charts/gitlab-pages/values.yaml:

gitlab:
  gitlab-pages:
    rateLimitSubnetsAllowList:
     - "1.2.3.4/24"
     - "2001:db8::1/32"

Configuring KEDA

This keda section enables the installation of KEDA ScaledObjects instead of regular HorizontalPodAutoscalers. This configuration is optional and can be used when there is a need for autoscaling based on custom or external metrics.

Most settings default to the values set in the hpa section where applicable.

If the following are true, CPU and memory triggers are added automatically based on the CPU and memory thresholds set in the hpa section:

• triggers is not set.
• The corresponding request.cpu.request or request.memory.request setting is also set to a non-zero value.

If no triggers are set, the ScaledObject is not created.

Refer to the KEDA documentation for more details about those settings.

serviceAccount

This section controls if a ServiceAccount should be created and if the default access token should be mounted in pods.

affinity

For more information, see affinity.