11.1 Cloud Native CI/CD Pipelines & Build Tooling

11.1 Cloud Native CI/CD Pipelines & Build Tooling

Quick Answer: Continuous Integration builds and tests every commit. Continuous Delivery keeps every successful build deployable, releasing on a human decision. Continuous Deployment removes that decision and ships automatically. In Kubernetes, pipelines increasingly run as Kubernetes objects — Tekton Task/Pipeline and Argo Workflows — and images are built without a privileged Docker daemon using Kaniko, Buildah, BuildKit, or Cloud Native Buildpacks.

The official curriculum lists Application Delivery as a competency in its own right. This section covers the build-and-promote half; section 11.2 covers the GitOps half that puts the result into a cluster.

---

1. CI, CD, and CD — Three Different Things

 commit ──► BUILD ──► TEST ──► PACKAGE ──► [approval] ──► DEPLOY
           └──────── Continuous Integration ────────┘
           └───────────── Continuous Delivery ──────────────────┘
                          (approval gate present)
           └───────────── Continuous Deployment ────────────────┘
                          (no approval gate)

Both CD variants abbreviate to "CD", which is why the exam-relevant discriminator is always the presence or absence of the manual gate.

---

2. A Cloud Native Pipeline End to End

[1] Commit to the application repository
[2] CI triggers:
      • unit tests, linting, static analysis (SAST)
      • dependency vulnerability scan
      • build an OCI image (reproducible, multi-arch)
      • generate an SBOM (Syft / Trivy)
      • scan the image for CVEs (Trivy / Grype)
      • sign the image digest (Cosign) + attach provenance
      • push to the registry
[3] CI updates the image digest in the CONFIG repository
[4] An in-cluster GitOps controller notices the change
[5] Admission verifies the signature, then the rollout proceeds

The deliberate split between an application repository (source) and a configuration repository (manifests) is what allows CI to hold no cluster credentials at all — it writes a commit, and the cluster pulls. That is the security argument for GitOps as much as the workflow argument.

---

3. Kubernetes-Native Pipeline Engines

Traditional CI servers run pipelines on their own agents. Kubernetes-native engines model the pipeline itself as custom resources reconciled by a controller (the CRD pattern from section 5.3), so every step runs in a Pod with the cluster's own RBAC, quotas, scheduling, and autoscaling.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-and-push
spec:
  params:
  - name: image
  steps:
  - name: build
    image: gcr.io/kaniko-project/executor:latest
    args:
    - --dockerfile=Dockerfile
    - --destination=$(params.image)

The advantage is uniformity: pipeline capacity autoscales like any other workload, secrets come from the same Secret objects, and there is no second permission model to maintain.

---

4. Building Images Without a Docker Daemon

Building an image inside a cluster used to mean mounting the node's Docker socket into a build Pod — effectively granting root on that node, since anything that can talk to the daemon can start a privileged container. Daemonless builders exist precisely to remove that:

Why Buildpacks Matter

Buildpacks (a CNCF project, driven by the pack CLI and used by Heroku, Google Cloud, and Paketo) invert the responsibility model. Developers stop writing and maintaining Dockerfiles; the platform team maintains the base images. The killer feature is rebase: when a CVE lands in the base OS layer, buildpacks swap the run image underneath thousands of applications without rebuilding or re-testing any of them, because the application layer is unchanged.

---

5. Testing Stages

Validating manifests in CI is disproportionately valuable: a schema error or a policy violation caught in a pull request costs seconds, while the same error caught at admission costs a failed rollout.

---

6. Securing the Pipeline

CI is a privileged system that writes the artifacts your cluster runs. Treat it as production:

The recurring theme is that the pipeline is part of the attack surface. An attacker who can modify a pipeline definition does not need to break into the cluster at all — the cluster will happily deploy whatever the pipeline produces, which is exactly why signature verification at admission is the control that matters.