One policy, two places: Chenile in action

On camera: “Last episode’s problem was drift — the same policy written twice, in two tech stacks. Chenile’s answer is almost annoyingly simple: there’s only one kind of policy.”

Voiceover: “A policy is a Chenile interceptor. The exact same interceptor contract runs inside the auth gateway from chenile-security, and inside every service’s interception pipeline at the last mile. You don’t write two versions. You write one, and choose where it runs.”

Two boxes — Gateway and Last mile — with the caption “same interceptor contract in both.” Arrows show the registry pushing a policy into either box.

Attach an authorization policy to a service via its service-registry entry (extension keys). Call the service directly; show it enforced at the last mile with full resource context.

Bring up the Chenile auth gateway (gateway starter). Configure authentication + a coarse check at the edge. Send an unauthenticated request; it’s rejected before reaching the service. “Same abstraction, different site.”

Now run both: authenticate at the edge, authorize the specific resource at the last mile. Send a request from a valid user for a resource they don’t own; edge lets it in, last mile blocks it. “Defence in depth, one policy model.”

Voiceover: “Moving a policy from last mile to gateway, or adding it in both, is a registry change — not a refactor. Placement is configuration.”

Mention chenile-proxies (interface calls, local or remote) and chenile-messaging (MQTT, Kafka, Azure, in-JVM). “The same policy can guard an HTTP call, an internal proxy call, and a message off a queue.”

Lower third: “Write a policy once. Run it at the gateway, the last mile, or both — chosen by configuration.”

“One interceptor abstraction, two deployment sites, placement by service-registry config. No drift.”