The three-plane model — control plane, runner, and environment

A CI run is not a single process. It is three processes, on three different machines, exchanging data across two trust boundaries. The control plane decides what to run. The runner runs it. The environment is what the runner changes. Conflating the three planes is the architectural mistake this part of the course exists to undo.

The three planes

flowchart LR
    CP["Control plane\n(forge: GitHub, GitLab,\nworkflow state, secrets store,\nartifact store)"]
    RUN["Runner\n(fresh VM or persistent agent,\npipeline file, checkout,\nstep outputs)"]
    ENV["Environment\n(cloud account, k8s cluster,\nbare metal, target system)"]

    CP -->|"job dispatch,\nstep log tail,\nsecret injection"| RUN
    RUN -->|"plan/apply, push,\ndeploy, exec"| ENV
    ENV -->|"apply result,\ndeploy log,\ndrift state"| RUN
    RUN -->|"status report,\nartifact upload"| CP

• Control plane. The forge (GitHub, GitLab, Jenkins controller). It owns the workflow file, the trigger evaluation, the secret store, the artifact store, the runner pool, and the status UI. It does not run your code.
• Runner. A machine allocated for one job. It checks out the commit, executes the steps, holds the in-memory secrets for the duration of the job, and reports results. The runner is the only plane that runs your code.
• Environment. The system the change targets - a cloud account, a Kubernetes cluster, a server, a database. The runner reaches it over the network using credentials the job was given.

The pipeline file defines the contract between the three planes: what the runner pulls from the control plane, what it sends to the environment, what it reports back.

The two trust boundaries

flowchart LR
    CP["Control plane\n(trusted forge)"]
    B1["Boundary 1\n(forge -> runner):\ncode, secrets, dispatch"]
    RUN["Runner\n(partially trusted)"]
    B2["Boundary 2\n(runner -> environment):\nAPI calls, deploy payloads"]
    ENV["Environment\n(production target)"]

Every CI run crosses two trust boundaries:

• Boundary 1: control plane to runner. The forge ships the pipeline file, the commit, the secrets (as environment variables), and the dispatch token. The runner trusts these because the forge signs them.
• Boundary 2: runner to environment. The runner ships the Terraform apply, the kubectl apply, the ansible-playbook call. The environment trusts the runner’s credentials because the identity was minted by the control plane or an OIDC provider.

The mistake is to assume the runner and the control plane are the same trust zone. A runner that processes untrusted pull requests is a runner that, for the duration of the job, is in the attacker’s trust zone. The control plane’s secrets are not safe on that runner unless scoped to jobs that do not process untrusted input.

Where the data lives

Each plane owns different data. The control plane owns the workflow definition, trigger history, encrypted secrets, artifacts, and OIDC signing keys. The runner owns the checkout, the step logs in memory, the secrets as environment variables, the build cache, and the artifact staging directory. The environment owns the desired state (Terraform state, k8s manifests), the credentials the runner used, and the audit trail (CloudTrail, kube-apiserver audit log).

The runner is ephemeral. The control plane is durable. The environment is the asset. The cross-boundary question is always: what crosses, in which direction, with which authentication, and which plane is the source of truth.

Production discipline

1. Name the plane before naming the tool. Decide what each plane owns before picking the YAML keywords that wire them.
2. Scope secrets to the plane that needs them. Secrets that cross more than one boundary have wider blast radius.
3. Treat the runner as untrusted for untrusted jobs. A fork PR’s runner is in the attacker’s trust zone. Scope secrets and isolate the network.

Cross-course references

• Linux for Production Sysadmins - Part XXXIV (ConfigMgmt) applies the same model to package builds.
• Ansible for Production Sysadmins - Part XXXVII (RepoArch) treats molecule runner, controller, and target as three planes.
• Terraform for Production Sysadmins - Parts IX-XII (State) treat Terraform Cloud, CI runner, and cloud account as three planes.

Quiz