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, 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: when removing a single cluster, the same role could be accidentally deleted, effectively killing CAST AI in other clusters.
CAST AI does not use IAM users for EKS.
To be on the safe side and follow best practices, first, disable access keys for the user and remove the user only after some time (for example, 7 days). This way you would have a fallback and could re-enable keys in case this user is used for some reason.
We are setting up SSO with help from the guide and used this API as the redirect URL to register the app in AzureAD. However, it differs from the format we see in the Auth0 documentation. Can you help us validate what the right value is in this case?
Check if you can you update the value with this, which is the correct one from here.
SSO users have no impact on basic Auth0 users; it will continue to work as expected.
CAST AI offers the following roles out of the box:
- Owner - Full access to clusters, billing, and organizations management.
- Member - Full access to clusters. View-only access to billing.
- Viewer - View-only access to clusters and billing.
- Analyst - Full access to cost monitoring, view-only access to clusters and billing.
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.
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 in "NodeConfiguration" specify which keypair to inject into the new VM so that SSH access would work.
CAST AI doesn't check KeyPair permission during credential validation.
The user roles, as defined in your Azure AD, remain entirely unchanged from the CAST AI end. They stay consistent both before and after the SSO integration.
Yes, you can use the same API key to delete the integration.
The CAST AI system follows the current API permissions in our documentation. User data isn't processed by CAST AI; 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.
CAST AI SSO by default, assigns users the Viewer role.
Updated 14 days ago