Access control
Who in your team can do what in Facets, per project and per environment, and signing in with your own identity provider.
Roles decide what someone can do in Facets, and user groups decide where.
Who can do what
Access is set per team and per environment.
- given to a
- assigned to
An environment-specific role replaces a user group's default role in one environment, such as Viewer in production.
A resource group limits a user group to some resources, and a Kubernetes role sets what someone can do in an environment's cluster.
The web UI, the Praxis CLI, the API and Praxis all work within the role of the account using them.
Single sign-on
Single sign-on is set up in the web UI, over SAML (Okta and Google) or OAuth (Google, Microsoft Entra ID, Okta, OneLogin, JumpCloud and any OpenID Connect provider).
- Roles stay in Facets: it doesn't read groups from your identity provider.
Approvals and guardrails
What your AI assistant can change through Praxis, where you review it, what happens when it's wrong, and how to block a change.
Cloud and Git access
What Facets needs in your cloud and Git accounts and why, how to narrow it, the identity it acts as, and where your setup is stored.