Role-Based Access Control (RBAC)

Understanding RBAC in Cast AI

Role-based access control (RBAC) in Cast AI enables fine-grained access management for your organization's resources. It allows you to control who can access what within your organization and clusters, ensuring security and operational efficiency.

Roles and permissions

Cast AI uses predefined roles to streamline access management. Each role comes with a specific set of permissions designed for common use cases:

  • Owner role has full administrative access to all organization and cluster resources. This role is typically assigned to platform team members who manage the entire organization.

  • Member role can perform all cluster-related operations but has limited access to organizational features like billing (read-only) or adding more users. This role suits DevOps engineers and cluster administrators.

  • Viewer role provides read-only access across all features, making it perfect for team members who need visibility but shouldn't make changes.

  • Analyst role specializes in cost monitoring, with full access to cost-related features while maintaining read-only access elsewhere. This role is designed for FinOps teams and financial analysts.

  • Schedule Manager role can manage rebalancing and hibernation schedules across the organization, with no other permissions. This role suits users or service accounts that automate cost-optimization schedules (for example, via the API, Terraform, or Crossplane) without full organization Owner access. See Schedule Manager scope and coverage.

CapabilityOwnerMemberAnalystViewerSchedule Manager
Connecting clusters✓----
Cluster management✓✓View onlyView only-
Hibernation schedule management✓---✓
Rebalancing schedule management✓---✓
Rebalancing job management✓---✓
Manual rebalancing (plans)✓---✓
Billing access✓View onlyView onlyView only-
Cost monitoring✓✓✓View only-
Organization management✓----
Invite/remove members✓----
Service account API key creation✓----

Schedule Manager scope and coverage

The Schedule Manager role's permissions, as shown in the Console under View permissions when configuring a role binding:

clusterOptimization.hibernationSchedules.create
clusterOptimization.hibernationSchedules.delete
clusterOptimization.hibernationSchedules.read
clusterOptimization.hibernationSchedules.write
clusterOptimization.rebalancing.create
clusterOptimization.rebalancing.delete
clusterOptimization.rebalancing.read
clusterOptimization.rebalancing.write

These are the role's only permissions. What they cover depends on the scope of the role binding.

Organization scope — required for managing schedules. Rebalancing and hibernation schedules are organization-scoped objects that can be assigned to multiple clusters (see Scheduled rebalancing), so no cluster-scoped binding can manage them, even with the Owner role:

Cluster scope — for the assigned clusters only:

  • Rebalancing jobs: link a rebalancing schedule to a cluster so the schedule runs on it, and view or remove those links
  • Manual rebalancing: generate, execute, and cancel rebalancing plans (see Rebalancing)

Not covered at any scope: hibernation pause/resume operations (the separate clusterOptimization.clusterHibernationJobs permission resource, held by Owner).

Enterprise roles

If your organization uses Enterprise organizations, two additional roles are available that span the parent Enterprise and all child organizations:

  • Enterprise Owner — full access to all product features, including organization management for the parent Enterprise and all child organizations.
  • Enterprise Viewer — read-only access to all product features, including organization management for the parent Enterprise and all child organizations.

Enterprise roles are assigned at the Enterprise level. Standard organization roles (Owner, Member, Viewer, Analyst) still apply within individual child organizations. A user can hold an Enterprise role and a child organization role simultaneously.

💡

Tip

Need to find out who in your organization has a specific role? Go to View Org → Access control → Resources → Organization to see all users and their current role assignments.

Resource scope

When assigning roles, you can control their scope of access:

  • Organization scope grants access to all clusters and organization-wide features like billing and SSO configuration. This broad access is suitable for platform teams and administrators managing multiple clusters.

  • Cluster scope restricts access to specific clusters. This granular control allows you to limit team members' access to only the clusters they need to work with, following the principle of least privilege.

  • Enterprise scope grants access across all child organizations' resources. This scope is available only with Enterprise roles (Enterprise Owner, Enterprise Viewer) and is assigned at the Enterprise level. See Enterprise organizations.

User Groups

User Groups simplify access management at scale by allowing you to:

  • Group users with similar access needs under a single policy
  • Manage permissions at the group level instead of individual users
  • Automatically handle access through your Identity Provider (IdP) groups (Coming soon!)
  • Apply consistent access policies across teams

For example, you might create separate groups for your platform team, application developers, and financial analysts, each with appropriate roles and resource access.

Service Accounts

Service Accounts enable automated access to Cast AI resources, which is particularly useful for:

  • CI/CD pipelines requiring programmatic access
  • Infrastructure as Code tools like Terraform
  • Automation scripts and system integrations

Each Service Account can:

  • Have its own set of roles and permissions
  • Generate API keys for secure authentication
  • Be managed independently of user accounts

Service Accounts follow the same RBAC model as user accounts, ensuring consistent security policies across both human and automated access.

📘

Note

When you delete a user from your organization, all API keys associated with that user get deleted as well. Employing Service Accounts and using their API keys instead to ensure consistent, uninterrupted functionality allows you to circumvent many potential issues.

Managing RBAC programmatically

Cast AI's RBAC system can be managed not only through the console but also programmatically through our API and Terraform provider.

API Management

All RBAC operations are available through the Cast AI API, enabling you to:

  • Create and manage users and service accounts
  • Configure user groups and their permissions
  • Assign and modify role bindings

For detailed API documentation, visit our API Reference.

Terraform Provider

The Cast AI Terraform provider offers comprehensive RBAC management capabilities, allowing you to:

  • Define and maintain RBAC configurations as code
  • Automate user and group management
  • Ensure consistent access patterns across organizations

Example Terraform configuration for creating a service account:

resource "castai_service_account" "service_account" {
  organization_id = organization.id
  name            = "example-service-account"
  description     = "service account description"
}

resource "castai_service_account_key" "service_account_key" {
  organization_id    = data.castai_organization.test.id
  service_account_id = castai_service_account.service_account.id
  name               = "example-key"
  active             = true
  expires_at         = "2025-01-01T00:00:00Z"
}

output "service_account_key" {
  value = castai_service_account_key.service_account_key.token
}

For more information and examples, see our Terraform Provider Documentation.

Next steps

Configure Service Accounts →

Manage User Groups →

Learn about SSO Integration →


Did this page help you?