Add RBAC documentation

qdrant-landing/content/documentation/cloud-tab.md

@@ -44,6 +44,15 @@ content:
       link:
         url: /documentation/private-cloud/
         text: Read More
+    - id: 4
+      image:
+        src: /img/dev-portal-cloud/private-cloud.png
+        alt: Role based Access Control
+      title: Role based Access Control
+      description: Qdrant Cloud enables you to manage permissions for your cloud resources with greater precision.
+      link:
+        url: /documentation/role-based-access-control/
+        text: Read More
   - partial: documentation/sections/cards-section
     title: Customer Support
     description: Stream, index, and migrate data to Qdrant with these essential tools and strategies.

qdrant-landing/content/documentation/role-based-access-control/_index.md

@@ -0,0 +1,39 @@
+---
+title: Role Based Access Control
+weight: 15
+partition: cloud
+---
+
+# Introducing Cloud RBAC: Secure Access to Qdrant Cloud
+
+# Summary
+
+Qdrant Cloud is introducing a new feature called Cloud RBAC (Role-Based Access Control), which enables you to manage permissions for your cloud resources with greater precision. This feature is designed to work seamlessly within the Qdrant Cloud console, ensuring that only authorized users have access to sensitive data and capabilities.
+
+## **What does Cloud RBAC mean for me?**
+
+Cloud RBAC ensures that every aspect of our platform is secure and governed by strict access controls. We are introducing this capability via a feature flag, allowing us to selectively enable Cloud RBAC for specific customers and sections of the cloud console before it becomes generally available. 
+
+## What permissions can I expect?
+
+ Cloud RBAC will be a rollout of RBAC capabilities for:
+
+- Billing
+- Identity and Access Management
+- Clusters
+- Hybrid Cloud
+- Account Configuration
+
+Cloud RBAC will also introduce an improved and overhauled UI for the existing Invites and User Management capabilities of Qdrant Cloud.
+
+To learn more detailed information about the available permissions see the attached documentation.
+
+## **The Roadmap Ahead**
+
+Our larger plan involves delivering three key features in a controlled and phased manner:
+
+1. **Cloud RBAC:** Cloud User Permissions (this feature)
+2. **Database API Keys w/ JWT RBAC:** A separate feature that enhances the built-in database api keys, including per-collection controls, with the ability to create client credentials for programmatic access to a cluster.
+3. **Automatic Dashboard Auth**: The integration of Cloud RBAC and Database API Keys to allow admins to configure per-cluster permissions for a Cloud User Identity, as well as enable automatic authentication to the Database GUI based on that user’s permissions (this feature is planned later)
+
+Once all three features are delivered, you will enjoy seamless integration between them, ensuring secure automated access across Qdrant Cloud.

qdrant-landing/content/documentation/role-based-access-control/faq.md

