Permissions, users, Orgs, and SSO

Can a different user be specified than expected during Cast AI onboarding?

It was a conscious design decision not to reuse the same role/serviceAccount/servicePrinciple as best practice to avoid operational and security risks. The role gets narrow permissions for this specific VPC and EKS with a specific tag-based IAM policy, which is the bare minimum needed for Cast AI to do autoscaling.

Having one role spanning multiple clusters would mean giving Cast AI permissions not limited to scope. It also brings operational risk: the same role could be accidentally deleted when removing a single cluster, effectively killing Cast AI in other clusters.

Is it possible to transfer clusters between organizations?

Currently, there is no built-in method to transfer clusters between organizations. To achieve this, you would need to disconnect the cluster from organization A and connect it to organization B.

Why does Cast AI require adding, deleting, or assigning a keypair? Does it require any ability to SSH?

Cast AI doesn't depend on or need SSH access.

However, as Cast AI takes over creating VMs, some customers still want to retain SSH access to their nodes. In this scenario, customers can specify in "NodeConfiguration" which keypair to inject into the new VM so that SSH access will work.

Cast AI doesn't check KeyPair permission during credential validation.

Can Cast AI SSO use claims in the JWT to get user data without checking the directory?

The Cast AI system follows the current API permissions in our documentation. Cast AI doesn't process user data; it's verified by our identity provider, Auth0, to confirm the user's identity. We don't store these details, and Auth0 manages them securely during integration setup.

Which role are SSO users assigned when they initially sign in?

Cast AI SSO by default assigns users the Viewer role.