Ascode Blog

GitLab CI/CD for Cloudflare Pages: Automated Deployments with Preview Environments

2026-01-30T00:00:00Z

Remember when the previous post ended with "Automating deployments — When I find some more time..."? Well, I found the time. Let me walk you through how I set up a GitLab CI/CD pipeline that deploys this website to Cloudflare Pages, complete with preview environments on merge requests.

The Goal

Simple:

Push to a branch, create a merge request → preview deploy on a unique URL
Merge to main → production deploy to ascode.nl
No manual steps. No clicking around in dashboards.

Prerequisites

You need two things from Cloudflare:

Account ID — find this on the sidebar of any zone in your Cloudflare dashboard
API Token — create one at dash.cloudflare.com/profile/api-tokens with these permissions:

Permission	Access
Account · Cloudflare Pages	Edit
Zone · Zone	Read

Add both as CI/CD variables in your GitLab project (Settings → CI/CD → Variables):

CLOUDFLARE_API_TOKEN — masked, protected
CLOUDFLARE_ACCOUNT_ID — masked, protected

Wrangler (the Cloudflare CLI) picks these up automatically, no extra configuration needed.

The Pipeline

The full .gitlab-ci.yml is surprisingly short. Two stages: build the static site with Eleventy, then deploy it with Wrangler.

Build Stage

stages:
  - build
  - deploy

variables:
  CLOUDFLARE_PROJECT_NAME: ascode-web
  NODE_VERSION: "20"

build:
  stage: build
  image: node:${NODE_VERSION}-alpine
  script:
    - npm ci
    - npx @11ty/eleventy
  artifacts:
    paths:
      - _site/
    expire_in: 1 hour
  rules:
    - if: $CI_MERGE_REQUEST_IID
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Nothing fancy. Install dependencies, run Eleventy, and pass the _site/ output as an artifact to the deploy stage. The rules ensure it runs on both merge requests and pushes to main.

Preview Deploys

This is where it gets nice:

deploy:preview:
  stage: deploy
  image: node:${NODE_VERSION}-alpine
  needs:
    - build
  script:
    - npx wrangler pages deploy _site/
        --project-name="${CLOUDFLARE_PROJECT_NAME}"
        --branch="${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}"
        --commit-hash="${CI_COMMIT_SHORT_SHA}"
  environment:
    name: preview/$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
    url: https://${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}.${CLOUDFLARE_PROJECT_NAME}.pages.dev
  rules:
    - if: $CI_MERGE_REQUEST_IID

Every merge request gets its own preview URL based on the branch name. Create a branch called new-blog-post, and you get https://new-blog-post.ascode-web.pages.dev. The GitLab environment link shows up directly in the merge request, so reviewers can click through to the preview without having to figure out the URL.

Wrangler handles everything — if the Cloudflare Pages project does not exist yet, it creates it. It uploads the files, configures the deployment, and gives you the URL. No need to pre-configure anything in the Cloudflare dashboard.

Stopping Preview Environments

When a merge request is merged or closed, the preview environment should be cleaned up in GitLab:

stop:preview:
  stage: deploy
  image: node:${NODE_VERSION}-alpine
  needs: []
  script:
    - echo "Preview environment stopped"
  environment:
    name: preview/$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_IID
      when: manual
      allow_failure: true

Note that this only stops the GitLab environment — the Cloudflare preview deployment itself stays around until Cloudflare cleans it up (they do, eventually). If you want to actively delete it, you can add a wrangler pages deployment delete command, but I have not found the need for that.

Production Deploy

deploy:production:
  stage: deploy
  image: node:${NODE_VERSION}-alpine
  needs:
    - build
  script:
    - npx wrangler pages deploy _site/
        --project-name="${CLOUDFLARE_PROJECT_NAME}"
        --branch="main"
        --commit-hash="${CI_COMMIT_SHORT_SHA}"
  environment:
    name: production
    url: https://ascode.nl
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Merge to main → deploys to production. That's it. The --branch="main" flag tells Cloudflare this is the production deployment, which means it goes live on your custom domain.

A Note on Wrangler and npx

You might notice I am using npx wrangler instead of installing it as a project dependency. This keeps the blog repository clean — Wrangler is a deployment tool, not a site dependency. The npx command downloads it on the fly in the CI environment, which adds a few seconds to the deploy stage but keeps package.json focused on what matters: Eleventy and its plugins.

If the download time bothers you, add wrangler to your devDependencies and it will be installed during npm ci in the build stage. Either way works.

The Result

The workflow is now:

Create a branch and write content
Push and open a merge request
Pipeline builds and deploys a preview — check the result
Merge to main
Pipeline deploys to production — live on ascode.nl

No more manual uploads to Cloudflare Pages. No more "when I find some more time." Just git push and go.

Building a Raspberry Pi5 Cluster with Talos Linux and Cilium

2025-10-23T00:00:00Z

You know when you want to have an environment to play with, test some things, and do some general tinkering around?

Of course you can run this on your laptop (Very Happy Macbook Pro M4 Max owner!) but where is the fun in that? So, I decided to build a Kubernetes cluster consisting of Raspberry Pi's. Now I am the kind of guy that does not go half way, so this cluster not only needs to be small and quiet, but also powerful. Which means I am building this with not a single Raspberry Pi board, but a full-fledged cluster with high-availability and everything.

Here is a picture of the end result:

Let me take you through how I build this!

Kit list

Click to view complete shopping list

For those of you that want to know and possibly want to build this themselves, here is the full kit list:

Item	Amount	Cost at time of writing of article	Total Cost	Where ordered?
Raspberry Pi 5 - 16GB	4	€ 131,50	€ 526	RaspberryPi Store
512GB Raspberry Pi NVMe SSD, 22x30mm	4	€ 54,95	€ 219,8	RaspberryPi Store
Sandisk 32Gb MicroSDHC Extreme PRO	1	€ 16,95	€ 16,95	RaspberryPi Store
Geekworm Cooler for Raspberry Pi 5, passive aluminum heatsink	4	€ 9	€ 36	Amazon
M.2 NVME M-Key and PoE+ HAT for RPi5	4	€ 36,29	€ 145,16	Kiwi El4ctronics
Ubiquiti UniFi Flex 2.5G PoE	1	€ 199,65	€ 199,65	KommaGo
Ubiquiti AC Adapter 210W	1	€ 105,88	€ 105,88	KommaGo
C4Labs 8-Slot Cloudlet Cluster Case	1	€ 72,74	€ 72,74	The Pi Hut

Grand total			€ 1249,44 incl. BTW

I realize this list does not fit everyone's budget, but it is what I went with. Yes, you could get a cheaper PoE switch, but I love Ubiquiti and it is my go-to choice for networking gear. You could get Raspberry Pi4 with just SD Cards in stead of SSD's, of course you can! That is the beauty of these projects, you can do it however you want! In this case, this is my blog and my project so this is what I used.

The cluster case I ordered from a company in the UK, and if you are not located in the UK then, it gets a bit more expensive - like a lot more expensive. That was a bit of an oversight from my part, there is a good alternative here: https://www.amazon.com/GeeekPi-Cabinet-Equipment-RackMate-Rackmount/dp/B0DPGZPTPP?th=1. I don't own a 3D printer but if you do, there are some very good cluster cases out there for you to print yourself. I also removed the fans from the case cause I hate noise - that is where the passive heatsink comes in.

Lastly I had to purchase some network cables to make it all look nice.

Putting it all together

Installing Talos

For those of you that are unfamiliar with Talos: Talos is a Linux distro that is optimized for Kubernetes and is secure, immutable and minimal by default, limiting your Kubernetes attack surface. All system management is done via an API - there is no shell or interactive console.

If you are interested in the philosophy behind this, have a read here.

