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.

An application deployed on GKE can use OIDC federation to exchange a Kubernetes-issued JWT token for temporary AWS credentials, eliminating the need to hardcode AWS Access Keys.

Explanation

What OIDC does in this scenario

OIDC (OpenID Connect) is essentially a protocol for “let me prove this identity is real.” In this use case, GKE acts as the OIDC Identity Provider (IdP), and AWS is the party that trusts what GKE says.

The overall flow looks like this:

GKE Pod
  │
  │ 1. Kubernetes automatically mounts a Service Account JWT token on the Pod
  │    (this token contains the workload's identity info, signed by GKE)
  │
  ▼
AWS STS (AssumeRoleWithWebIdentity)
  │
  │ 2. Submit the JWT token to AWS STS
  │    AWS validates the token against GKE's OIDC endpoint
  │
  ▼
Temporary AWS credentials (Access Key + Secret + Session Token)
  │
  │ 3. Use temporary credentials to operate on S3
  │
  ▼
S3 Bucket ✓

sequenceDiagram
    participant Pod as GKE Pod
    participant STS as AWS STS
    participant OIDC as GKE OIDC
    participant S3

    Note over Pod: K8s mounts JWT token
    Pod->>STS: AssumeRoleWithWebIdentity(JWT)
    STS->>OIDC: Verify signature
    OIDC-->>STS: OK
    STS-->>Pod: Temporary credentials (with TTL)
    Pod->>S3: Upload CSV
    S3-->>Pod: 200 OK

What needs to be configured in Terraform

1. AWS IAM OIDC Provider – tells AWS “I trust tokens issued by this GKE cluster”; requires the GKE OIDC issuer URL and thumbprint
2. AWS IAM Role + Trust Policy – defines which GKE service account can assume this role; the condition typically requires the sub claim to match system:serviceaccount:<namespace>:<ksa-name>
3. S3 Permission – attach the S3 read/write policy to this IAM Role

Go STS package upgrade

In the Go application, use AssumeRoleWithWebIdentity, passing in the JWT token path read from the Pod (typically /var/run/secrets/kubernetes.io/serviceaccount/token). After exchanging for temporary credentials, initialize the S3 client. The package upgrade was mainly to ensure compatibility with SDK v2’s credential provider interface.

Knowledge Sugar

Why not just use AWS Access Keys? Hardcoding keys has rotation issues, leakage risks, and makes it hard to audit which workload is accessing what. OIDC federation’s temporary credentials have a TTL and expire automatically, making them significantly more secure.

What’s inside the JWT token? The token issued by GKE is a standard JWT. The payload contains:

• iss: OIDC issuer (the GKE cluster’s URL)
• sub: system:serviceaccount:<namespace>:<name>
• exp: expiration time

When AWS STS receives the token, it fetches the public key from the iss URL’s /.well-known/openid-configuration endpoint to verify the signature.

How is the JWT token mounted into the Pod? This is a built-in Kubernetes mechanism – every Pod automatically gets a Service Account token mounted at creation, no extra config needed. However, the default token doesn’t specify an audience, which AWS STS won’t accept. So you need to mount a dedicated one using a projected volume in the Pod spec:

1volumes:
2  - name: aws-token
3    projected:
4      sources:
5        - serviceAccountToken:
6            audience: sts.amazonaws.com # here!
7            expirationSeconds: 3600
8            path: token

Terraform only handles the AWS side (OIDC Provider, IAM Role); the token mounting itself is done by Kubernetes.

The official name for this pattern: Workload Identity Federation GCP’s own Workload Identity uses the same principle, just with GCP resources. For cross-cloud scenarios (GKE -> AWS), OIDC serves as the universal standard that bridges them.