A Cluster From Hardware to Service Accounts
Trace one enterprise AI workflow request from a physical machine to a pod, then prove which identity that pod can use.
The enterprise problem and today’s slice
Enterprise problem: Teams call a cluster “a group of servers,” then grant a workload broad credentials or mistake a managed control plane for the machines that execute customer work; the result is either an outage with no clear layer or an avoidable data-access incident.
Whole-course context: The incoming evidence is a running managed-cluster workload with a customer request, a pod UID, and a provider resource ID; this day makes the hardware, host software, Kubernetes state, and workload authority behind that evidence explicit.
Today’s slice: We follow a single workflow API request through physical compute, virtual machines, node runtime, Kubernetes scheduling, a pod, and a Kubernetes ServiceAccount; we compare EKS and GKE at the same boundaries.
End-of-day evidence: A trace links request ID, pod UID, node UID, VM or instance ID, resource requests/limits, ServiceAccount, allowed API action, denied action, and immutable test run.
Still unsolved: External identity federation configuration, secret rotation systems, and multi-region disaster recovery remain separate decisions.
Customer use cases
An enterprise platform cannot safely process a customer workflow when operators cannot explain where its CPU, memory, storage, and authority originate. These use cases make placement and least privilege observable.
| Use case ID | Actor | Customer job | Success outcome | Denial or recovery evidence |
|---|---|---|---|---|
| D69-UC-01 | Platform engineer | Run a workflow API replica on capacity that can be traced to real hardware | A request reaches a Ready pod whose node and VM have recorded CPU, RAM, disk, and network allocation | An unschedulable or unready pod names the constrained layer while an existing replica remains healthy |
| D69-UC-02 | Security engineer | Give the workflow API only the authority it needs | The named ServiceAccount can read its permitted ConfigMap or cloud resource through its explicit binding | A probe using a different or unbound ServiceAccount is denied and the approved path remains healthy |
Actor-centred user stories
Placement and authorization become dangerous when a pod name is treated as proof of either capacity or permission. These stories require independently checkable runtime and identity evidence.
| Story ID | Use case IDs | User story | Observable acceptance conditions |
|---|---|---|---|
| D69-US-01 | D69-UC-01 | As a platform engineer, I want to map a workflow request from pod to physical substrate, so that I can diagnose whether compute, memory, disk, network, or scheduling caused a failure | Request, pod, node, VM, allocatable capacity, requests, limits, filesystem claim, and readiness observations share a timestamped run ID |
| D69-US-02 | D69-UC-02 | As a security engineer, I want workload identity separated from node and human identity, so that a compromised pod cannot inherit unrelated authority | Approved ServiceAccount action succeeds; unbound action is denied; Kubernetes RBAC and cloud workload binding are recorded separately |
End-to-end product flows
A request path only becomes dependable when the software process and the resources beneath it can be distinguished. This flow begins with a customer action and ends in a proof that is useful during both capacity and identity failures.
| Flow ID | Use case IDs | Path | Trigger | Numbered steps | Terminal evidence |
|---|---|---|---|---|---|
| D69-FLOW-01 | D69-UC-01 | Happy | Customer submits a workflow | 1. Edge routes the request to a Service. 2. Service selects a Ready pod. 3. The container process uses CPU time, RAM pages, writable filesystem space, and network packets on its node. 4. Kubelet reports status. 5. Trace joins pod, node, and provider-machine identifiers. | Request ID, pod UID, node UID, VM ID, requests/limits, readiness result, environment, timestamp, immutable run ID |
| D69-FLOW-02 | D69-UC-02 | Denied | Probe uses an unbound ServiceAccount | 1. Pod presents its projected ServiceAccount token. 2. API server or cloud identity service evaluates the explicit binding. 3. Requested action is denied. 4. Approved workload repeats its bounded action. 5. Audit records both results. | Actor, ServiceAccount, resource, scope, expected denial, observed denial, approved control, timestamp, audit ID |
The pod is the smallest useful execution box: it is where the application process runs, but it is not the machine and it has no inherent authority beyond the identity explicitly attached to it.
System design derived from the flows
Calling every layer “the cluster” hides where a failure is enforced. A cluster is coordinated software plus the compute substrate it controls: the control plane stores desired state, nodes run workloads, and each node ultimately consumes physical CPU, DRAM, storage, and networking.
| Use case ID | Entry point | Responsible services | Authoritative store | Failure evidence |
|---|---|---|---|---|
| D69-UC-01 | Public workflow endpoint and Deployment | Load balancer, Service, Deployment controller, scheduler, kubelet, container runtime, Linux kernel, provider VM service | Kubernetes API for desired/status state; provider inventory for VM/disk/network identity | Pending with insufficient resource, image/runtime failure, cgroup OOM, disk pressure, node NotReady, or failed probe |
| D69-UC-02 | ServiceAccount token and protected API | Kubernetes API server, RBAC authorizer, projected-token issuer, cloud workload-identity federation where configured | Kubernetes ServiceAccount/RoleBinding state and cloud IAM binding/audit state | Forbidden, token audience/expiry failure, missing binding, or cloud IAM denial |
The retained request, pod, and evidence boxes mean exactly the same thing as above. The node adds host software: kubelet asks the container runtime to create cgroups and mounts; the VM maps the node’s virtual vCPU, RAM, disk, and NIC capacity onto provider hardware. The ServiceAccount is a separate authorization boundary, not a resource reservation.
Data model and ownership
Generated-application database: Not created in this slice — Kubernetes/provider control-plane records and immutable evidence are sufficient; customer workflow data remains in the generated application’s separately owned store.
| Record or entity | Store and owner | Primary key | Foreign key or opaque reference | Tenant key | Material constraint | Lifecycle and deletion | Use case IDs |
|---|---|---|---|---|---|---|---|
| PodPlacementEvidence | Kubernetes API plus evidence store, owned by platform operations | Pod UID plus run ID | Opaque Node UID and provider VM ID | Namespace maps to platform environment | Requests must fit node allocatable capacity; status must identify observed node | Created per revision/run, retained for audit, expired by evidence policy | D69-UC-01 |
| WorkloadAuthorityEvidence | Kubernetes RBAC and cloud IAM audit stores, owned by security platform | Audit event ID | ServiceAccount UID and opaque cloud-principal reference | Namespace/environment | Binding grants only declared verb/resource or cloud scope; no inherited node/human authority | Created on access, revoked by binding removal, retained then expired by policy | D69-UC-02 |
Capacity and authorization now produce the same reviewable evidence without becoming the same authority. A managed EKS or GKE control plane operates the API-server substrate, while the selected node mode determines who configures worker machines; in either case the workload owner still defines requests, limits, ServiceAccounts, application data access, and customer outcome.
Code-to-reality: a pod identity on a node
This manifest declares desired software state; it does not directly allocate a physical server. The scheduler interprets requests against node allocatable capacity, kubelet and the runtime create the process sandbox, and the API server issues the projected identity token.
apiVersion: v1
kind: ServiceAccount
metadata:
name: workflow-api
namespace: platform
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: workflow-api
namespace: platform
spec:
template:
spec:
serviceAccountName: workflow-api # Selects workload identity; it is not a human login.
containers:
- name: api
image: registry.example/workflow-api@sha256:REPLACE_ME
resources:
requests: { cpu: "500m", memory: "1Gi" } # Scheduler placement input.
limits: { memory: "2Gi" } # Linux cgroup memory ceiling.
| Declaration | Interpreter and software state | Compute, memory, and storage effect | Observable proof |
|---|---|---|---|
requests | Scheduler records a placement requirement | Reserves schedulable vCPU/RAM accounting; it does not pre-fill DRAM | kubectl describe pod shows node and requests |
limits.memory | Kubelet/runtime writes cgroup limit | Process may use physical RAM until its cgroup ceiling; excess can terminate it | OOMKilled status and node metrics |
serviceAccountName | API server mounts a short-lived projected token | Consumes negligible node storage; changes no CPU/RAM entitlement | kubectl auth can-i and audit event show allowed/denied scope |
Run, fail, and recover
kubectl -n platform get pod -l app=workflow-api -o wide # Join pod to Node.
kubectl -n platform describe pod POD_NAME # Read requests, limits, events, and ServiceAccount.
kubectl get node NODE_NAME -o wide # Join Node to provider instance identity.
kubectl auth can-i get configmaps --as=system:serviceaccount:platform:workflow-api -n platform
kubectl auth can-i get secrets --as=system:serviceaccount:platform:unbound -n platform # Expected denial.
Decision rule: diagnose a workload incident from the enforcing layer outward: process/cgroup, node allocatable capacity, VM/provider capacity, then control plane. Grant a ServiceAccount only the verb, resource, namespace, and cloud scope the workload demonstrably needs; node credentials and human credentials are separate identities.
Primary references
Kubernetes ServiceAccounts provide an identity for processes running in Pods and must be granted authority through explicit policy; see Kubernetes ServiceAccounts. For managed implementations, compare the EKS security model with GKE cluster architecture.
Key takeaways
- A cluster combines control-plane software, nodes, and the physical substrate behind those nodes.
- CPU, memory, storage, and identity are different mechanisms with different enforcing software.
- Managed control planes reduce provider-operated work; they do not make workload resource or access decisions disappear.
Checklist
- [ ] Joined one request to pod, node, VM, and capacity evidence.
- [ ] Proved one allowed ServiceAccount action and one denied action.
- [ ] Distinguished control-plane, node, workload, and generated-application ownership.