Installing Talos was a little less easy than I expected, mainly because the Raspberry Pi5 is not officially supported yet. Here is an overview of the (non-Pi5) supported Raspberry Pi series: (https://docs.siderolabs.com/talos/v1.11/platform-specific-installations/single-board-computers/rpi_generic). After a quick search I found a Github repo here that ported the offial Talos image to work on Raspberry Pi5. Give them a star to support their work!

Preparing the Raspberry Pi

I had a previous Raspberry Pi OS Lite installed with K3S so my Pi had to be cleared out first:

sudo umount /dev/nvme0n1p?
sudo wipefs --all --force /dev/nvme0n1p?
sudo wipefs --all --force /dev/nvme0n1
sudo dd if=/dev/zero of=/dev/nvme0n1 bs=1024 count=1

Also, you want to make sure the boot order is changed so that the Pi attempts NVMe boot first. This does assume you already have an OS on your Pi5:

# Open the Raspberry Pi configuration editor
sudo raspi-config

# Navigate to Advanced Options > Boot > Boot Order
# Highlight 'NVMe/USB Boot' and press enter
# Follow the prompts

When you do not have an OS on your Pi5 yet, you can flash your SD card using the Raspberry Pi Imager. For OS, choose Misc utility images, Bootloader (Pi5 Family), NVMe/USB Boot and start your Pi5 using this card. Once the green light flashes, the Pi5 is configured to boot from NVMe first.

Flashing the OS to an SD Card

On a side note, make sure you use specific fast SD cards as the Pi5 does not like slow cards. The type from the shopping list is good. On another note, I used 1 card. You can get more cards if you are impatient and do not want to re-flash in between tasks.

Here is where it gets a little more interesting. You would think that we flash the Talos OS onto the SD card, right? Well, no, we don't. After spending quite a few hours, I found out that even when you select the NVMe card as the install disk, it just would not install to it. Here is the associated Talos config (that, to be clear, did not work for me):

machine:
  install:
    disk: /dev/nvme0n1 # The disk used for installations.
    image: ghcr.io/siderolabs/installer:v1.11.1 # Allows for supplying the image used to perform the installation.
    wipe: true # Indicates if the installation disk should be wiped at installation time.

I worked around the problem by flashing the SD Card with Raspberry Pi OS using the Raspberry Pi Imager Raspberry Pi OS (other), Raspberry Pi OS Lite (64 bit).

I then used this card to boot the first Pi into Pi OS and then downloading the Talos OS:

curl -LO https://github.com/talos-rpi5/talos-builder/releases/download/v1.11.1-pre/metal-arm64.raw.zst
unzstd metal-arm64.raw.zst

You only need to do this once. Make sure you set the hostname and then use the downloaded image to flash your NVMe disk. Repeat this on each of your nodes:

sudo hostnamectl set-hostname rpi5-1
sudo dd if=metal-arm64.raw of=/dev/nvme0n1 bs=4M status=progress

Make sure you set a unique hostname for each node! Shutdown the node after this step is complete, remove the SD card and power on the node again; it should now boot from the SSD drive.

Preparing Talos Config

To perform any kind of management on Talos, you need to communicate (securely) with the API. In this blog, I use talosctl for management.

brew install siderolabs/tap/talosctl

Once you have talosctl installed, we can create the config to deploy the cluster. We are going to install Cilium, for which we need a Talos Patch to prepare Talos for it. Specifically, no cni should be enabled and kube-proxy will be disabled as it will be replaced by Cilium. The last line will allow workloads to be scheduled on control plane nodes, which is fine for this lab environment but in a production environment maybe not such a good idea.

> cat <<EOF > ./cilium-patch.yaml
  machine:
    install:
      disk: /dev/nvme0
      image: ghcr.io/siderolabs/installer:v1.11.3
      wipe: true
    network:
      interfaces:
      - deviceSelector:
          physical: true
        dhcp: true
  # view more in the complete command sequence

Click to see the complete command sequence

cat <<EOF > ./cilium-patch.yaml
  machine:
    install:
      disk: /dev/nvme0
      image: ghcr.io/siderolabs/installer:v1.11.3
      wipe: true
    network:
      interfaces:
      - deviceSelector:
          physical: true
        dhcp: true
        vip:
          ip: 10.10.10.15
  cluster:
    network:
      cni:
        name: none
    proxy:
      disabled: true
  allowSchedulingOnControlPlanes: true
EOF

export CONTROL_PLANE_IP=10.10.10.11
mkdir _out
talosctl gen config talosrpi5 https://$CONTROL_PLANE_IP$:6443 --output-dir _out --config-patch @cilium-patch.yaml

This will create 3 files in the _out directory:

talosconfig - this is the unique context for your cluster that contains the certificates for authentication
controlplane.yaml - for configuring control plane nodes
worker.yaml - for configuring worker nodes

⚠️ Note: You want your cluster nodes to have a fixed IP address. I found out that starting with DHCP and then setting a fixed IP as part of configuration basically broke the setup. The solution was to make a DHCP reservation for each node in your cluster, making sure that the nodes will always get the same IP address from DHCP.

Install Talos on the first node

We are now ready to configure the first cluster node. Make sure the node is up and has the correct IP address; if you hooked up a display to your RPi then you should see this on screen.

export CONTROL_PLANE_IP=10.10.10.11
talosctl apply-config --insecure --nodes $CONTROL_PLANE_IP --file _out/controlplane.yaml
export TALOSCONFIG="_out/talosconfig"
talosctl config endpoint $CONTROL_PLANE_IP
talosctl config node $CONTROL_PLANE_IP
talosctl bootstrap ## <-- this command only needs to be run ONCE on a control plane node!

If all went well, you can use talosctl health to check the status of your Talos cluster. Get the Kubernetes config using the following command:

talosctl kubeconfig --nodes $CONTROL_PLANE_IP
kubectl get nodes

# you should see something like this
NAME     STATUS   ROLES           AGE   VERSION
rpi5-1   Ready    control-plane   1h    v1.34.0

Install Talos on other nodes

I would recommend to take care of Cilium first, then install the rest of the nodes.

Install Cilium

For those of you that are unfamiliar with Cilium: Cilium is an open-source, eBPF-based networking, security, and observability platform designed for cloud-native environments such as Kubernetes clusters and containerized workloads. Cilium operates as a Container Network Interface (CNI) and provides an advanced, kernel-native framework for container networking, combining eBPF-based performance, granular security, and deep observability.

Start by installing the Cilium CLI as described on https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli

Next I am going to use Helm to install Cilium onto the cluster using Terraform (actually, I used OpenTofu). For a complete list of values and how to further customize the Helm deployment, look here

terraform {
  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = ">= 2.38.0"
    }
    helm = {
      source  = "hashicorp/helm"
      version = ">= 3.0.2"
    }
  }
  required_version = ">= 1.10.0"
}
# view more in the complete command sequence

Click to see the complete Terraform configuration with all Helm values

terraform {
  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = ">= 2.38.0"
    }
    helm = {
      source  = "hashicorp/helm"
      version = ">= 3.0.2"
    }
  }
  required_version = ">= 1.10.0"
}

provider "kubernetes" {
  config_path = "~/.kube/config"
}

provider "helm" {
  kubernetes = {
    config_path = "~/.kube/config"
  }
}

resource "helm_release" "cilium" {
  chart            = "cilium"
  name             = "cilium"
  repository       = "https://helm.cilium.io/"
  version          = "1.18.2"
  create_namespace = false
  namespace        = "kube-system"

  set = [
    {
      name  = "ipam.mode"
      value = "kubernetes"
    },
    {
      name  = "kubeProxyReplacement"
      value = "true"
    },
    {
      name  = "securityContext.capabilities.ciliumAgent"
      value = "{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}"
    },
    {
      name  = "securityContext.capabilities.cleanCiliumState"
      value = "{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}"
    },
    {
      name  = "cgroup.autoMount.enabled"
      value = false
    },
    {
      name  = "cgroup.hostRoot"
      value = "/sys/fs/cgroup"
    },
    {
      name  = "k8sServiceHost"
      value = "localhost"
    },
    {
      name  = "k8sServicePort"
      value = 7445
    },
    {
      name  = "gatewayAPI.enabled"
      value = true
    },
    {
      name  = "gatewayAPI.enableAlpn"
      value = true
    },
    {
      name  = "gatewayAPI.enableAppProtocol"
      value = true
    }
  ]
}

If you want to check what versions are available for Cilium, run the following commands:

helm repo add cilium https://helm.cilium.io/
helm search repo cilium --versions

</div>

