> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage users on Astro Private Cloud

Astro Private Cloud allows you to adjust permissions for each user role and define how new users join your organization.

Use this guide to learn about customizing user signups and user roles, as well as how to use Astro Private Cloud system-level permissions. For a list of the default permissions for each role, see [User roles and permissions](/docs/astro-private-cloud/v-1-x/role-permission-reference).

To learn more about managing users through your identity provider (IdP), see [Import IdP groups](/docs/astro-private-cloud/v-1-x/import-idp-groups).

## Add users to Astronomer

When Astro Private Cloud is first deployed, the first user to log in is granted "System Admin" permissions by default. From there, a user is created on Astro Private Cloud by any of the following:

* Invitation to a Workspace by a Workspace Admin
* Invitation to Astronomer by a System Admin
* Signing up via the Astro Private Cloud UI without an invitation (requires "Public Signups")
* Imported to Astronomer through an [IdP group](/docs/astro-private-cloud/v-1-x/import-idp-groups)

As a System Admin, you can open the platform to public signups, limit account creation to users invited by others, or make it so that users can only join the platform as part of an [IdP-based Team](/docs/astro-private-cloud/v-1-x/import-idp-groups).

<Note> New users appear under a System Admin's **Users** tab only after the new user has successfully logged in for the first time.</Note>

<Note> You can bypass the email verification process for new users through a Houston API mutation. For the format of this mutation, see [Sample Mutations](/docs/astro-private-cloud/v-1-x/houston-api).</Note>

### Enable public signups

Public signups allow any user with access to your base domain to create an account. If public signups are disabled, users that try to access Astronomer without an invitation from another user will be met with an error.

In cases where SMTP credentials are difficult to acquire, enabling this flag might facilitate initial setup, as disabling public signups requires that a user accept an email invitation. Public signups are a configuration available in Astronomer's Houston API and can be enabled in the `values.yaml` file of your Helm chart.

To enable public signups, add the following yaml snippet to your `values.yaml` file:

```yaml wrap theme={null}
astronomer:
  houston:
    config:
      publicSignups: true
      emailConfirmation: false # If you wish to also disable other SMTP-dependent features
```

An example `values.yaml` file would look like:

```yaml wrap theme={null}
global:
  baseDomain: mybasedomain
  tlsSecret: astronomer-tls
nginx:
  loadBalancerIP: 0.0.0.0
  preserveSourceIP: true

astronomer:
  houston:
    config:
      publicSignups: true
      emailConfirmation: false

```

Then, push the configuration change to your platform as described in [Apply a config change](/docs/astro-private-cloud/v-1-x/apply-platform-config).

## System permissions on Astro Private Cloud

The System Admin role grants full permissions across all clusters, Workspaces, and Deployment entities. Users with this role can monitor and take action on Workspaces, Deployments, and users throughout all clusters.

On Astro Private Cloud, System Admins specifically can:

* Register a data plane
* List all data planes
* Manage data plane -wide config
* De-register a data plane
* List and search all users.
* List and search all Deployments.
* Access the Airflow UI for all Deployments.
* Delete a user.
* Delete a Deployment.
* Access Grafana for cluster-level monitoring.
* Add other System Admins.

In addition to the commonly used System Admin role, the Astro Private Cloud platform also supports both a System Editor and System Viewer permission set.

No user is assigned the System Editor or Viewer Roles by default, but they can be added by System Admins via our API. Once assigned, System Viewers, for example, can access Grafana but don't have permission to delete a Workspace they're not a part of.

