RBAC (Role-Based Access Control) is a permissions model where you first define what roles can do, then assign roles to people. K8s uses RBAC to control who can perform which operations on which resources. CD tools use RBAC to control who can deploy to which environment.

Explanation

Three core elements of RBAC

Subject (who)  →  RoleBinding (assignment)  →  Role (what they can do)

• Subject: a user, group, or service account (programmatic identity)
• Role: defines a set of permissions (which operations on which resources)
• RoleBinding: assigns a Role to a Subject

Intuitive analogy: a Role is a job title (engineer, manager), a RoleBinding is the “appointment letter,” and the Subject is the person being appointed.

RBAC in Kubernetes

K8s RBAC controls “who can do what against the K8s API.”

Resources & Verbs

1rules:
2- apiGroups: [""]
3  resources: ["pods", "services"]   # resource types
4  verbs: ["get", "list", "watch"]   # allowed operations

Common verbs: get list watch create update patch delete

Role vs ClusterRole

 1# Role: only effective in the production namespace
 2kind: Role
 3metadata:
 4  namespace: production
 5  name: pod-reader
 6rules:
 7- apiGroups: [""]
 8  resources: ["pods"]
 9  verbs: ["get", "list"]
10
11---
12# RoleBinding: assign this Role to alice
13kind: RoleBinding
14metadata:
15  namespace: production
16subjects:
17- kind: User
18  name: alice
19roleRef:
20  kind: Role
21  name: pod-reader

Service Account: identity for programs

Programs running in pods (like a CD tool agent) are not people. K8s uses Service Accounts to give them an identity, then uses RoleBinding to control what they can do:

CD tool agent (Pod)
  → uses ServiceAccount: octopus-agent
  → RoleBinding → ClusterRole: deploy-permissions
  → can apply manifests, update Deployments

RBAC in CD Tools (Octopus)

The CD tool has its own RBAC layer, controlling “who can operate which project / environment”:

Engineer alice
  → belongs to Team: backend-team
  → Team is assigned Role: deployer (can deploy, cannot change project settings)
  → restricted to Environment: dev, staging (cannot touch prod)

Typical role hierarchy:

Knowledge Sugar

Why does K8s need RBAC?

The K8s API can do a lot – delete Pods, modify Secrets, scale Deployments. Without access control, anyone or any program that can connect to the cluster can do anything. RBAC lets you:

• Restrict devs to only operate within their own namespace
• Give CI/CD agents only manifest apply permission, not Secret deletion
• Give SRE cluster-level read access without prod write access

Principle of Least Privilege

The design philosophy behind RBAC: give each subject only the minimum permissions needed to do its job. If a CD tool agent only needs apply, do not give it delete.

For CD tool background, see the WarpCD vs Octopus Deploy post.

WarpSpeedCD (internally called WarpCD) is a GitOps pull model – Git is the single source of truth, and a bot syncs changes to the cluster. Octopus is a push model – a pipeline actively triggers deploys, with approval and release management handled in the Octopus UI. The fundamental difference is who drives the deploy.

Explanation

WarpCD (GitOps / Pull model)

Code PR merged
    ↓
WarpCD bot opens a PR in the K8s repo (updates manifests)
    ↓
Manual review & approve PR
    ↓
PR merged → cluster auto-syncs (pull)

• Source of truth: K8s manifests live in a Git repo; cluster state always follows Git
• Audit trail: every deploy is a Git commit, giving you history for free
• Approval: through the PR review process, consistent with code review

Octopus Deploy (Push model)

CI build completes → artifact (image) pushed to registry
    ↓
Octopus detects new version, creates a Release
    ↓
Promotion flow: dev → staging → prod (each stage can have an approval gate)
    ↓
Octopus actively applies manifests to the cluster (push)

• Source of truth: Octopus’s Release and Project configuration
• Approval: approval gates configured in the Octopus UI, not through Git PRs
• Runbook: can run operational tasks (DB migration, rollback, smoke test)

Core differences

Knowledge Sugar

How to do a CD pipeline migration?

Switching from GitOps to Octopus is not just migrating YAML – it is replacing the entire deploy driver:

1. Artifacts stay the same: container images and Helm charts do not need changes
2. K8s manifests may be kept: Octopus can use kubectl/Helm steps to apply existing manifests
3. What actually migrates is the process:
   • Replace WarpCD bot’s PR flow with Octopus’s Release + Promotion
   • Replace Git PR approval with Octopus’s approval gates
   • Create corresponding Projects + Steps in Octopus for each service’s deploy config

Typical migration steps

1. Create environments in Octopus (dev / staging / prod)
2. Create an Octopus Project for each service, configure deploy steps
3. Set up approval gates to replace PR review
4. Run shadow mode (old and new in parallel) to verify results match
5. Once confirmed, turn off the WarpCD bot -- switchover complete