```bash
# results are something like this
NAME            CHART VERSION   APP VERSION     DESCRIPTION
cilium/cilium   1.18.2          1.18.2          eBPF-based Networking, Security, and Observability
cilium/cilium   1.18.1          1.18.1          eBPF-based Networking, Security, and Observability
cilium/cilium   1.18.0          1.18.0          eBPF-based Networking, Security, and Observability
...

Apply the Terraform code and wait for Cilium to be fully deployed. This can take a bit, be patient.

You can check the status of deployment with either kubectl or the cilium cli.

Install Talos on other nodes

Now that Cilium is installed, we can install the other Talos nodes. When you install Cilium straight after the first Talos node is deployed, the rest of the nodes automatically have the correct Cilium config.

Because of etcd cluster quorum (a two-node etcd cluster is not high availability (HA) because if one node is lost, the cluster will have quorum loss and enter read-only mode), we are going to deploy a total of 3 control plane nodes (hence the allowSchedulingOnControlPlanes: true config, otherwise we would only have 1 worker node on which to deploy workloads).

CONTROL_PLANE_IP=("10.10.10.12" "10.10.10.13")
WORKER_IP="10.10.10.14"
for ip in "${CONTROL_PLANE_IP[@]}"; do
  echo "Applying config to worker node: $ip"
  talosctl apply-config --insecure --nodes "$ip" --file _out/controlplane.yaml
done
talosctl apply-config --insecure --nodes "${WORKER_IP}" --file _out/worker.yaml

The end result will be a 4-node Talos cluster that looks something like this:

kubectl get nodes

NAME     STATUS   ROLES           AGE   VERSION
rpi5-1   Ready    control-plane   1h    v1.34.0
rpi5-2   Ready    control-plane   1h    v1.34.0
rpi5-3   Ready    control-plane   1h    v1.34.0
rpi5-4   Ready    <none>          1h    v1.34.0

> cilium status

    /¯¯\
 /¯¯\__/¯¯\    Cilium:             OK
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    OK
 \__/¯¯\__/    Hubble Relay:       disabled
    \__/       ClusterMesh:        disabled

# view more in the complete command sequence

Click to see complete cluster status and pod listings

kubectl get nodes

NAME     STATUS   ROLES           AGE   VERSION
rpi5-1   Ready    control-plane   1h    v1.34.0
rpi5-2   Ready    control-plane   1h    v1.34.0
rpi5-3   Ready    control-plane   1h    v1.34.0
rpi5-4   Ready    <none>          1h    v1.34.0

cilium status

    /¯¯\
 /¯¯\__/¯¯\    Cilium:             OK
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    OK
 \__/¯¯\__/    Hubble Relay:       disabled
    \__/       ClusterMesh:        disabled

DaemonSet              cilium                   Desired: 4, Ready: 4/4, Available: 4/4
DaemonSet              cilium-envoy             Desired: 4, Ready: 4/4, Available: 4/4
Deployment             cilium-operator          Desired: 2, Ready: 2/2, Available: 2/2
Containers:            cilium                   Running: 4
                       cilium-envoy             Running: 4
                       cilium-operator          Running: 2
                       clustermesh-apiserver
                       hubble-relay
Cluster Pods:          20/20 managed by Cilium
Helm chart version:    1.18.2
Image versions         cilium             quay.io/cilium/cilium:v1.18.2@sha256:858f807ea4e20e85e3ea3240a762e1f4b29f1cb5bbd0463b8aa77e7b097c0667: 4
                       cilium-envoy       quay.io/cilium/cilium-envoy:v1.34.7-1757592137-1a52bb680a956879722f48c591a2ca90f7791324@sha256:7932d656b63f6f866b6732099d33355184322123cfe1182e6f05175a3bc2e0e0: 4
                       cilium-operator    quay.io/cilium/operator-generic:v1.18.2@sha256:cb4e4ffc5789fd5ff6a534e3b1460623df61cba00f5ea1c7b40153b5efb81805: 2

talosctl health
discovered nodes: ["10.10.10.11" "10.10.10.12" "10.10.10.13" "10.10.10.14"]
waiting for etcd to be healthy: ...
waiting for etcd to be healthy: OK
waiting for etcd members to be consistent across nodes: ...
waiting for etcd members to be consistent across nodes: OK
waiting for etcd members to be control plane nodes: ...
waiting for etcd members to be control plane nodes: OK
waiting for apid to be ready: ...
waiting for apid to be ready: OK
waiting for all nodes memory sizes: ...
waiting for all nodes memory sizes: OK
waiting for all nodes disk sizes: ...
waiting for all nodes disk sizes: OK
waiting for no diagnostics: ...
waiting for no diagnostics: OK
waiting for kubelet to be healthy: ...
waiting for kubelet to be healthy: OK
waiting for all nodes to finish boot sequence: ...
waiting for all nodes to finish boot sequence: OK
waiting for all k8s nodes to report: ...
waiting for all k8s nodes to report: OK
waiting for all control plane static pods to be running: ...
waiting for all control plane static pods to be running: OK
waiting for all control plane components to be ready: ...
waiting for all control plane components to be ready: OK
waiting for all k8s nodes to report ready: ...
waiting for all k8s nodes to report ready: OK
waiting for kube-proxy to report ready: ...
waiting for kube-proxy to report ready: SKIP
waiting for coredns to report ready: ...
waiting for coredns to report ready: OK
waiting for all k8s nodes to report schedulable: ...
waiting for all k8s nodes to report schedulable: OK

kubectl get pods -A

NAMESPACE       NAME                                               READY   STATUS    RESTARTS      AGE
kube-system     cilium-9tff5                                       1/1     Running   0             1h
kube-system     cilium-envoy-f8z4f                                 1/1     Running   o             1h
kube-system     cilium-envoy-jnj94                                 1/1     Running   0             1h
kube-system     cilium-envoy-qdwcn                                 1/1     Running   o             1h
kube-system     cilium-envoy-ww9pq                                 1/1     Running   o             1h
kube-system     cilium-kxkxb                                       1/1     Running   0             1h
kube-system     cilium-mvggt                                       1/1     Running   0             1h
kube-system     cilium-operator-54d6f6cccb-bkn8k                   1/1     Running   0             1h
kube-system     cilium-operator-54d6f6cccb-cdvz9                   1/1     Running   0             1h
kube-system     cilium-w9fvm                                       1/1     Running   0             1h
kube-system     coredns-7bb49dc74c-nbrd2                           1/1     Running   0             1h
kube-system     coredns-7bb49dc74c-xjkw8                           1/1     Running   0             1h
kube-system     kube-apiserver-rpi5-1                              1/1     Running   0             1h
kube-system     kube-apiserver-rpi5-2                              1/1     Running   0             1h
kube-system     kube-apiserver-rpi5-3                              1/1     Running   0             1h
kube-system     kube-controller-manager-rpi5-1                     1/1     Running   0             1h
kube-system     kube-controller-manager-rpi5-2                     1/1     Running   0             1h
kube-system     kube-controller-manager-rpi5-3                     1/1     Running   0             1h
kube-system     kube-scheduler-rpi5-1                              1/1     Running   0             1h
kube-system     kube-scheduler-rpi5-2                              1/1     Running   0             1h
kube-system     kube-scheduler-rpi5-3                              1/1     Running   0             1h

What's next?

Now that Talos and Cilium are ready, start deploying other services to your cluster. Think about ArgoCD, cert-manager, external-dns or get an intro to what Cilium can actually do with the Star Wars Demo.

Have fun!

Self-hosted Gitlab Runners on AKS, with Managed Identities

2025-09-30T00:00:00Z

This post is long overdue, I've been meaning to write this for a long time but did not get around to doing it. So here goes!

The code used in this post is located in https://gitlab.com/ascodenl/gitlab-runner-aks

The great thing about using Managed Identities in Azure is that they cannot be (ab)used to run elsewhere, like Service Principals can. Yes, you can use workload identities conditional access policies nowadays, but SP's are basically just another username/password combination that can be abused for other purposes than they were meant for. Managed Identities are a special type of Service Principal (which is an Azure Enterprise Application Registration under the hood) that can only be used when attached to an Azure resource. When connected to a Kubernetes service account, the managed identity permissions can be assumed by the pod that has that service account attached. This allows for fine-grained permissions for specific purposes, for specific Gitlab runners. For example, a runner that is purpose-built for building container images that pushes to Azure Container Registry - using a Managed Identity that only has the AcrPush permission on the ACR(s) it needs to push to.

The case for self-hosted Gitlab Runners

"Why not use the Gitlab provided runners"? I hear that quite often. In summary, self-hosted GitLab runners are ideal when you need maximum control, security, and flexibility for your CI/CD jobs, want to optimize costs at scale, or have specific compliance and infrastructure requirements that (what Gitlab calls) Instance runners cannot meet. Yes, it requires maintenance but it outweighs the added benefits - especially in environments with heavy compliance requirements like the Financial industry.

Slightly more detailed, for several reasons:

1. Full Control Over the Build Environment

Self-hosted runners give complete control over the (virtual) hardware, operating system, and software installed on the machines (in our case, Kubernetes) running CI/CD jobs. This allows you to customize environments to match your production setup, install proprietary or legacy tools, and fine-tune performance for specific workloads.

2. Security and Compliance

By running jobs on your own infrastructure, you can ensure sensitive code and data never leave your network. This is especially important for organizations with strict compliance, data residency, or privacy requirements, such as those in the public sector.
Self-hosted runners can be placed behind firewalls or VPNs, further reducing exposure to potential threats.

3. Cost Efficiency and Scalability

For teams with high CI/CD usage, self-hosted runners can be more cost-effective than paying for shared or cloud-hosted runners, especially at scale. You avoid per-minute billing and can utilize existing cloud resources as needed.
You can scale your runners as your needs grow.

4. Performance and Flexibility

Self-hosted runners can be optimized for your specific workloads, providing faster builds and more reliable performance than shared runners.
You can run jobs on specialized hardware (e.g., GPUs, large-memory machines) or in specific environments (e.g., on-premises, in particular cloud regions) that aren't available with GitLab-hosted runners.

5. Advanced Customization

You can create custom caching strategies, use local Docker registries, or integrate with internal systems and services that aren't accessible from public runners.
Self-hosted runners allow for advanced monitoring, logging, and debugging, giving greater visibility into CI/CD processes.

Types of runners

Gitlab has 3 types of runners:

Instance runners: Shared runners that are built, deployed and managed by Gitlab for generic use.
Group runners: Deployed on Gitlab group level, inherited by all repositories (projects) that are part of that group. Self-hosted and self- managed.
Project runners: Deployed on a single repository. Self-hosted and self-managed.

Types of runtime environments

When registering a GitLab runner, you must select an executor, which determines the environment in which your CI/CD jobs will run. Each executor offers different levels of isolation, scalability, and compatibility, making them suitable for various scenarios.

Executor	Isolation	Typical Use Case	Pros	Cons
Shell	Low	Simple, local jobs	Easy, minimal setup	Low isolation, less secure
Docker	High	Reproducible, isolated builds	Clean, scalable, supports services	Needs Docker, some limits
Docker Autoscaler	High	Scalable cloud builds	Auto-scales, cloud support	Complex setup
Instance	Very High	Full VM per job, high isolation	Max isolation, flexibility	Resource intensive
Kubernetes	High	Cloud-native, Kubernetes environments	Scalable, cloud integration	Needs Kubernetes
SSH	Varies	Remote, legacy, or custom environments	Remote execution	Limited support
VirtualBox/Parallels	High	VM-based isolation on local hardware	Good isolation	Slower, needs virtualization
Custom	Varies	Anything not covered above	Flexible	Requires custom scripts

Choosing the right executor depends on your project's requirements for isolation, scalability, environment, and available infrastructure.

Our default platform of choice is Kubernetes, this article covers the Azure implementation of Kubernetes called Azure Kubernetes Service (AKS)

Creating infrastructure in Azure (or any environment for that matter) is done using Infrastructure as Code (IaC). The tool of choice is Terraform or Tofu, whatever your preference. The idea is to let a CI/CD pipeline handle the creating, updating and destruction of Azure resources, using Gitlab Runners on AKS. For this, we need several resources to make that happen.

Here is a quick overview of what we are building:

Azure configuration

The runner will use a Kubernetes Service account, which is "connected" to an Azure Managed Identity, that will be assigned roles with permissions to create resources in Azure. You will need an AKS cluster with OIDC issuer enabled. Read here how to enable if not configured yet.

The Managed Identity is created as a separate resource outside of any Terraform Module. The main reason for this is, we use RBAC to assign permissions on Azure Resources. If you want to allow a Managed Identity access to Entra ID (to read groups, primarily), assigning permissions in Entra ID requires elevated privileges that we do not want to delegate to a Managed Identity. To prevent (re)creation of a Managed Identity as part of a module, we create it separately.

locals {
  runners = {
    tf = {
      environment      = "ss"
      environment_long = "shared"
      runner_type      = "group_type"
      runner_tags      = ["azure", "platform", "ss"]
      repo_path        = "ascodenl/infra"
      run_privileged   = "true"
      purpose          = "Runner for deploying Terraform resources in the Azure Landing Zone using Gitlab"
    }
# view more in the complete command sequence

Click to see complete Terraform code

locals {
  runners = {
    tf = {
      environment      = "ss"
      environment_long = "shared"
      runner_type      = "group_type"
      runner_tags      = ["azure", "platform", "ss"]
      repo_path        = "ascodenl/infra"
      run_privileged   = "true"
      purpose          = "Runner for deploying Terraform resources in the Azure Landing Zone using Gitlab"
    }
    packer = {
      environment      = "ss"
      environment_long = "shared"
      runner_type      = "project_type"
      runner_tags      = ["infra-packer-azure", "ss"]
      repo_path        = "ascodenl/infra/base-images/azure"
      run_privileged   = "true"
      purpose          = "Gitlab runner for deploying Custom images to Shared Imaged Gallery using Packer in Azure"
    }
  }
}

resource "azurerm_user_assigned_identity" "gitlab_runner" {
  for_each            = local.runners
  name                = "${each.value.region_code}-${each.value.environment}-msi-gitlab-${each.key}"
  resource_group_name = azurerm_resource_group.gitlab[each.value.region_code].name
  location            = azurerm_resource_group.gitlab[each.value.region_code].location
  tags = merge(local.tags, {
    purpose = each.value.purpose
  })
  lifecycle {
    ignore_changes = [tags["CreatedOnDateTime"]]
  }
}

##
## Create the MSGraph application
##

data "azuread_application_published_app_ids" "well_known" {}

resource "azuread_service_principal" "msgraph" {
  client_id    = data.azuread_application_published_app_ids.well_known.result.MicrosoftGraph
  use_existing = true
}

##
## Assign the Permissions in Entra ID
##

resource "azuread_app_role_assignment" "gitlab_api_permissions" {
  for_each            = toset(["Group.Read.All", "User.Read.All", "GroupMember.Read.All", "Directory.Read.All"])
  app_role_id         = azuread_service_principal.msgraph.app_role_ids[each.key]
  principal_object_id = azurerm_user_assigned_identity.gitlab_runner["tf"].principal_id
  resource_object_id  = azuread_service_principal.msgraph.object_id
}

##
## Create a federated credential
##

resource "azurerm_federated_identity_credential" "gitlab_runner" {
  for_each            = local.runners
  name                = "ascode-${each.value.environment_long}-msi-gitlab-${each.key}-cred"
  resource_group_name = azurerm_resource_group.gitlab.name
  audience            = ["api://AzureADTokenExchange"]
  issuer              = module.aks.oidc_issuer_url
  parent_id           = azurerm_user_assigned_identity.gitlab_runner[each.key].id
  subject             = "system:serviceaccount:${module.runners[each.key].k8s_sa_namespace}:${module.runners[each.key].k8s_sa_name}"
}

##
## Assign permissions in Azure
##

# MSI is owner on all subscriptions
resource "azurerm_role_assignment" "gitlab_runner_platform_owner" {
  for_each             = local.subscription_id
  scope                = "/subscriptions/${each.value}"
  role_definition_name = "Owner"
  principal_id         = azurerm_user_assigned_identity.gitlab_runner["tf"].principal_id
}

Note that we make the MSI specific to deploying Terraform resources (azurerm_user_assigned_identity.gitlab_runner["tf"].principal_id) owner of the subscriptions. Contributor is not going to be enough as we also want to use the pipeline to do role assignments and RBAC, therefor it needs owner permissions.

⚠️ Warning: This means that this MSI has very powerful privileges! Make sure you lock down your pipelines so that not just anyone can run them and make sure you do proper Merge Requests and code reviews!

Kubernetes resources

Remember we are using Kubernetes as the Gitlab Executor. What we are deploying is what can be described as a "runner manager", which will spin off containers (pods, actually) that will run the pipeline. Once the pipeline is finished, the pod is destroyed.

The Gitlab Runner is deployed using Helm. Gitlab maintains a Helm chart that you can find on https://gitlab.com/gitlab-org/charts/gitlab-runner/.

Gitlab Runner configuration is done in a config.toml file that we deploy using a template.

gitlabUrl: "${gitlab_url}"
unregisterRunners: true
terminationGracePeriodSeconds: 3600
concurrent: 10
checkInterval: 30
serviceAccountName: ${rbac_service_account_name}
# view more in the complete configuration

Click to see GitLab Runner Helm Values Configuration

gitlabUrl: "${gitlab_url}"
unregisterRunners: true
terminationGracePeriodSeconds: 3600
concurrent: 10
checkInterval: 30
serviceAccountName: ${rbac_service_account_name}
rbac:
  create: false
serviceAccountAnnotations: {
    azure.workload.identity/client-id: ${client_id},
    azure.workload.identity/tenant-id: ${tenant_id}
}
metrics:
  enabled: true
runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        pod_labels_overwrite_allowed = ".*"
        privileged = ${run_privileged}
        service_account = "${service_account_name}"
        namespace = "${runner_namespace}"
      [runners.kubernetes.pod_labels]
        "azure.workload.identity/use" = '"true"'
      [[runners.kubernetes.volumes.empty_dir]]
        name = "docker-certs"
        mount_path = "/certs/client"
        medium = "Memory"
  name: "${gitlab_name}"
  image: "${gitlab_docker_image}"
  privileged: ${run_privileged}
  serviceAccountName: ${service_account_name}
  pull_policy: always
  secret: "${runner_secret}"
securityContext:
  runAsUser: 100
deploymentLabels: {
  deployment_repository: ${deployment_repo_path}
}
podLabels: {
    azure.workload.identity/use: "true"
}

Then we use Terraform to tranform the template and deploy the Helm chart:

locals {
  gitlab_runner_vars = {
    gitlab_url                = var.gitlab_url
    gitlab_docker_image       = var.gitlab_docker_image
    gitlab_name               = "${var.environment}-k8-${var.runner_name}"
# view more in the complete chart

Click to see Terraform deploy Helm Chart

locals {
  gitlab_runner_vars = {
    gitlab_url                = var.gitlab_url
    gitlab_docker_image       = var.gitlab_docker_image
    gitlab_name               = "${var.environment}-k8-${var.runner_name}"
    run_privileged            = var.run_privileged
    service_account_name      = kubernetes_service_account_v1.gitlab_runner.metadata[0].name
    rbac_service_account_name = kubernetes_service_account_v1.gitlab_runner.metadata[0].name
    runner_namespace          = kubernetes_namespace_v1.gitlab.metadata[0].name
    client_id                 = var.mi_client_id
    tenant_id                 = var.tenant_id
    runner_secret             = kubernetes_secret_v1.gitlab_runner.metadata[0].name
    deployment_repo_path      = var.deployment_repo_path
  }
}

resource "helm_release" "gitlab_runner" {
  chart            = "gitlab-runner"
  name             = "${var.customer_tla}-${var.environment}-${var.runner_name}"
  namespace        = kubernetes_namespace_v1.gitlab.metadata[0].name
  repository       = "https://charts.gitlab.io"
  version          = var.gitlab_runner_helm_release_version
  create_namespace = false

  values = [
    templatefile("${path.module}/templates/runner-values.yml.tpl", local.gitlab_runner_vars)
  ]
}

To check for the latest version(s) of the chart:

helm repo add gitlab-runner https://charts.gitlab.io
helm repo update
helm search repo-l gitlab/gitlab-runner | head -5

The last part is to create the Kubernetes Service Account that "glues" the Managed Identity to the Gitlab Runner:

resource "kubernetes_service_account_v1" "gitlab_runner" {
  metadata {
    name      = "gitlab-runner-${random_id.this.hex}"
    namespace = kubernetes_namespace_v1.gitlab.metadata[0].name
    annotations = {
      "azure.workload.identity/client-id" = var.msi_client_id
      "azure.workload.identity/tenant-id" = var.tenant_id
    }
    labels = {
      "azure.workload.identity/use" = "true"
    }
  }
}

Finally some required Kubernetes resources to make this all work (I use rbac.create = false in the config.toml because I like to be in control of what is created. Setting this to true means you have to annotate the Service Account with the correct values as it gets auto-created).

resource "kubernetes_namespace_v1" "gitlab" {
  metadata {
    name = "gitlab-${random_id.this.hex}"
  }
}
# view more in the complete Kubernetes resources

Click to see Terraform Kubernetes resources

resource "kubernetes_namespace_v1" "gitlab" {
  metadata {
    name = "gitlab-${random_id.this.hex}"
  }
}

resource "kubernetes_role" "gitlab" {
  metadata {
    name      = "gitlab-runner-${random_id.this.hex}"
    namespace = kubernetes_namespace_v1.gitlab.metadata[0].name
  }
  rule {
    api_groups = [""]
    resources  = ["configmaps", "pods", "pods/attach", "secrets", "services", "namespaces"]
    verbs      = ["get", "list", "watch", "create", "patch", "update", "delete"]
  }
  rule {
    api_groups = [""]
    resources  = ["pods/exec"]
    verbs      = ["create", "patch", "delete"]
  }
  rule {
    api_groups = [""]
    resources  = ["serviceAccounts"]
    verbs      = ["get"]
  }
}

resource "kubernetes_role_binding_v1" "gitlab" {
  metadata {
    name      = "gitlab-runner-binding-${random_id.this.hex}"
    namespace = kubernetes_namespace_v1.gitlab.metadata[0].name
  }
  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Role"
    name      = kubernetes_role.gitlab.metadata[0].name
  }
  subject {
    kind      = "ServiceAccount"
    name      = kubernetes_service_account_v1.gitlab_runner.metadata[0].name
    namespace = kubernetes_namespace_v1.gitlab.metadata[0].name
  }
}

resource "kubernetes_cluster_role_binding_v1" "runner_admin" {
  metadata {
    name = "gitlab-runner-admin-${random_id.this.hex}"
  }
  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = "cluster-admin"
  }
  subject {
    kind      = "ServiceAccount"
    name      = kubernetes_service_account_v1.gitlab_runner.metadata[0].name
    namespace = kubernetes_namespace_v1.gitlab.metadata[0].name
  }
}

Runner registration

ℹ️ Note: This article describes the new way of registering runners. Please see https://docs.gitlab.com/ci/runners/new_creation_workflow/ how to migrate.

When deploying a runner, it needs to be registered against a group or repository. Each group or repository has its own unique token. You can do this from the CI/CD settings of the repository or group, create a project or group runner, fill in the details and out comes a registration token. But who wants do do manual? Let's automate this.

Terraform has a great provider for Gitlab, found on https://registry.terraform.io/providers/gitlabhq/gitlab/latest/docs. You can use it to fully automate your Gitlab environment, including repositories, groups, authorizations, integrations, etc. We'll focus on the gitlab_user_runner resource to get the registration token.

Each group or project in Gitlab has a unique id, whiich is hard to find and even harder to remember. We use the path to find the id, which is a lot easier to remember. If you use Terraform to also create your groups and projects, you can even reference the Terraform resource!

Terraform provider configuration is required for Gitlab and Kubernetes (the registration token is stored in a Kubernetes secret):

provider "kubernetes" {
  config_path = "~/.kube/config" # Need to create this file from the pipeline or run locally
}

provider "gitlab" {
  base_url = "https://gitlab.com/"
  token    = data.azurerm_key_vault_secret.gitlab_token.value # this can be a Group token or a PAT token with the create_runner scope
}

First, we need to determine if we are deploying a group runner or a project runner:

data "gitlab_group" "group" {
  count     = var.runner_type == "group_type" ? 1 : 0
  full_path = var.repo_path
}

data "gitlab_project" "project" {
  count               = var.runner_type == "project_type" ? 1 : 0
  path_with_namespace = var.repo_path
}

repo_path is the path to your repo, for example ascodenl/infra/tools.

Then, dependent on what type of runner you want, create a token and store it in a Kubernetes secret. Note the reference to a Kubernetes Service Account, this will become clear later on.

resource "gitlab_user_runner" "gitlab_runner_project" {
  count       = var.runner_type == "project_type" ? 1 : 0
  runner_type = var.runner_type
  description = "${kubernetes_service_account_v1.gitlab_runner.metadata[0].name}-${var.region_code}-aks"
# view more code below

Click to see Terraform Runner Token Creation

resource "gitlab_user_runner" "gitlab_runner_project" {
  count       = var.runner_type == "project_type" ? 1 : 0
  runner_type = var.runner_type
  description = "${kubernetes_service_account_v1.gitlab_runner.metadata[0].name}-${var.region_code}-aks"
  project_id  = data.gitlab_project.project[0].id
  tag_list    = flatten([[var.region_code], [var.runner_name], var.runner_tags])
  untagged    = var.run_untagged
}

resource "gitlab_user_runner" "gitlab_runner_group" {
  count       = var.runner_type == "group_type" ? 1 : 0
  runner_type = var.runner_type
  description = "${kubernetes_service_account_v1.gitlab_runner.metadata[0].name}-${var.region_code}-aks"
  group_id    = data.gitlab_group.group[0].id
  tag_list    = flatten([[var.region_code], [var.runner_name], var.runner_tags])
  untagged    = var.run_untagged
}

resource "kubernetes_secret_v1" "gitlab_runner" {
  metadata {
    name      = kubernetes_service_account_v1.gitlab_runner.metadata[0].name
    namespace = kubernetes_namespace_v1.gitlab.metadata[0].name
  }
  type = "Opaque"
  data = {
    runner-registration-token = "" # need to leave as an empty string for compatibility reasons
    runner-token              = var.runner_type == "project_type" ? gitlab_user_runner.gitlab_runner_project[0].token : gitlab_user_runner.gitlab_runner_group[0].token
  }
}

Using this in a Gitlab pipeline

Now that the runner is deployed with the proper permissions, it is time to create a pipeline to implement this in CI/CD.

Creating a full multi environment pipline is enough for a separate blog post, so here is the most important part:

before_script:
  - |
    if ! [ -x "$(command -v az)" ]; then
      echo -e "\e[33mWarn: az is not installed.\e[0m"
      exit 1
    else
      echo "Logging in to Azure using client_id $AZURE_CLIENT_ID..."
      az login --service-principal -u $AZURE_CLIENT_ID --tenant $AZURE_TENANT_ID --federated-token $(cat $AZURE_FEDERATED_TOKEN_FILE)
      if [[ ! -z ${ARM_SUBSCRIPTION_NAME} ]]; then az account set -n ${ARM_SUBSCRIPTION_NAME}; fi
      export ARM_OIDC_TOKEN=$(cat $AZURE_FEDERATED_TOKEN_FILE)
      export ARM_CLIENT_ID=$AZURE_CLIENT_ID
      export ARM_TENANT_ID=$AZURE_TENANT_ID
    fi

If OIDC is working correctly, the Azure token is stored in a file that is referenced in $AZURE_FEDERATED_TOKEN_FILE which usually points to /var/run/secrets/azure/tokens/azure-identity-token. Enabling OIDC on AKS deploys something called a "Mutating Admission Webhook" which takes care of getting a token that has a limited lifetime, and refreshes the token on expiration. If you are interested in how this works under the hood, look here.

I hope you enjoyed this, thanks for sticking around till the end. Until the next!

New Website, refactored

2025-05-04T00:00:00Z

Having neglected our web site for a long time, I read a post on X of someone that used Eleventy to create his web site. Being a guy that alwys likes to try out new technology, I thought I'd give it a go. Our previous website was created with Hugo, which is also great but still required a lot of tweaking to get right. Since I am not a web developer by trade, reading up on Eleventy seemed like it could make the job easier.

Getting started

I used the blog template available on Github to get started, cloned it into my local git environment and started customizing it to the Ascode look and feel. One if the nice features of Eleventy (same with Hugo) is that you can run a local web server using eleventy --serve that starts a web server on http://localhost:8081 together with a file system watcher that once a change is made to a file, immediately processes the change and makes your chanegs visible through the local web server. This is great for immediate feedback on the result of the changes that were made.

There are a bunch of plugins available, we wanted to get up and running quickly so I kept the first version really simple.

Hosting on Cloudflare Pages

The previous web site was a really nice project to test out the serverless features of AWS, but it involved deploying and maintaining quite a bit of resources so we decided to keep it really simple this time and host the web site with Cloudflare Pages.

You can generate the static content for upload to Cloudflare by running the command npx @11ty/eleventy which generates all required files and stores them by default in the _site folder. Then, upload the contents of the _site folder to Cloudflare (in the Compute (Workers)/Workers & Pages section). The name you give the project is the name that is used to generate the default Cloudflare Pages url, in this case the name is ascode-web which automatically generates the url https://ascode-web.pages.dev/. That's it for basics, pretty simple - love it.

The first go for me resulted in none of the pictures being visible, they contained broken links. After some troubleshooting I found the --serve option does not clean up after itself; after removing the local _site folder and re-running eleventy --serve all was looking fine again.

Here is the documentation for the image plugin that might help you out: https://www.11ty.dev/docs/plugins/image/

Setting a custom domain

We are hosting the ascode.nl at Cloudflare which makes it super-easy to add the custom domain ascode.nl to Cloudflare Pages. Just add the custom domain on the Workers & Pages page and Cloudflare will take care of creating or updating the required DNS record, and generate an SSL certificate with the same name. Keep in mind that ascode.nl and www.ascode.nl are 2 separate custom domains in the Pages sense and need to be generated seperately.

Automating deployments

When I find some more time...

Shared VPC Subnet tagging

2023-11-06T00:00:00Z

This post was previously published on https://www.lionsville.nl/blog/shared-vpc-subnet-tagging. Since it is no longer there, it is re-published on this site.

One of the services we provide for our customers is the deployment and management of an AWS Landing Zone. Part of the Landing Zone is a centralized networking environment that is used as the centralized VPC for ingress and egress network traffic. VPC sharing is used, implementation varies, for this article we implement a shared VPC per AWS account with 3 subnets per VPC.

Each AWS Account gets its own VPC with 3 type of subnets:

Isolated
Private
TransitGateway

With 1 subnet per Availability Zone, a total of 9 subnets are created. The subnets are then shared with Resource Access Manager (RAM) with the Team account.

For the sake of simplicity, this article will only focus on the subnet sharing part of this implementation. One of the big downsides of RAM is that the shared resource in the Team acccount does not inherit tags. Especially for implementations like EKS or other AWS services that rely on tagging, this is a problem. As part of the VPC deployment in the Shared Network account, several tags are created of which a few of them we would like to make available in the Team account. The tags that are discussed in this post are Name, AccountID, subnetType and aws-cdk:subnet-type.

Process

EventBridge detects an AssociateResourceShare Cloudwatch Event.
EventBridge triggers the Lambda function with the Cloudwatch event json as input.
The Lambda function looks up the subnet-id that is in the body of the Cloudwatch event and grabs the tags that are configured on that subnet.
The Lambda function assumes a role in the team account.
The Lambda function updates the tags on the subnets in the team account.

The process in the will be discussed in more detail, using code examples (Terraform and Lambda). The code can be found here.

If you want Eventbridge to be able to record events with a detail-type value of AWS API Call via CloudTrail, a CloudTrail trail with logging enabled is required. The event that Eventbridge is configured to look for is the AssociateResourceShare event. Check the API Documentation for the different events that are available for RAM. The target for the event is a Lambda function that was created by Markus Muhr. Two resources are created, an event rule and an event target.

resource "aws_cloudwatch_event_rule" "ram" {
  name        = "capture-ram-creation"
  description = "Capture creation of RAM shares"

  event_pattern = jsonencode({
    "source" : ["aws.ram"],
    "detail-type" : ["AWS API Call via CloudTrail"],
    "detail" : {
      "eventSource" : ["ram.amazonaws.com"],
      "eventName" : ["AssociateResourceShare"]
    }
  })
}

resource "aws_cloudwatch_event_target" "lambda" {
  target_id = "lambda-function-target"
  rule      = aws_cloudwatch_event_rule.ram.name
  arn       = aws_lambda_alias.tagger_alias.arn
}

Lambda function

The Lambda function contains several functions:

lookup the shared subnet
assume the role
tag the team subnet
the main Lambda event handler

The example shows a simplified version of the actual function that was implemented, it should however be easy to extend upon this code.

IAM role in Team account(s)

The team account requires an IAM role to be created that can be assumed by the Lambda function in order to create the tags. This is a very simple role, which is created using org-formation In short, in order to use Terraform several resources like an S3 bucket for state backend and IAM roles are required. Org-formation uses Cloudformation under the hood for creating the resources that are required for Terraform and resources that need to be created in all accounts. When AWS Control Tower is not an option, we leverage org-formation as our account vending machine in AWS. Note the OrganizationBinding parameter, this is specific to org-formation to target or filter only specific accounts or OU's. If you don't use org-formation, omit this parameter.

LambdaTaggerPolicy:
  Type: "AWS::IAM::ManagedPolicy"
  OrganizationBinding: !Ref TeamAccountBinding
  Properties:
    ManagedPolicyName: LambdaTaggerPolicy
    Description: Policy to allow access from lz-net Lambda function
    PolicyDocument:
      Version: 2012-10-17
      Statement:
        - Effect: Allow
          Action:
            - "ec2:CreateTags"
          Resource:
            - "arn:aws:ec2:*:*:subnet/*"
            - "arn:aws:ec2:*:*:vpc/*"
    Roles:
      - !Ref LambdaTaggerRole

LambdaTaggerRole:
  Type: AWS::IAM::Role
  OrganizationBinding: !Ref TeamAccountBinding
  Properties:
    RoleName: LambdaTaggerRole
    AssumeRolePolicyDocument:
      Version: "2012-10-17"
      Statement:
        - Effect: Allow
          Principal:
            Service:
              - lambda.amazonaws.com
          Action:
            - "sts:AssumeRole"
        - Effect: Allow
          Principal:
            AWS:
              - "<central network account ID>"
          Action:
            - "sts:AssumeRole"

That's it! Even though the current Lambda is “only” used to tag resources, you can imagine this concept can be used for all sorts of implementations. Go nuts!

AWS Account creation, fully automated - ascode style

2020-03-04T09:58:02Z

An introduction into creating accounts in AWS, in code, fully automated with Terraform.

We like AWS. In fact, it's our preferred public cloud provider. Why? Because AWS understands the need to automate things. We use Terraform for automating our cloud infrastructures, and Hashicorp usually has first day support for new services coming out of Amazon. If Terraform doesn't have support for something, you can always fall back to the AWS CLI (which can be called with Terraform using a null_resource). I was automating the AWS cost & usage report the other day, and found out there is no Athena support in the "aws_cur_report_definition" resource, so I had to fall back to the CLI to create the report definition, like so:

resource "null_resource" "create_cur_report" {
  provisioner "local-exec" {
    command = <<EOF
      AWS_DEFAULT_REGION="us-east-1" aws cur put-report-definition --report-definition \
      AdditionalArtifacts=[\"ATHENA\"],AdditionalSchemaElements=[\"RESOURCES\"],\
      Compression=\"Parquet\",Format=\"Parquet\",RefreshClosedReports=true,\
      ReportName=${var.report_name},ReportVersioning=\"OVERWRITE_REPORT\",\
      S3Bucket=${var.cf_bucket_name},S3Prefix=${var.s3_prefix},S3Region=${var.s3_region},\
      TimeUnit=\"${var.time_unit}\"
      EOF
  }
}

The nice thing about using the null_resource is that you can use the variables that you have configured for your other resources, and use the output from other resources in your Terraform template.

Anyway, I digress. Creating the cost & usage report is a good subject for another blog post. This post is about account creation automation.

AWS Organizations

We use AWS Organizations to structure our AWS accounts. For every new client, we roll out a basic setup that looks like this:

By default, we create the following accounts:

svc: used for shared services that are used by the other accounts
log: contains the centralised logs, only accessbile by a limited number of users
DTAP: dev, tst, acc, prd
sandbox: contains 1 or more sandbox accounts used for "playgrounds"

This setup is sufficient to get a customer started in AWS. Because of AWS Organizations, consolidated billing is in place. Tagging is enforced so that resources (and therefore, costs) are identifiable by customer and/or environment. The Terraform code for this setup:

data "aws_organizations_organization" "root" {}

locals {
  dtap_accounts = {
    dev = "${var.email_group}+-${var.client_short_name}-dev@${var.email_domain}"
    tst = "${var.email_group}+-${var.client_short_name}-tst@${var.email_domain}"
    acc = "${var.email_group}+-${var.client_short_name}-acc@${var.email_domain}"
    prd = "${var.email_group}+-${var.client_short_name}-prd@${var.email_domain}"
  }
  core_accounts = {
    log = "${var.email_group}+-${var.client_short_name}-log@${var.email_domain}"
    svc = "${var.email_group}+-${var.client_short_name}-svc@${var.email_domain}"
  }
  sbx_accounts = {
    sbx = "${var.email_group}+-${var.client_short_name}-sbx@${var.email_domain}"
  }
}

resource "aws_organizations_organizational_unit" "customer_root" {
  count = var.has_organizations ? 1 : 0

  name      = var.client_name
  parent_id = data.aws_organizations_organization.root.roots.0.id
}

resource "aws_organizations_organizational_unit" "customer_dtap" {
  count = var.has_organizations ? 1 : 0

  name      = "${var.client_name}-environments"
  parent_id = aws_organizations_organizational_unit.customer_root.0.id
}

resource "aws_organizations_organizational_unit" "customer_sandbox" {
  count = var.has_organizations ? 1 : 0

  name      = "${var.client_name}-sandbox"
  parent_id = aws_organizations_organizational_unit.customer_root.0.id
}


resource "aws_organizations_organizational_unit" "customer_core" {
  count = var.has_organizations ? 1 : 0

  name      = "${var.client_name}-core"
  parent_id = aws_organizations_organizational_unit.customer_root.0.id
}

resource "aws_organizations_account" "dtap" {
  for_each = var.has_organizations ? local.dtap_accounts : {}

  name      = "${var.client_short_name}-${each.key}"
  email     = each.value
  parent_id = aws_organizations_organizational_unit.customer_dtap.0.id
}

resource "aws_organizations_account" "core" {
  for_each = var.has_organizations ? local.core_accounts : {}

  name      = "${var.client_short_name}-${each.key}"
  email     = each.value
  parent_id = aws_organizations_organizational_unit.customer_core.0.id
}

resource "aws_organizations_account" "sandbox" {
  for_each = var.has_organizations ? local.sbx_accounts : {}

  name      = "${var.client_short_name}-${each.key}"
  email     = each.value
  parent_id = aws_organizations_organizational_unit.customer_sandbox.0.id
}

This code is part of a module that we created for anything client-related. Creation is done when the variable has_organizations is set to true. We did this so we can exclude this from testing the module, as creating AWS accounts is easy but removing them is not. When you remove the AWS account from Terraform, Terraform removes it from the state but does not actually delete the account - this must be done manually and can only be done after at least 7 days. When we test a module, we create and destroy the resources in a sandbox environment to make sure it works - doing this for AWS accounts would mean it would become a mess real soon with leftover accounts. Using the has_organizations variable gives the added benefit that we can set this to false when a customer already has AWS Organizations in place, for example.

The outputs that are defined look like this:

output "customer_dtap_accounts_map" {
  value = var.has_organizations ? [for environment, accountid in zipmap(keys(local.dtap_accounts), values(aws_organizations_account.dtap)[*]["id"]) : { "environment" = environment, "account_id" = accountid }] : null
}

output "customer_core_accounts_map" {
  value = var.has_organizations ? [for environment, accountid in zipmap(keys(local.core_accounts), values(aws_organizations_account.core)[*]["id"]) : { "environment" = environment, "account_id" = accountid }] : null
}

output "customer_sandbox_accounts_map" {
  value = var.has_organizations ? [for environment, accountid in zipmap(keys(local.sbx_accounts), values(aws_organizations_account.sandbox)[*]["id"]) : { "environment" = environment, "account_id" = accountid }] : null
}

output "customer_root_ou_id" {
  value = var.has_organizations ? aws_organizations_organizational_unit.customer_root.0.id : ""
}

output "customer_dtap_ou_id" {
  value = var.has_organizations ? aws_organizations_organizational_unit.customer_dtap.0.id : ""
}

output "customer_sandbox_ou_id" {
  value = var.has_organizations ? aws_organizations_organizational_unit.customer_sandbox.0.id : ""
}

output "customer_core_ou_id" {
  value = var.has_organizations ? aws_organizations_organizational_unit.customer_core.0.id : ""
}

output "all_account_ids_map" {
  value = var.has_organizations ? [for environment, accountid in merge(zipmap(keys(local.dtap_accounts), values(aws_organizations_account.dtap)[*]["id"]), zipmap(keys(local.core_accounts), values(aws_organizations_account.core)[*]["id"]), zipmap(keys(local.sbx_accounts), values(aws_organizations_account.sandbox)[*]["id"])) : { "environment" = environment, "account_id" = accountid }] : null
}

What you see here is the Organizational Unit id's are configured as output so they can be used as parent_id when creating additional accounts. The account id's are configured as output so they can be used to automatically create the AWS CLI config, but I will get into that later on. For now, I will break up the export of the account id's into smaller pieces to explain what is done.

value = var.has_organizations ? - the value is only exported if the variable has_organizations is set to true (which is the default).
[for environment, accountid in zipmap(keys(local.dtap_accounts), values(aws_organizations_account.dtap)[*]["id"]) : { "environment" = environment, "account_id" = accountid }] - this links the environment name that is defined in locals to the account id that is created.
zipmap(keys(local.dtap_accounts), values(aws_organizations_account.dtap)[*]["id"]) - this creates a map of environment with account_id. The result for the core accounts looks like this:

{
    "svc" = "123456789",
    "log" = "123456788",
}

Then, using the for loop [for environment, accountid in zipmap(...) : { "environment" = environment, "account_id" = accountid }] a map is created that looks like this:

{
    "account_id" = "123456788"
    "environment" = "log"
  },
  {
    "account_id" = "123456789"
    "environment" = "svc"
  }

All the outputs are merged together to get a nice overview of all the provisioned accounts.

Additional AWS accounts

So, we have the default setup in place. It could be possible that a client wants an additional account, for example an additional sandbox account or an isolated account for a high-secure application. We want the creation of this account to be automated, incorporated into AWS Organizations and set up with some default roles and resources that are required in each account.

First, the account is created. It is possible to add the account to an existing Organizational Unit for AWS Organizations, like an additional sandbox account that goes into the sandbox OU. It is also possible to add an additional OU in which we then create the account. The code for the module looks like this:

resource "aws_organizations_account" "additional" {
  count = var.create_account ? 1 : 0

  name      = "${var.customer_tla}-${var.aws_account_name}"
  email     = var.aws_account_email_address
  parent_id = var.aws_account_parent_id
}


resource "aws_organizations_organizational_unit" "ou" {
  count = var.create_ou ? 1 : 0

  name      = var.ou_name
  parent_id = var.aws_ou_parent_id
}

Not too difficult, right? When you want to create an OU, create_account is set to false and create_ou is set to true, and vice versa.

Using this in a module, with the example of creating an additional OU, looks like this:

module "new_aws_ou" {
    source                    = "modules/aws/account"
    create_account            = false
    create_ou                 = true
    ou_name                   = "custom"
    aws_ou_parent_id          = module.client_customer_name.customer_root_ou_id
}

module "new_aws_account" {
    source                    = "modules/aws/account"
    customer_tla              = var.customer_tla
    aws_account_name          = var.additional_account_name
    aws_account_email_address = "${var.email_group}+${var.customer_tla}-{var.environment}@${var.email_domain}"
    aws_account_parent_id     = module.new_aws_ou.organizational_unit_id
}

This creates a new OU named custom with a new account created in this OU. Now we can create the AWS CLI config file with the output of all the resources that we created:

# can use specific config file with export AWS_CONFIG_FILE=/var/tmp/config-${var.customer_name} in CI/CD pipeline

resource "null_resource" "aws_config" {
  depends_on = [module.client_customer_name, module.new_aws_account]
  provisioner local-exec {
    working_dir = "/keybase/team/customer/customerbot/home/.aws"
    command     = <<EOT
      echo "##########################################################################" >| config-${var.customer_name}
      echo "# AWS config file for customer ${var.customer_name}" >> config-${var.customer_name}
      echo "##########################################################################" >> config-${var.customer_name}
      echo "[profile ${var.customer_name}-root-user]\nregion=eu-west-1\noutput=json\n" >> config-${var.customer_name}
      echo "##########################################################################" >> config-${var.customer_name}
      echo "# DTAP Accounts" >> config-${var.customer_name}
      echo "##########################################################################" >> config-${var.customer_name}
      %{for account in module.client_customer_name.customer_dtap_accounts_map}
        echo "\n[profile ${var.customer_name}-${account.environment}]\nrole_arn=arn:aws:iam::${account.account_id}:role/AccountAssumeRole\nsource_profile=${var.customer_name}-root-user\nregion=eu-west-1\noutput=json\n" >> config-${var.customer_name}
      %{endfor~}
      echo "##########################################################################" >> config-${var.customer_name}
      echo "# Core Accounts" >> config-${var.customer_name}
      echo "##########################################################################" >> config-${var.customer_name}
      %{for account in module.client_${var.customer_name}.customer_core_accounts_map}
        echo "\n[profile ${var.customer_name}-${account.environment}]\nrole_arn=arn:aws:iam::${account.account_id}:role/AccountAssumeRole\nsource_profile=${var.customer_name}-root-user\nregion=eu-west-1\noutput=json\n" >> config-${var.customer_name}
      %{endfor~}
      echo "##########################################################################" >> config-${var.customer_name}
      echo "# Sandbox Accounts" >> config-${var.customer_name}
      echo "##########################################################################" >> config-${var.customer_name}
      %{for account in module.client_${var.customer_name}.customer_sandbox_accounts_map}
        echo "\n[profile ${var.customer_name}-${account.environment}]\nrole_arn=arn:aws:iam::${account.account_id}:role/AccountAssumeRole\nsource_profile=${var.customer_name}-root-user\nregion=eu-west-1\noutput=json\n" >> config-${var.customer_name}
      %{endfor~}
      echo "##########################################################################" >> config-${var.customer_name}
      echo "# Other Accounts" >> config-${var.customer_name}
      echo "##########################################################################" >> config-${var.customer_name}
      echo "\n[profile ${var.customer_name}-${module.new_aws_account.aws_account_id["environment"]}]\nrole_arn=arn:aws:iam::${module.new_aws_account.aws_account_id["account_id"]}:role/AccountAssumeRole\nsource_profile=${var.customer_name}-root-user\nregion=eu-west-1\noutput=json\n" >> config-${var.customer_name}
     EOT
  }
}

As you can see, we use Keybase with a bot account in the CI/CD pipeline that uses an AWS config file. I hate having to update this file every time a new account is created, so by using this resource the file is updated every time a new account is created! The (partial) result looks like this:

##########################################################################
# AWS config file for customer CUSTOMER
##########################################################################
[profile customer-root-user]
region=eu-west-1
output=json

##########################################################################
# DTAP Accounts
##########################################################################

[profile customer-acc]
role_arn=arn:aws:iam::123456787:role/AccountAssumeRole
source_profile=customer-root-user
region=eu-west-1
output=json


[profile customer-dev]
role_arn=arn:aws:iam::123456786:role/AccountAssumeRole
source_profile=customer-root-user
region=eu-west-1
output=json
...

Once the file is updated, it can be used to provision resources in the new account. This is done by configuring a module that contains basic resources that we want deployed in all accounts. For example, Cloudtrail must be enabled, some IAM roles must be deployed, centralized logging must be set up and anything else that you can think of that you want to be part of your default AWS account rollout.

First, we configure an AWS provider with an alias:

provider "aws" {
  region  = var.aws_region
  profile = "customer-custom"
  alias   = "custom"

  skip_metadata_api_check = true

  assume_role {
    role_arn = "arn:aws:iam::${module.new_aws_account.aws_account_id["account_id"]}:role/AccountAssumeRole"
  }
}

Then we can provision the resources in the new account using this provider:

module "new_aws_account_baseline" {
  source                 = "../modules/aws-account-baseline"
  aws_account_id         = var.aws_account_id
  customer_tla           = var.customer_tla
  environment            = var.environment
  tags                   = local.tags
  customer_name          = var.customer_name
  cloudtrail_bucket_name = module.centralized_logging.cloud_trail_bucket_id
  cloudtrail_kms_key_id  = module.centralized_logging.log.outputs.cloud_trail_kms_arn
  cloudtrail_s3_prefix   = data.aws_caller_identity.current.account_id
  providers = {
    aws = aws.custom
  }
}

Each client gets it's own Terraform template using a set of shared modules, that defines the base accounts and any possible additional accounts. The client module can be extended with whatever services or resources you want to be part of a new AWS account. That way, all accounts are provisioned in exactly the same way. You could also create different contexts with IAM permissions boundaries, allowing only certain services to be provisioned in the account. You can then apply those contexts to an account based on a variable. The possibilities are nearly endless...

How to build a serverless website, in AWS

2020-01-29T00:00:00Z

We needed a new website, we didn't need Wordpress. Our experience building our new site, serverless and secure, in AWS.

We have our fresh new logo, stickers, and lots of content. Now we need a new website to begin sharing with our customers and the community. As a company whose mission it is to do "all the things as code," our website obviously can not be some middle-of-the-road Wordpress site. Quite the opposite if you roll with our way of doing things. It must be clean, secure, serverless and fast. Plus, we are going to want a DTAP street so that we can experiment, test and ensure at least one environment which is production-like for testing. Naturally, it must run on the public cloud, in this instance, AWS. Infrastructure code in Terraform, Gitlab for CI/CD with automatic deployments to Dev and manual deployments to Acc and Prod.

For the framework, we decided to use Hugo. Hugo is a popular open-source static site generator. It is straightforward to run locally, so you get immediate feedback on your changes, and it has a built-in mode for building static pages. You can even deploy straight from Hugo to your favourite cloud provider! As we wanted to have a little more control over the deployment, we decided to write custom deployment scripts.

Architecture

As mentioned in the introduction, we wanted to go full serverless. Here is an overview of the architecture:

You would think that hosting a static website is easy enough, but there are a few things that need attention. First of all, hosting a website in S3 is relatively easy to set up. But, it does not support SSL and is HTTP-only. That could be perfectly fine for other companies, but not for us - we advocate to implement security in everything we do. The most common way of using SSL with an S3-hosted website is Cloudfront. Since we want this all automated, we leveraged AWS Certificate Manager to generate the SSL certificates that Cloudfront requires. Remember, whenever you want to use ACM Certificates or Lambda function in Cloudfront, they must be created in US-East-1! Also, Origin Access Identity is used to make the S3 buckets only accessible to Cloudfront and nothing else. The S3 bucket cannot be encrypted. CloudFront currently does not support KMS server-side encryption for S3. The reason this does not work is that viewer requests through CloudFront do not have access to the KMS credentials used to encrypt the S3 objects.

Route53 has Alias records for ascode.nl and www.ascode.nl pointing to the Cloudfront distribution.

So far, so good. We started off with an English website, but want to leave the option open to add other languages (hence the "/en" extension when you open our site). With Cloudfront, it is not necessary to configure your S3 bucket (or S3 origin, in Cloudfront lingo) containing the static files in "public-read" mode, which makes it a little more secure. CloudFront does allow you to specify a default root object (index.html), but it only works on the root of the website (such as https://ascode.nl > https://ascode.nl/index.html). It does not work on any subdirectory (such as https://ascode.nl/about/). If you were to attempt to request this URL through CloudFront, CloudFront would do a S3 GetObject API call against a key that does not exist, throwing a "NoSuchKey" error message. Apache, for example, has the DirecoryIndex setting to configure the default document to serve.

With Cloudfront there is no easy way to configure this, at least not if you want to keep your S3 bucket private and use OAI. Enter Lambda@Edge. With this, you can have a function running on the CloudFront edge nodes to request the appropriate object key from the S3 origin. We configured this in a Cloudfront distrbution as a Lambda function association with an origin-request event. We also set the viewer-profile to redirect-to-https so that all requests are made using SSL but still allowing for our website audience to connect over HTTP. Lastly, we want to redirect people coming to our site via www.ascode.nl to be redirected to ascode.nl (also called "naked domain" or "apex"). We use another Lambda@Edge function for this implementation but now configured in Cloudfront as a Lambda function association with a viewer-request event.

The challenges when running a static website - server-side code

Cool, we have our website up and running! Last thing to tackle is our contact form. And boy, was that a challenge! Since S3 doesn't support any server-side code, such as PHP - so you can't use server-side logic to send an email, this required a different solution. Yes, we could have just implemented a mailto: link that will cause the user to open their mail client when they click on it - but what's the fun in that? We wanted a form that allowed anyone to send an email without needing an email client. The function for sending the email is a Lambda function behind an API Gateway. Invoking the protected API requires an API key.

The problem with this setup, however, is that the API Gateway is on a different domain (https://...execute-api...) than Cloudfront (in our case, https://ascode.nl, but could also be https://,,,cloudfront.net). Since the domains are different, the browser will treat this as a cross-origin request. And that means CORS headers are required on the API side. The two most important headers are Access-Control-Allow-Origin and Access-Control-Allow-Credentials. The former is required for every cross-origin request, the latter is only when the {credentials: "include"} option is used. This can be solved in the API Gatway itself by configuring an "OPTIONS" mock request that returns Access-Control-Allow-Origin = "*" to Cloudfront, but this proved to be very error-prone and took a lot of testing.

After some research we found out we can use Cloudfront not only with S3 origins but also with API Gateway origins, eliminating the CORS problem as both the API request as the website request comes from the same domain. There is a trick to this, however. It has to do with the way Cloudfront constructs the URL for the backend. When CloudFront constructs the URL for the backend, you can specify three parts:

The domain_name
The origin_path
The path_pattern at the cache behavior

CloudFront constructs the URL to the origin by replacing the distribution URL with the domain_name+origin_path; then, it appends the path. Because the web site is already on "/", the API needs configuration on a different path. Long story short, the path_pattern you configure in Cloudfront must have the same name as the stage name in the API Gateway. For example, if you have configured a stage called "prod" in API Gateway, the path pattern in Cloudfront will be "/prod/*". It took some time to figure that out. Victory is sweet!

Making this work in DTAP

We write all our infrastructure code in Terraform and Gitlab for CI/CD. For this website, we wanted a "DAP" environment - DEV to check quickly how the site behaves, Acc the same as Prd. Hugo also supports environments (look here), which means we can also parameterize Hugo for the different environments. For example, the API key differs per environment so we can use the respective environment .toml files to configure the various keys.

We have split up the code over multiple repositories; infrastructure code is in a different repository than the actual web site. The same DAP-principles apply, however.

With Gitlab, pipeline as code is relatively easy. It takes some time getting used to the YAML syntax, but once you got the hang of it, it works great. As soon as a branch is ready to be merged into master, a merge request is created. The code is validated and scanned for compliance using terraform-compliance. Once the pipeline is passed, the MR can be merged after which a new version is created, and the code is automatically deployed to Dev. Build/plan is done automatically for Acc and Prd, but they have manual deployment approvals (for now).

If you are interested in what infrastructure code we used, we created a public repository that contains all the code that we wrote to build the AWS environment. As mentioned, in practice, we have this code divided over more than one repository, but for ease of (re)use, we created a single public repo. There probably will be some room for improvement here and there, so if you see a better way to do it, let us know! Or even better, create a merge request against our public repo.

Ascode Blog

GitLab CI/CD for Cloudflare Pages: Automated Deployments with Preview Environments

The Goal

Prerequisites

The Pipeline

Build Stage

Preview Deploys

Stopping Preview Environments

Production Deploy

A Note on Wrangler and npx

The Result

Building a Raspberry Pi5 Cluster with Talos Linux and Cilium

Table of Contents

Kit list

Putting it all together

Installing Talos

Preparing the Raspberry Pi

Flashing the OS to an SD Card

Preparing Talos Config

Install Talos on the first node

Install Talos on other nodes

Install Cilium

Install Talos on other nodes

What's next?

Self-hosted Gitlab Runners on AKS, with Managed Identities

The case for self-hosted Gitlab Runners

Types of runners

Types of runtime environments

Azure configuration

Kubernetes resources

Runner registration

Using this in a Gitlab pipeline

New Website, refactored

Getting started

Hosting on Cloudflare Pages

Setting a custom domain

Automating deployments

Shared VPC Subnet tagging

VPC Sharing overview

Process

Lambda function

IAM role in Team account(s)

AWS Account creation, fully automated - ascode style

An introduction into creating accounts in AWS, in code, fully automated with Terraform.

AWS Organizations

Additional AWS accounts

How to build a serverless website, in AWS

Architecture

The challenges when running a static website - server-side code

Making this work in DTAP