Access Control

Everything about who can sign in and what they may do lives under IAM & Security. The model is the same for every connected cloud, so one set of users, projects and roles governs all of them. For the concepts behind it, see Core concepts.

Typical setup

1. Decide on domains. Stay in the Default domain if a single organization uses Constella. Create a domain per tenant (a subsidiary or a customer) when each must manage its own users and projects independently.
2. Create projects that mirror how you account for resources, for example one per team, application or environment.
3. Add users, or connect a directory so users sign in with their existing accounts (see below).
4. Put users or groups into projects with a role. A user without a project can sign in but sees nothing.
5. Set quotas on projects if you want to cap what each one may create.

Domains, projects, users and groups

Menu	What you do there
Domain	Create tenants. Each domain has its own users, groups, projects and roles, and can have its own administrators.
Project	Create projects, add users or groups with a role, set quotas, and see the resources a project owns.
Group	Collect users so you can add them to projects together.
User	Create users, reset passwords, enable or disable sign-in, and see which projects a user belongs to.

Roles and permissions

• Roles are what a user is in a project. The built-in roles cover the common cases, and you can add your own:

  Built-in role	Meant for
  project_viewer, project_editor, project_owner	Read-only, day-to-day operation, and full control of one project
  domain_viewer, domain_editor, domainadmin	The same levels across a whole domain
  admin	Full control of the platform
  sys_secadmin, sys_opsadmin, sys_adtadmin (and domain_… equivalents)	Separated security, operations and audit administrators, for organizations that must split these duties

• Permissions (policies) list the actions a role may perform. They can be scoped to the whole system, one domain, or one project. When a user holds several roles, the most permissive policy applies.

Keep the built-in policies unchanged and create new ones when you need something narrower. Built-in policies are the fallback if a custom policy turns out to be wrong.

Cloud Shell is limited to sessions that hold the system sysadmin policy, which the admin role in the system project grants, because commands in it run with full platform rights. See Cloud Shell.

Sign-in sources

Authentication Domain connects Constella to external identity systems:

Source	Use it for
LDAP / Microsoft Active Directory	Users sign in with their directory account. Users and groups are synchronized into a Constella domain.
SAML 2.0	Single sign-on through an identity provider such as ADFS, Azure AD (Entra ID) or Okta
OpenID Connect, OAuth2	Single sign-on through providers that speak OIDC or OAuth2
CAS	Single sign-on through a CAS server

When a source is configured, the sign-in page offers it next to the username and password form.

Security alerts

Security Alerts lists security-related events the platform has raised, with when each was triggered and what it was about. Review it regularly, or route these events to people with a notification topic.