Skip to content
This repository has been archived by the owner on Jan 29, 2024. It is now read-only.

Commit

Permalink
Merge pull request #2148 from aiven/staceys-super-admin-doc-472
Browse files Browse the repository at this point in the history
Add documentation for super admin
  • Loading branch information
staceysalamon-aiven authored Nov 22, 2023
2 parents b4b775a + 849841f commit 702f52a
Show file tree
Hide file tree
Showing 3 changed files with 33 additions and 19 deletions.
1 change: 1 addition & 0 deletions _toc.yml
Original file line number Diff line number Diff line change
Expand Up @@ -69,6 +69,7 @@ entries:
entries:
- file: docs/platform/howto/manage-org-users
- file: docs/platform/howto/delete-user
- file: docs/platform/howto/make-super-admin
- file: docs/platform/howto/list-user-profile
entries:
- file: docs/platform/howto/edit-user-profile
Expand Down
34 changes: 15 additions & 19 deletions docs/platform/concepts/projects_accounts_access.rst
Original file line number Diff line number Diff line change
Expand Up @@ -11,32 +11,38 @@ Organizations and organizational units

Organizations and organizational units are collections of projects. When you sign up to Aiven, an organization is created for you.

You can use these to create a hierarchical structure that fits your needs. Organizational units can be nested within an organization, adding another level to group your projects. This gives you greater flexibility to organize your setup to meet your specific use cases. For example, you can easily split production and testing workloads into different organizational units that are in the same organization.
You can use your organization to create a hierarchical structure that fits your needs. Organizational units can be nested within an organization, adding another level to group your projects. This gives you greater flexibility to organize your infrastructure based on your specific use cases. For example, you can easily split production and testing workloads into different organizational units.

Grouping your projects in organizations and organizational units lets you centrally manage settings like:

* Authentication methods - Only available on the organization level
* Authentication methods: Only available on the organization level

* ACLs - Can be set on all levels (organization, organizational unit, and project)
* Access control lists (ACLs): Can be set on all levels (organization, organizational unit, and project)

* ACLs for service plans are inherited, meaning all projects within an organization or organizational unit will have the same service plan.

* Groups - User groups managed at the organization level and assigned to projects
* Groups: Managed at the organization level and assigned to projects

* Teams - Specific to a single organization or organizational unit and cannot be shared between them
* Support contracts: Specific to a single organization and cannot be shared between them

* Support contracts - Specific to a single organization or organizational unit and cannot be shared between them
* Billing groups: Specific to a single organization and cannot be shared between them

Super admin
~~~~~~~~~~~~

Super admin have full access to the organization, including all organizational units, projects, and services. Users are automatically made super admin when they create an organization, and they can :doc:`make other users super admin </docs/platform/howto/make-super-admin>`.

Super admin are the same as account owners. Adding a user to the account owners team makes them a super admin. Likewise, when you make a user a super admin, they are added to the account owners team.

* Billing groups - Specific to a single organization or organizational unit and cannot be shared between them

Projects
--------

Projects are collections of services and user permissions. Each project must have a unique name within an organization. You can group your services however you see fit. These are some examples of how customers organize their services:
Projects are collections of services and user permissions. Each project must have a unique name. You can group your services however you see fit. These are some examples of how customers organize their services:

* Single project: One project containing services that are distinguished by their names. For example, services are named based on the type of environment: ``demo_pg_project.postgres-prod`` and ``demo_pg_project.postgres-staging``.

* Environment-based projects: Each project represents a deployment environment, for example: ``dev``, ``qa``, and ``production``. This allows you to apply uniform network security, such as the use of virtual private clouds, to all services within each environment. This also gives you more granular user permissions, such as developer access to production infrastructure.
* Environment-based: Each project represents a deployment environment, for example: ``dev``, ``qa``, and ``production``. This allows you to apply uniform network security, such as the use of virtual private clouds, to all services within each environment. This also gives you more granular user permissions, such as developer access to production infrastructure.

* Project-based: Each project contains all the services for an internal project, with naming that highlights the relevant environment; for example: ``customer-success-prod`` and ``business-analytics-test``.

Expand All @@ -52,16 +58,6 @@ Groups

:doc:`Organization users </docs/platform/howto/manage-org-users>` can be :doc:`added to groups </docs/platform/howto/manage-groups>`, making it easy to control access to the services in a project. When you :doc:`add a group to a project </docs/platform/howto/add-groups-projects>`, you also select the role for that group. This role gives all users in that group the same level of access to all services in the project.

Teams
~~~~~

.. important::
**Teams are becoming groups**

:doc:`Groups </docs/platform/howto/manage-groups>` are an easier way to control access to your organization's projects and services for a group of users.

You can also use teams within organizations or organizational units to control access to projects for a group of users. When you create a team, you choose which projects to add it to. Another option is to set up :doc:`SAML single sign-on (SSO) </docs/platform/howto/list-saml>` for an organization that automatically adds users to a team when they sign up. For greater security, you may want to use a combination of SAML and RBAC regardless of the size of team.

Best practices for organizations
---------------------------------

Expand Down
17 changes: 17 additions & 0 deletions docs/platform/howto/make-super-admin.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
Make users super admin
=======================

Super admin have full access to an organization and its settings as well as all of its organizational units, projects, and services.

Make a user a super admin
--------------------------

To give a user full access to your organization:

#. In the organization, click **Admin**.

#. Click **Users**.

#. Find the user and click **Actions** > **Make super admin**.

To revoke super admin privileges for a user, follow the same steps and select **Revoke super admin**.

0 comments on commit 702f52a

Please sign in to comment.