You can customize all three Astro Private Cloud permission sets to meet your specific requirements. For more information about the default configurations attached to the System Admin, Editor and Viewer Roles, see the [Houston API default config](https://github.com/astronomer/astronomer-docs-resources/blob/main/software/software_configs/0.35/default.yaml).

### Assign users System Admin roles

Use the **System Admin** tab in the Astro Private Cloud UI to add System Admins.

Keep in mind that:

* Only existing System Admins can grant the System Admin role to another user
* The user must have a verified email address and already exist in the system

<Note> If you'd like to assign a user a different System-Level Role (either `SYSTEM_VIEWER` or `SYSTEM_EDITOR`), you'll have to do so via an API call from your platform's GraphQL playground. For guidelines, refer to our ["Houston API" doc](/docs/astro-private-cloud/v-1-x/houston-api).</Note>

#### Verify System Admin access

To verify a user was successfully granted the System Admin role, ensure they can do the following:

* Navigate to `grafana.BASEDOMAIN`
* Access the 'System Admin' tab from the top left menu of the Astro Private Cloud UI

## User roles on Astro Private Cloud

Administrators can customize permissions across your installation. On Astro Private Cloud, users can be assigned roles at three levels:

* Deployment Level (Viewer, Editor, Admin)
* Workspace Level (Viewer, Editor, Admin)
* System Level (Viewer, Editor, Admin)
* Cluster Level (Admin)

Deployment roles apply to a Deployment within a single Workspace. Workspace roles apply to all Airflow Deployments within a single Workspace. Cluster Roles apply to *all* Workspaces across a single data plane. System Roles apply across all data planes. For more information about the three Workspace-level roles on Astro Private Cloud (Viewer, Editor and Admin), see [Manage user permissions on an Astro Private Cloud Workspace](/docs/astro-private-cloud/v-1-x/manage-permissions).

## Customize role permissions

Permissions are defined on Astro Private Cloud as `scope.entity.action`, where:

* `scope`: The layer of our application to which the permission applies
* `entity`: The object or role being operated on
* `action`: The verb describing the operation being performed on the `entity`

For example, the `deployment.serviceAccounts.create` permission translates to the ability for a user to create a Deployment-level service account in any Deployment to which they belong. To view the available platform permissions and default role configurations, see [Reference: System permissions](/docs/astro-private-cloud/v-1-x/role-permission-reference).

A permission for a given `scope` only applies to the parts of the scope where a user has been invited. For example, a user with a role including the `workspace.serviceAccounts.get` permission can view service accounts only in the Workspaces they belong to.

For a complete list of Astro Private Cloud roles and default permissions, see [User roles and permissions](/docs/astro-private-cloud/v-1-x/role-permission-reference).

### Role permission inheritance

In addition to their own permissions, roles inherit permissions from other roles.

There are several chains of inheritance in the Astro Private Cloud RBAC system. In the following list, `>` represents "inherits from":

* System Admin > System Editor > System Viewer > User
* Deployment Admin > Deployment Editor > Deployment Viewer > User
* Workspace Admin > Workspace Editor > Workspace Viewer > User

### Step 1: Identify a permission change

Review the default roles and permissions in the [default Houston API configuration](https://github.com/astronomer/astronomer-docs-resources/blob/main/software/software_configs/0.37/default.yaml) and determine the following:

* What role you want to configure. For example, `DEPLOYMENT_EDITOR`.
* What permission(s) you want to add or remove from the role, For example, `deployment.images.push`.

For example, you might want to block a `DEPLOYMENT_EDITOR` (and therefore `WORKSPACE_EDITOR`) from deploying code to all Airflow Deployments within a Workspace and instead limit that action to users assigned the `DEPLOYMENT_ADMIN` role.

### Step 2: Modify your `values.yaml` file

Apply the role and permission changes to your organization's `values.yaml` file. For example:

```yaml wrap theme={null}
astronomer:
  houston:
    config:
      roles:
        DEPLOYMENT_EDITOR:
          permissions:
            deployment.images.push: false
```

In the same way you can remove permissions from a particular role by setting a permission to `:false`, you can add permissions to a role at any time by setting a permission to `:true`.

For example, if you want to allow any `DEPLOYMENT_VIEWER` (and therefore `WORKSPACE_VIEWER`) to push code directly to any Airflow Deployment within a Workspace, you'd specify the following:

```yaml wrap theme={null}
astronomer:
  houston:
    config:
      roles:
        DEPLOYMENT_VIEWER:
          permissions:
            deployment.images.push: true
```

Push the configuration change to your platform. See [Apply a config change](/docs/astro-private-cloud/v-1-x/apply-platform-config).

### Example customization: Limit Workspace creation

Unless otherwise configured, a user who creates a Workspace on Astro Private Cloud is automatically granted the `WORKSPACE_ADMIN` role and can create an unlimited number of Airflow Deployments within that Workspace. For organizations looking to more strictly control resources, Astro Private Cloud supports limiting the Workspace creation function through the `USER` role.

Astro Private Cloud includes a `USER` role that is synthetically bound to *all* users within the Control plane. By default, this role includes the `system.workspace.create` permission.

If you're a System Admin who wants to limit Workspace creation, you can:

* Set the `system.workspace.create` permission for the `USER` role to `false`
* Attach the `system.workspace.create` permission to a separate role of your choice

You might want limit this permission to the `SYSTEM_ADMIN` role on the platform, because System Admins can be responsible for managing cluster-level resources and costs. To reassign this permission to System Admins, your `values.yaml` would appear similar to the following example:

```yaml wrap theme={null}
astronomer:
  houston:
    config:
      roles:
        SYSTEM_ADMIN:
          permissions:
            system.workspace.create: true
        USER:
          permissions:
            system.workspace.create: false
```