RBAC Docs fixup

This commit is contained in:
leflambeur
2025-03-10 21:06:49 +00:00
parent 5875cc77aa
commit 08c10576e5
9 changed files with 133 additions and 163 deletions
@@ -0,0 +1,34 @@
---
title: Cloud RBAC
weight: 26
partition: cloud
---
# Cloud RBAC - Early Access
## About Cloud RBAC
Qdrant Cloud enables you to manage permissions for your cloud resources with greater precision within the Qdrant Cloud console. This feature ensures that only authorized users have access to sensitive data and capabilities, covering the following areas:
- Billing
- Identity and Access Management
- Clusters*
- Hybrid Cloud
- Account Configuration
*Note: Current permissions control access to ALL clusters. Per Cluster permissions will be in a future release.
### How can I participate in the Early Access program for Cloud RBAC?
Customers who are interested should [register your interest](https://share-eu1.hsforms.com/1H5vI2Xx6TbCjwfyARUwQaA2b46ng).
Check out our [Early Access FAQ](/documentation/cloud-rbac/early-access-faq/) for more information.
## Guides
- [Role Management](/documentation/cloud-rbac/role-management/)
- [User Management](/documentation/cloud-rbac/user-management/)
## Reference
- [Permission List](/documentation/cloud-rbac/permission-list/)
@@ -0,0 +1,65 @@
---
title: Early Access FAQ
weight: 4
---
# Early Access FAQ
## 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 Database API Keys deliver programmatic credentials with access control at a cluster level, including per-collection permissions.
## 2. Will my existing operations be disrupted?
We are committed to minimizing disruption during the rollout process.
## 3. Will this change how I interact with my cloud resources?
Initially, you may need to adjust your workflows in the cloud console if you restrict permissions for users. However, our phased rollout approach is 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 cluster.
## 4. I am currently an admin in another account, will I lose access once this is enabled?
No, for existing users already invited to another 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 assigned the base role meaning they will not automatically become admins like today.
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.
## 5. I have SSO, will I be able to use Cloud RBAC?
Cloud RBAC treats all users the same, regardless of authentication method.
## 6. How can I participate in the Early Access program for Cloud RBAC?
Customers who are interested should [register your interest](https://share-eu1.hsforms.com/1H5vI2Xx6TbCjwfyARUwQaA2b46ng).
## 7. I use Hybrid Cloud, how will this feature affect me?
Cloud RBAC is focused on the Cloud Interface itself, this means for Hybrid Cloud, Cloud RBAC will only affect those users you wish to administrate your clusters and account in the Cloud UI.
Additionally, Database API Keys are already available in Hybrid Clusters by accessing the Database UI directly through your ingress.
## 8. Will this allow me to segregate my dev and admin user access?
Cloud RBAC currently covers permissions within the cloud console only. The ability to control access to individual clusters and collections is not yet available, but is 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.
In the future, we plan to add the ability to restrict specific cloud identities per resource (cluster or collection) for Managed Cloud as well.
For Hybrid Clusters, where the Cluster Dashboard UI access is not routed through Qdrant Cloud, it is possible to leverage the built-in API Key RBAC to restrict access when accessing the Cluster UI directly.
For the administration of clusters and cloud resources with Hybrid you would then 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.
## 9. Does enabling Cloud RBAC incur any extra cost?
No, this feature will eventually be enabled for all users in Qdrant Cloud, and we are reaching out to existing customers to gather feedback.
## 10. 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.
@@ -1,16 +1,16 @@
---
title: Permissions Reference
title: Permission Reference
weight: 3
---
# **Permissions Reference**
# **Permission Reference**
This document outlines the different permissions available in the system, categorized for clarity.
This document outlines the different permissions available in Qdrant Cloud.
---
## **Identity and Access Management**
Controls permissions related to user roles, access management, and invitations.
## **Identity and Access Management**
Permissions related to user roles, access management, and invitations.
| Permission | Description |
|------------|------------|
@@ -28,8 +28,8 @@ Controls permissions related to user roles, access management, and invitations.
---
## **Cluster**
Manages permissions for clusters, backups, API keys, and schedules.
## **Cluster**
Permissions for clusters, backups, API keys, and schedules.
### **API Keys**
| Permission | Description |
@@ -61,8 +61,8 @@ Manages permissions for clusters, backups, API keys, and schedules.
---
## **Hybrid Cloud**
Manages permissions for hybrid cloud infrastructure.
## **Hybrid Cloud**
Permissions for hybrid cloud environments.
| Permission | Description |
|------------|------------|
@@ -72,8 +72,8 @@ Manages permissions for hybrid cloud infrastructure.
---
## **Payment & Billing**
Handles permissions related to payment methods and billing information.
## **Payment & Billing**
Permissions for payment methods and billing information.
| Permission | Description |
|------------|------------|
@@ -82,8 +82,8 @@ Handles permissions related to payment methods and billing information.
---
## **Account Management**
Controls permissions for managing user accounts.
## **Account Management**
Permissions for managing user accounts.
| Permission | Description |
|------------|------------|
@@ -93,11 +93,11 @@ Controls permissions for managing user accounts.
---
## **Profile**
Handles permissions for accessing and managing user profile information.
## **Profile**
Permissions for accessing personal profile information.
| Permission | Description |
|------------|------------|
| `read:profile` | View the user’s own profile information.<br> **(Assigned to all users by default)** |
---
---
@@ -5,17 +5,17 @@ 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.
A **Role** contains 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.
Qdrant Cloud includes some built-in roles for common use-cases. 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
- The **Base Role** is assigned to all users, and provides the minimum privileges required to access Qdrant Cloud.
- The **Admin Role**  has all available permissions, except for account write permissions.
- The **Owner Role** has all available permissions assigned, including account write permissions. There can only be one Owner per account currently.
![image.png](/documentation/cloud/role-based-access-control/built-in-roles.png)
@@ -8,27 +8,27 @@ weight: 2
## 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.
Users can be invited via the **User Management** section, where they are assigned the **Base role** by default. 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**
### 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.
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.
Once accepted, they'll be assigned that role's permissions, along with the base role.
![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.
Before being accepted, an Admin/Owner can cancel a pending invite directly on either the **User Management** or **Role Details** page.
![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**.
Authorized users can give or take away roles from users in **User Management**.
![image.png](/documentation/cloud/role-based-access-control/update-user-role.png)
@@ -44,15 +44,6 @@ 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.
@@ -1,11 +1,11 @@
---
title: Qdrant Cloud API
weight: 26
partition: cloud
weight: 27
partition: cloud
---
# Qdrant Cloud API
# Qdrant Cloud API
The Qdrant Cloud API lets you manage Cloud accounts and their respective Qdrant clusters. You can use this API to manage your clusters, authentication methods, and cloud configurations.
The Qdrant Cloud API lets you manage Cloud accounts and their respective Qdrant clusters. You can use this API to manage your clusters, authentication methods, and cloud configurations.
| REST API | Documentation |
| -------- | ------------------------------------------------------------------------------------ |
@@ -34,14 +34,14 @@ curl -X 'GET' \
This request will return a list of clusters associated with your account in JSON format.
## Cluster Management
Use these endpoints to create and manage your Qdrant database clusters. The API supports fine-grained control over cluster resources (CPU, RAM, disk), node configurations, tolerations, and other operational characteristics across all cloud providers (AWS, GCP, Azure) and their respective regions in Qdrant Cloud, as well as Hybrid Cloud.
## Cluster Management
Use these endpoints to create and manage your Qdrant database clusters. The API supports fine-grained control over cluster resources (CPU, RAM, disk), node configurations, tolerations, and other operational characteristics across all cloud providers (AWS, GCP, Azure) and their respective regions in Qdrant Cloud, as well as Hybrid Cloud.
- **Get Cluster by ID**: Retrieve detailed information about a specific cluster using the cluster ID and associated account ID.
- **Delete Cluster**: Remove a cluster, with optional deletion of backups.
- **Update Cluster**: Apply modifications to a cluster's configuration.
- **List Clusters**: Get all clusters associated with a specific account, filtered by region or other criteria.
- **Create Cluster**: Add new clusters to the account with configurable parameters such as nodes, cloud provider, and regions.
- **Get Booking**: Manage hosting across various cloud providers (AWS, GCP, Azure) and their respective regions.
- **Get Booking**: Manage hosting across various cloud providers (AWS, GCP, Azure) and their respective regions.
## Cluster Authentication Management
Use these endpoints to manage your cluster API keys.
@@ -1,27 +0,0 @@
---
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.
@@ -1,93 +0,0 @@
---
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.