Modern Kubernetes environments are not difficult to operate; they are difficult to govern.
In a typical production cluster, developers regularly scale deployments, restart services or inspect logs during incidents. These Day-2 activities are routine. The simplest way to enable them is to grant kubectl access.
At first, it works. Teams move quickly.
But over time, kubeconfig files spread across machines, permissions expand “temporarily,” and operational practices begin to vary. Audit logs capture what changed, but not always the context behind it.
Kubernetes RBAC can control which actions are allowed. The harder problem is controlling how those actions are executed.
The challenge is not authorization alone. It is execution governance.
Solving this requires rethinking how operational access is granted and enforced, not by expanding permissions, but by restructuring execution itself.
Progress Chef 360 introduces a different approach. Instead of granting developers direct Kubernetes API access, operational actions are executed through governed jobs. These jobs run within the cluster using Courier Runner, operating under native Kubernetes identity and RBAC.
This shifts the model from direct access to intent-driven execution. Kubernetes continues to enforce permissions through RBAC. Chef 360 governs how those permissions are exercised.
The process begins in the ticket management system, where a task is created to increase the replica count of the demo-app deployment in the platform-demo namespace.
Opening the task shows the request details: the application currently requires scaling to three replicas. The request is tracked, prioritized and assigned within the workspace.
At this point:
No direct Kubernetes action has been performed yet.
The developer does not have direct access to the Kubernetes API.
Instead of executing commands using kubectl, direct interaction with the cluster is restricted.
Any requested action must go through a controlled workflow or approved process before execution.
Switching to the Kubernetes Platform demo Dashboard, we can see the current state of the workload:
The scaling command is evaluated by the Kubernetes API server.
The API server performs an authorization check against the user’s RBAC bindings.
The system verifies whether the user has permission to perform the requested action.
The user’s identity does not have permission to patch deployments in the namespace.
As a result, the request is denied by the Kubernetes API server.
This is where the operating model shifts from direct access to governed execution.
Instead of expanding permissions or granting direct cluster access, operational changes are executed through Courier Runner.
Courier Runner operates as an in-cluster execution agent. It runs as a pod within the Kubernetes namespace and authenticates using a dedicated ServiceAccount. Its permissions are defined through Kubernetes RBAC and scoped to specific verbs and resources, ensuring strict least-privilege enforcement.
When a job is triggered from Chef 360, Courier Runner interacts with the Kubernetes API using its ServiceAccount identity. The API server evaluates the request against the configured Role or ClusterRole bindings before allowing execution.
Because execution occurs entirely within the cluster boundary, there is no kubeconfig distribution, no external credentials and no reliance on SSH or privileged network access.
Inspecting the Courier Runner deployment confirms this model in practice. The associated ServiceAccount is authorized to patch deployments within the namespace, enabling scaling operations, while access to cluster-level resources such as nodes remains explicitly denied.
The platform operator logs into the Chef 360 platform.
Login to your Chef360 platform
Courier allows multiple options for creating jobs.
Jobs can be created by building a custom job.
Users can also use a pre-built template to create a job.
Another option is to duplicate an existing job.
In this scenario, an existing job is duplicated.
The duplicated job is then configured for the target cluster.
Once executed, Chef 360 sends the instruction to the Courier Runner running inside the Kubernetes environment. After successful completion, the job status is marked accordingly within the Chef 360 platform.
One of the key capabilities of the Chef 360 Platform is the ability to programmatically create and execute Courier jobs using REST APIs. This allows external systems, such as ticketing platforms, CI/CD pipelines, or custom automation scripts, to trigger operational workflows without manual intervention.
Courier jobs define what actions to perform, when to execute them, and which nodes should run them. These jobs can then be triggered through the Chef 360 UI, CLI, API, or scheduled workflows.
In practice, this means organizations can build intent-driven automation pipelines in which external systems generate job requests and Chef 360 executes them under controlled RBAC policies.
Example: Injecting Ticket Data Using the Chef 360 CLI
This script simulates extracting data from a ticket and automatically creating a Chef 360 job with the required parameters.
Why API-Driven Jobs Matter
API-driven job execution enables Chef 360 to act as a central orchestration layer for infrastructure automation.
Instead of running operational commands manually, external systems can create jobs automatically, while Chef 360 ensures:
Controlled execution
Rule enforcement
Auditability
Repeatability
Integration with existing DevOps workflows
To know more about Chef 360 platform APIs, follow this link.
Returning to the application and refreshing the deployment view, the updated desired state is reflected. Kubernetes reconciles the Deployment resource through its controller loop, creating additional pods until the replica count reaches three.
The ticket management system automatically marks tickets as completed, demonstrating integration with external systems and full workflow traceability.
While this example focuses on a single namespace within one cluster, the same job definition can be applied consistently across multiple Kubernetes environments.
Because execution is abstracted through Chef 360 and Courier Runner, platform teams can standardize operational workflows without distributing credentials or duplicating access models.
The change was executed through a policy-driven workflow in Chef 360, with execution handled by an in-cluster agent operating under strictly defined RBAC controls. Execution remains entirely within the Kubernetes control plane, eliminating the need for distributed kubeconfig files, elevated user privileges, embedded credentials, or direct node access.
Every action:
Executes from within the Kubernetes cluster
Operates strictly under RBAC-defined permissions
Is triggered through Courier job orchestration
Remains fully auditable within the Chef 360 control plane
This approach represents a structural shift in Kubernetes operations. Developers express intent through controlled requests, while execution is performed by a governed, in-cluster identity operating within clearly defined authorization boundaries.
By separating intent from execution, platform teams enable change without sacrificing control. Governance remains enforced. Access remains constrained. Auditability remains continuous.
Link for the Technical Demo
To experience the capabilities of Progress Chef, book a trial with us today!