@@ -0,0 +1,93 @@
+---
+title: Frequently asked questions
+weight: 4
+---
+
+
+# Frequently Asked Questions
+
+## 1. What is the difference between Cloud RBAC and Database API Keys?
+
+Cloud RBAC covers permissions within the Qdrant Cloud console such as Billing and Backups, while the upcoming Database Access Tokens will deliver programmatic credentials with access control at a database level, including per-collection permissions.
+
+## 2. How does Automatic Dashboard Auth differ to Cloud RBAC and Database API Keys?
+
+Currently in Qdrant Cloud if you access the Dashboard UI of your cluster you need to copy an API Key in. With Database API Keys we can now restrict that access to specific collections, with Cloud RBAC we can begin to assign permissions to users. Automatic Dashboard Auth will be built on top of both features to bridge the gap between RBAC in the Cloud UI and Dashboard UI so that when you access the dashboard your Cloud RBAC permissions will be used to generate an ephemeral session key that is automatically applied to you dashboard.
+
+## 3. Will my existing operations be disrupted?
+
+We are committed to minimizing disruption during the rollout process and are carefully selecting customers for participation in our Early Access program before it becomes GA.
+
+## 4. When can I expect the full suite of features?
+
+Once Cloud RBAC, Database API Keys, and Automatic Dashboard Auth are delivered, you will enjoy seamless integration between these features, ensuring secure access across all aspects of Qdrant Cloud.
+
+Cloud RBAC is rolling out in the next few weeks, and Database API Keys w/ JWT RBAC is already available. Automatic Dashboard Auth is in the design stage with plans to roll this out in H1 2025.
+
+## 5. Will this change how I interact with my cloud resources?
+
+Initially, you may need to adjust your workflows in the cloud console to accommodate the new permissions introduced by Cloud RBAC if you restrict permissions for users. However, our phased rollout approach and feature flag delivery are designed to minimize disruption.
+
+Existing Database API Keys for direct cluster access will not be affected, as Cloud RBAC only affects the capabilities and resources of the cloud console itself not the databases.
+
+## 6. I am currently an admin in someone-else’s account, will I lose access once this is enabled?
+
+No, for existing users already invited to someone-else's account we will not be changing any permissions as you have already been granted Admin privileges.  It will be up to the account owner and users who also have permission to configure RBAC to apply new permissions.
+
+Moving forward, any new users invited to an account will be given minimal permissions meaning they will not automatically become admins like today and will need to be assigned roles.
+
+Admins will be also be able to assign pre-configured roles to a user when inviting them as part of the overhauled Invitations and User Management UI.
+
+## 7. Is Qdrant Cloud also planning to deliver SSO?
+
+Single Sign On (SSO) capabilities supporting both Okta and Entra ID (formally Azure AD) became  available in Qdrant Cloud earlier this year and is already in use by customers in production.
+
+SSO is only available to our Premium customers and requires configuration in the Qdrant Cloud backend to enable it per account, meaning it cannot be enabled self-service currently.
+
+For SSO enabled users, it is still necessary to invite other SSO enabled users to your account like any other user, all that changes is the ability to authenticate to Qdrant Cloud with your own directory services.
+
+Cloud RBAC treats all users the same so is agnostic to Social/SSO logins and will apply to SSO users like any other user.
+
+## 8. How can I participate in the Early Access program for Cloud RBAC?
+
+We are inviting customers who are willing to test the new capability while it's experimental to provide regular feedback during the initial rollout of Cloud RBAC. 
+
+## 9. I use hybrid cloud, how will this feature affect me?
+
+Cloud RBAC is focused on the Cloud Interface itself, this means for Hybrid Clusters, Cloud RBAC will only affect those users you wish to administrate your clusters and account in the Cloud UI.
+
+Additionally for the Database API Keys feature mentioned in the Roadmap section. this is the Managed Cloud implementation, this feature is actually already available in Hybrid Clusters by accessing the Database UI directly through your ingress.
+
+For the Automatic Dashboard Auth feature described above, this will be available to Managed Cloud users, where we own the end to end infrastructure and have control over where we redirect people to; in future we may consider ways to deliver this functionality to Hybrid Clusters but this is not scheduled yet.
+
+## 10. What permissions will new users be granted when I invite them to my account moving forward?
+
+By default all users are granted a permission to see only their own user profile and nothing else.
+
+## 11. Will this allow me to segregate my dev and admin user access?
+
+Cloud RBAC on it’s own is only for permissions within the cloud console, the ability to control access to individual clusters and collections is not yet available and planned for the Automatic Dashboard Auth on our roadmap.
+
+Today, it is possible to provide dev users with only Database API keys, which will let them authenticate into clusters programmatically. However, for UI access to Managed Cloud Clusters, they will still need access via the Cloud Console.
+
+Once Automatic Dashboard Auth is delivered the ability to restrict specific cloud identities per resource (cluster or collection) will be made available for control via the UI.
+
+For Hybrid Clusters, where the Database Dashboard UI access is not routed through Qdrant Cloud, it is possible to leverage the built-in database tokens and RBAC to provide users with the correct permissions to restrict access and achieve full segregation when accessing the database UI but this requires managing credentials rather than users and assigning them manually.
+
+For the administration of clusters and cloud resources with Hybrid you would only permit trusted admin users into your cloud admin console, and the Cloud RBAC feature will let you control the permissions at this level for those users.
+
+## 12. How will I know I have the new Cloud RBAC enabled?
+
+By navigating to ‘Access Management’ you will see an interface for creating roles, managing roles and users, this is not available to users without the feature flag.
+
+You may need to create a new browser session, or re-authenticate to see the changes once enabled.
+
+## 13. Does enabling Cloud RBAC incur any extra cost?
+
+No, this feature will eventually be enabled for all users in Qdrant Cloud, for now we are only reaching out to existing customers who we believe would benefit from this capability to gather feedback and assess usability for an initial rollout.
+
+## 14. I use Cloud Admin Keys, will Cloud RBAC apply to these as well?
+
+Cloud RBAC was designed to work with both permissions in the UI for Cloud Users to restrict functionality, and also in the backend to work with Admin Keys and programmatic access to the cloud console.
+
+Configuring permissions for Cloud Management Keys will not available immediately, but is on the roadmap for later.

