Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt

Use this file to discover all available pages before exploring further.

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:
TierWhat It DoesWhy It’s Needed
Steady-stateMonitors the application’s health, reads pod status and eventsThe controller needs to know if the application is running correctly
InstallCreates and updates infrastructure resourcesRequired for initial deployment and upgrades
DeployCreates and modifies application workloadsRequired to deploy new versions of the application

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:
TierWhat It DoesWhen You’d Enable It
Read-only operationsView logs, describe resources, check eventsWhen we need to diagnose an issue without making changes
Read-write operationsRestart pods, apply patchesWhen we need to remediate an issue (e.g., restart a stuck pod)
Admin operationsExecute commands inside containers, port-forwardFor deep troubleshooting of complex issues

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:
kubectl get clusterrolebindings | grep <namespace>