Why Runbooks Reject Conditional Logic

The Request for Conditions

When operators start using iddio’s runbook engine, the first feature request is usually conditional logic. The YAML schema allows matching by HTTP methods, resources, and subresources, which downgrades the operation’s tier (typically T2 to T1). But teams often want rules like:

• “Allow restarting the deployment only if it has fewer than 3 replicas.”
• “Allow the agent to delete the pod only if it has been running for more than 24 hours.”
• “Allow patching the service only during business hours.”

It’s a natural request. But we decided against building conditional logic into the native runbook engine. The engine remains purely static: method, resource, subresource. Here is the technical reasoning behind that constraint.

1. Auditability at a Glance

The most critical property of a security policy is that an operator can read it and instantly understand the effective permissions.

With our current runbook schema, a security-conscious operator can look at:

runbooks:
  restart-deploy:
    operations:
      - methods: [PATCH]
        resources: [deployments]

…and immediately know exactly what it permits. The surface area is minimal.

If we introduced conditional logic (“if replicas < 3”), the runbook would suddenly require state evaluation. The operator reading the YAML no longer knows if the agent can restart the deployment — it depends on cluster state at execution time. This makes the policy non-deterministic from a static analysis perspective, severely complicating audit reviews.

2. The 200-Nanosecond Performance Budget

Iddio classifies every Kubernetes API request before it reaches the real cluster. Our native classifier operates over three strings (method, resource, subresource) with zero allocations. Benchmarks show classification taking 50-200 nanoseconds per request.

Evaluating stateful conditions like “deployment replicas < 3” would completely destroy this performance profile. It would require:

1. Pausing the classification pipeline.
2. Making an upstream HTTP GET request to the Kubernetes API server to fetch the current deployment state.
3. Parsing the JSON response into a struct.
4. Evaluating the condition.

This turns a 50-nanosecond operation into a 5-millisecond operation, introducing network latency, JSON unmarshaling overhead, and failure modes (what if the upstream GET fails or times out?) into the critical path of every request.

3. Chained Operations and Statefulness

Another common request is chained operations: “allow restart only after a health check.”

This breaks the fundamental statelessness of HTTP proxies. To enforce chained operations, iddio would have to maintain state machines for every active agent, tracking which commands they have successfully run recently. If an agent runs a health check, iddio must store that state, wait for the restart command, correlate the two, and then expire the state.

This introduces cache invalidation problems, distributed state complexity for the Enterprise control plane (if the health check hits proxy A but the restart hits proxy B), and memory exhaustion vectors.

The Escape Hatch: OPA/Rego

Deciding against conditional logic in the native engine doesn’t mean we ignore the use case. It means we push the complexity to a system designed for it.

For complex conditional policies, iddio provides the OPA/Rego integration (available via the opa build tag). Open Policy Agent is explicitly built for complex, cross-cutting constraints, and the Rego language handles time-based conditions and external data sources natively.

# Example Rego policy for business hours
decision = {"action": "allow", "reason": "business hours"} {
    input.tier == 1
    hour := time.clock(time.now_ns())[0]
    hour >= 9
    hour < 18
}

By pushing complex logic to OPA, we keep the default iddio binary small (~12MB), dependency-free, and lightning-fast for the 80% of use cases that just need simple static pre-approvals. Teams that need the remaining 20% can opt-in to the opa build tag and accept the performance and complexity tradeoffs intentionally.