Skip to main content
The controller operates with a tiered permission model. Some permissions are always active (the controller needs them to do its job), and others are on-demand - you control whether they’re enabled.

​
Permission Tiers

​
Always Active

These permissions are required for the controller to function:

​
On-Demand (You Control These)

These permissions enable troubleshooting and operational support. They are off by default and can be enabled or disabled at any time:

​
What the Controller Cannot Do

Regardless of which permission tiers are enabled:
  • Cannot access resources outside the deployment - The controller is scoped to the cluster dedicated to this deployment
  • Cannot read your secrets - The controller can detect whether required secrets exist, but cannot read their values from outside its scope
  • Cannot access your cloud account beyond the deployment - IAM roles (AWS) or service accounts (Kubernetes) are scoped to the specific resources the deployment manages

​
Implementation Details

Each permission tier corresponds to:
  • A ClusterRole - defines what actions are allowed on what resources
  • A ClusterRoleBinding - grants those permissions to a service account
  • A ServiceAccount - the identity the controller uses
This gives the controller cluster-wide visibility, which is appropriate because the entire cluster is dedicated to this deployment.

​
Viewing Current Permissions

List the active cluster role bindings: