Kubernetes agent-operation authority

Use admission control or a governed API proxy for mutation, with RBAC as baseline.

01 / Principal and identity

Who acts, and what can the platform identify?

An operations agent uses a Kubernetes service account.

Service-account token and RBAC identify the API caller and allowed verbs/resources.

Trace the proposed action
  1. 01Originating task
  2. 02Agent or workload
  3. 03It deletes a deployment or changes replica count.
  4. 04Observed effect

02 / Action-time control

Where can an unauthorized effect be stopped?

Use admission control or a governed API proxy for mutation, with RBAC as baseline.

Bind cluster, namespace, workload, verb, desired state and incident window.

SubjectVerified caller and task
RequestOperation, target and values
OutcomeDecision, attempt and state

Delegation constraint

A child observer with a read task must not reuse the parent’s mutation token.

03 / Worked denial

Test a request outside the grant.

An agent asked to diagnose latency attempts to scale production replicas to zero.

Adversarial verification

Use a service account with deployments/update permission and submit replicas=0 for production. Confirm admission or protected API policy rejects the mutation while allowing an authorized read.

04 / Review and responsibility

What should the audit trail prove?

Service account, request UID, namespace, object diff, task grant, admission decision and observed workload state.

Admission coverage and direct paths must be tested; authorization cannot guarantee rollout health.

Platform primary source

Check the current execution model

Architecture discussion

Map one consequential action in your environment.

Request a Conversation