The 5-Tier Request Classifier

The Classification Problem

Every Kubernetes API request needs a risk assessment. kubectl get pods is safe. kubectl delete namespace production is catastrophic. Between those extremes lies a spectrum of operations with varying blast radius and reversibility.

Iddio classifies every request into one of five tiers. The classification happens before the request reaches the real cluster, in sub-millisecond time, with zero network calls.

The Five Tiers

Tier 0 — OBSERVE. Read-only by default. All GET, HEAD, and OPTIONS requests. Full visibility, zero blast radius. Examples: kubectl get, kubectl logs, kubectl describe, kubectl top.

Tier 1 — OPERATE. Pre-approved runbook operations. Common, well-understood writes that match a sanctioned pattern. Examples: kubectl scale, kubectl rollout restart (when matched by a runbook).

Tier 2 — MODIFY. Standard write operations. POST, PUT, and PATCH requests that create or update resources. These require human approval by default. Examples: kubectl apply, kubectl create, kubectl patch.

Tier 3 — SENSITIVE. Irreversible or security-sensitive operations. All DELETE requests, secret reads, and pod evictions. These always require quick operator confirmation. Examples: kubectl delete pod, kubectl get secret, pod eviction.

Tier 4 — BREAK-GLASS. Highest-risk operations. Interactive access (exec, attach, portforward), mutations on RBAC resources, webhook configs, CRDs, namespaces, and persistent volumes. Blocked by default. Examples: kubectl exec, kubectl delete namespace, kubectl port-forward.

Classification Algorithm

The classifier examines three dimensions of each request:

1. HTTP Method — GET/HEAD → low risk, DELETE → high risk, POST/PUT/PATCH → medium risk
2. Resource Type — pods are lower risk than namespaces; deployments are lower risk than RBAC roles
3. Subresource — accessing pods/log is read-only, but pods/exec is break-glass

func (c *Classifier) Classify(method, resource, subresource string) int {
    // Break-glass subresources — always T4
    if isBreakGlass(subresource) {
        return TierBreakGlass
    }

    // GET on secrets is sensitive (T3), not observe (T0)
    if method == "GET" && resource == "secrets" {
        return TierSensitive
    }

    // All other reads
    if method == "GET" || method == "HEAD" || method == "OPTIONS" {
        return TierObserve
    }

    // DELETE is always sensitive
    if method == "DELETE" {
        // Namespace/PV/CRD deletion is break-glass
        if isCriticalResource(resource) {
            return TierBreakGlass
        }
        return TierSensitive
    }

    // Writes to critical resources are break-glass
    if isCriticalResource(resource) {
        return TierBreakGlass
    }

    // Standard writes
    return TierModify
}

Break-Glass Subresources

These subresources are always classified as T4, regardless of the HTTP method:

• exec — interactive shell into a container
• attach — attach to a running container’s stdin/stdout
• portforward — tunnel a local port to a pod
• proxy — proxy raw HTTP to a pod

These grant direct, interactive access to running workloads — the highest-risk operations in Kubernetes.

Critical Resources

Mutations on these resources are classified as T4:

• namespaces — deleting a namespace cascades to everything in it
• persistentvolumes — data loss risk
• customresourcedefinitions — can break controllers and operators
• clusterroles / clusterrolebindings — RBAC escalation
• mutatingwebhookconfigurations / validatingwebhookconfigurations — can intercept all API traffic

The Secret Read Exception

One notable classification: GET /api/v1/namespaces/*/secrets/* is T3 (sensitive), not T0 (observe). Reading a secret is technically a read operation, but secrets contain credentials, API keys, and TLS certificates. An AI agent listing secrets and reading their values is a significant security event that should be audited and potentially escalated.

Performance

Classification is a pure function over three strings. No network calls, no database lookups, no file I/O. In benchmarks, classification takes 50-200 nanoseconds per request — well under the microsecond threshold. This is important because classification happens on every single request through the proxy.

BenchmarkClassify/GET_pods-12         23847298    50.2 ns/op    0 B/op   0 allocs/op
BenchmarkClassify/DELETE_pod-12       22934182    52.1 ns/op    0 B/op   0 allocs/op
BenchmarkClassify/POST_deploy-12      23102847    51.8 ns/op    0 B/op   0 allocs/op
BenchmarkClassify/GET_secret-12       22891023    52.4 ns/op    0 B/op   0 allocs/op
BenchmarkClassify/exec_subresource-12 23441029    51.0 ns/op    0 B/op   0 allocs/op

Zero allocations per classification. The classifier uses only stack-local variables and string comparisons.