Running docker build inside GitLab CI does not work out of the box – the job itself already runs in a container with no Docker daemon. You need Docker-in-Docker (DinD) as a sidecar service to provide the daemon.

Explanation

Overall structure

1stages:
2  - test    # runs first
3  - build   # runs after (only if all test jobs pass)

Jobs in the same stage run in parallel; stages run sequentially.

run_tests job – typical job structure

1run_tests:
2  stage: test
3  image: python:3.11-slim  # set up container based on this image where job runs
4  before_script:
5    - apt-get update && apt-get install -y make gcc python3-dev
6  script:
7    - make test

• image: which Docker image to use as the execution environment for this job
• before_script: runs before every script, good for dependency installation
• script: the main commands to execute

build_image job – Docker-specific details

 1build_image:
 2  stage: build
 3  image: docker:20.10.16           # Docker CLI
 4  services:
 5    - docker:20.10.16-dind         # Docker daemon (sidecar)
 6  variables:
 7    DOCKER_TLS_CERTDIR: "/certs"   # enable TLS for secure communication
 8  before_script:
 9    - docker login -u $REGISTRY_USER -p $REGISTRY_PASS
10  script:
11    - docker build -t $IMAGE_NAME:$IMAGE_TAG .
12    - docker push $IMAGE_NAME:$IMAGE_TAG

Why do you need services: docker:dind?

Each GitLab CI job runs inside a container. That container has no Docker daemon by default, so docker build fails.

services is GitLab CI’s sidecar mechanism – it starts an extra container alongside the job container, both on the same network. docker:dind is an image with a built-in Docker daemon, designed for exactly this:

job container (docker:20.10.16, has CLI)
        ↕ TLS-encrypted communication
sidecar (docker:20.10.16-dind, has daemon)

What is DOCKER_TLS_CERTDIR: "/certs"?

Here “CLI” means the side that runs docker build – docker build itself just sends a request to the daemon via the Docker API, and the daemon does the actual build. TLS protects this API communication:

job container: docker build ...
     ↕ Docker API over TLS
sidecar: daemon actually runs the build

Setting DOCKER_TLS_CERTDIR: "/certs" makes DinD auto-generate TLS certificates. The CLI side reads them too, and the two complete a handshake before communicating. Setting it to an empty string "" disables TLS, but that is insecure and not recommended.

How are credentials passed in?

$REGISTRY_USER and $REGISTRY_PASS are CI/CD Variables configured in the GitLab project settings. They never appear in the YAML file, avoiding hardcoded secrets.

Knowledge Sugar

Top-level variables vs job-level variables

1variables:           # available to all jobs
2  IMAGE_NAME: alienmushroom/demo-app
3
4build_image:
5  variables:         # only this job; can override top-level
6    DOCKER_TLS_CERTDIR: "/certs"

Does before_script behave differently from script on failure? No – if any command returns a non-zero exit code, the job is marked as failed and subsequent stages do not run.

Keep versions aligned image: docker:20.10.16 and services: docker:20.10.16-dind must use the same version number. A mismatch between CLI and daemon versions can cause unexpected issues.

Fetching private Go modules directly from GitHub in CI/CD easily gets rate-limited (403) when there are too many requests. The fix is to set GOPROXY in your CD yaml to point at an internal Athens proxy server – Athens caches the modules, so subsequent builds never hit GitHub again.

CI / go build
      |
   Athens (internal proxy, with cache)
      | (only on first fetch)
   GitHub / VCS

Explanation

Go has three environment variables that control how modules are fetched:

GOPROXY fallback chain

GOPROXY supports comma-separated sources – Go tries them in order:

GOPROXY=https://internal-proxy.company.com,direct

direct is not another proxy – it means fetching directly from VCS (GitHub). If the internal proxy doesn’t have a particular public module, it falls back to direct.

Knowledge Sugar

Why can’t private modules be sent to sum.golang.org? sum.golang.org is a public service. By default, Go sends the module path there for checksum verification. If a private module’s path gets sent, it leaks internal repo information. Use GONOSUMDB or GOPRIVATE to exclude them.

GOPRIVATE vs setting GOPROXY + GONOSUMDB separately GOPRIVATE=company.com/* is equivalent to setting both GONOSUMDB=company.com/* and GONOPROXY=company.com/* (skip proxy, go straight to VCS). If you’re using an internal Athens proxy, you usually still need to explicitly set GOPROXY, because GOPRIVATE tells Go “don’t use a proxy” – which would bypass your Athens instance and hit GitHub directly.

How to pass a GitHub token in Docker builds? If your Dockerfile runs go build and needs to fetch private modules, don’t use ARG for the token – ARG values end up in the build history and can be recovered from image layers even after the file is deleted.

The correct approach is Docker BuildKit’s secret mount:

1RUN --mount=type=secret,id=github_token \
2    GITHUB_TOKEN=$(cat /run/secrets/github_token) \
3    go build ./...

The secret is only visible during this RUN step and is never written to any image layer.