qdrant-landing/content/documentation/role-based-access-control/perrmissions-list.md

@@ -0,0 +1,103 @@
+---
+title: Permissions Reference
+weight: 3
+---
+
+# **Permissions Reference**
+
+This document outlines the different permissions available in the system, categorized for clarity.
+
+---
+
+## **Identity and Access Management**  
+Controls permissions related to user roles, access management, and invitations.  
+
+| Permission | Description |
+|------------|------------|
+| `read:roles` | View roles in the Access Management page. |
+| `write:roles` | Create and modify roles in the Access Management page. |
+| `delete:roles` | Remove roles in the Access Management page. |
+| `read:management_keys` | View Cloud Management Keys in the Access Management page. |
+| `write:management_keys` | Create and manage Cloud Management Keys. |
+| `delete:management_keys` | Remove Cloud Management Keys in the Access Management page. |
+| `write:invites` | Invite new users to an account and revoke invitations. |
+| `read:invites` | View pending invites in an account. |
+| `delete:invites` | Remove an invitation. |
+| `read:users` | View user details in the profile page. <br> - Also applicable in User Management and Role details (User tab). |
+| `delete:users` | Remove users from an account. <br> - Applicable in User Management and Role details (User tab). |
+
+---
+
+## **Cluster**  
+Manages permissions for clusters, backups, API keys, and schedules.
+
+### **API Keys**
+| Permission | Description |
+|------------|------------|
+| `read:api_keys` | View Database API Keys for managed clusters. |
+| `write:api_keys` | Create new Database API Keys. |
+| `delete:api_keys` | Remove Database API Keys. |
+
+### **Backups**
+| Permission | Description |
+|------------|------------|
+| `read:backups` | View backups in the **Backups page** and **Cluster details > Backups tab**. |
+| `write:backups` | Create backups from the **Backups page** and **Cluster details > Backups tab**. |
+| `delete:backups` | Remove backups from the **Backups page** and **Cluster details > Backups tab**. |
+
+### **Cluster**
+| Permission | Description |
+|------------|------------|
+| `read:clusters` | View cluster details. |
+| `write:clusters` | Modify cluster settings in the Cluster details page. |
+| `delete:clusters` | Delete a cluster from the **Danger Zone** in the Clusters page. |
+
+### **Backup Schedules**
+| Permission | Description |
+|------------|------------|
+| `read:backup_schedules` | View backup schedules in the **Backups page** and **Cluster details > Backups tab**. |
+| `write:backup_schedules` | Create backup schedules from the **Backups page** and **Cluster details > Backups tab**. |
+| `delete:backup_schedules` | Remove backup schedules from the **Backups page** and **Cluster details > Backups tab**. |
+
+---
+
+## **Hybrid Cloud**  
+Manages permissions for hybrid cloud infrastructure.
+
+| Permission | Description |
+|------------|------------|
+| `read:hybrid_cloud_environments` | View hybrid cloud details. |
+| `write:hybrid_cloud_environments` | Modify hybrid cloud settings. |
+| `delete:hybrid_cloud_environments` | Remove a hybrid cloud cluster. |
+
+---
+
+## **Payment & Billing**  
+Handles permissions related to payment methods and billing information.
+
+| Permission | Description |
+|------------|------------|
+| `read:payment_information` | View payment methods and billing details. |
+| `write:payment_information` | Modify or remove payment methods and billing details. |
+
+---
+
+## **Account Management**  
+Controls permissions for managing user accounts.
+
+| Permission | Description |
+|------------|------------|
+| `read:account` | View account details that the user is a part of. |
+| `write:account` | Modify account details such as:<br> - Editing the account name<br> - Setting an account as default<br> - Leaving an account<br> **(Only available to Owners)** |
+| `delete:account` | Remove an account from:<br> - The **Profile page** (list of user accounts).<br> - The **active account** (if the user is an owner/admin). |
+
+---
+
+## **Profile**  
+Handles permissions for accessing and managing user profile information.
+
+| Permission | Description |
+|------------|------------|
+| `read:profile` | View the user’s own profile information.<br> **(Assigned to all users by default)** |
+
+---

qdrant-landing/content/documentation/role-based-access-control/role-management.md

@@ -0,0 +1,55 @@
+---
+title: Role Management
+weight: 1
+---
+
+# Role Management
+
+A **Role** comprises a set of **permissions** that define the ability to perform or control specific actions within the platform. Permissions are accessible through the Permissions tab in the Role Details page and offer fine-grained access control, logically grouped for easy identification. 
+
+## Built-In Roles
+
+The system includes some built-in roles that have default sets of permissions assigned to them, covering common use-cases and the permissions for these built-in roles cannot be changed.
+
+There are three types: 
+
+- **Base Role** which provide the minimum necessary privileges for typical tasks
+- The **Admin Role** that has all available permissions except the account related permissions
+- The **Owner Role** that has all available permissions assigned
+
+![image.png](/documentation/cloud/role-based-access-control/built-in-roles.png)
+
+## Custom Roles
+
+An **Admin/Owner** or another authorised user can create their own custom roles with specific sets of permissions, giving them more control over who has what access to which resource.
+
+![image.png](/documentation/cloud/role-based-access-control/custom-roles.png)
+
+### Creating a Custom Role
+
+To create a new custom role, click on the **Add** button at the top-right corner of the **Custom Roles** list.
+
+- **Role Name**: Must be unique across roles.
+- **Role Description**: Brief description of the role’s purpose.
+
+Once created, the new role will appear under the **Custom Roles** section in the navigation.
+
+![image.png](/documentation/cloud/role-based-access-control/create-custom-role.png)
+
+![image.png](/documentation/cloud/role-based-access-control/create-new-role.png)
+
+### Editing a Custom Role
+
+To update a specific role's permissions, select it from the list and click on the **Permissions** tab. Here, you'll find logically grouped options that are easy to identify and edit as needed. Once you've made your changes, save them to apply the updated permissions to the role.
+
+![image.png](/documentation/cloud/role-based-access-control/update-permission.png)
+
+### Renaming, Deleting and Duplicating a Custom Role
+
+Each custom role can be renamed, duplicated or deleted via the action buttons located to the right of the role title bar.
+
+- **Rename**: Opens a dialog allowing users to update both the role name and description.
+- **Delete**: Triggers a confirmation prompt to confirm the deletion. Once confirmed, this action is irreversible. Any users assigned to the deleted role will automatically be unassigned from it.
+- **Duplicate:** Opens a dialog asking for a confirmation and also allowing users to view the list of permissions that will be assigned to the duplicated role
+
+![image.png](/documentation/cloud/role-based-access-control/role-actions.png)

qdrant-landing/content/documentation/role-based-access-control/user-management.md

@@ -0,0 +1,41 @@
+---
+title: User Management
+weight: 2
+---
+
+
+# User Management
+
+## Inviting Users to an Account
+
+Users can be invited through the **User Management** section, where they are assigned the **Base role** by default upon acceptance. Additionally, users have the option to select a specific role when inviting another user. The **Base role** is a predefined role with minimal permissions, granting users access to the platform while restricting them to viewing only their own profile.
+
+![image.png](/documentation/cloud/role-based-access-control/user-invitation.png)
+
+### **Inviting Users from a Role**
+
+Users can be invited attached to a specific role by inviting them through the **Role Details** page - just click on the Users tab and follow the prompts. 
+
+Once accepted, they'll gain access with that role's permissions, along with any base role they may already have.
+
+![image.png](/documentation/cloud/role-based-access-control/invite-user.png)
+
+### Revoking an Invitation
+
+Before being accepted, an account Admin/Owner can cancel a pending invite directly on either the **User Management** or **Role Details** page to which the user was invited.
+
+![image.png](/documentation/cloud/role-based-access-control/revoke-invite.png)
+
+## Updating a User’s Roles
+
+Account admins/owners with permission can give or take away roles from users in **User Management**.
+
+![image.png](/documentation/cloud/role-based-access-control/update-user-role.png)
+
+![image.png](/documentation/cloud/role-based-access-control/update-user-role-edit-dialog.png)
+
+## Removing a User from an Account
+
+Users can be removed from an account by clicking on their name in either **User Management** (via Actions). This option is only available after they've accepted the invitation to join, ensuring that only active users can be removed.
+
+![image.png](/documentation/cloud/role-based-access-control/remove-user.png)