Qdrant access control and SSO guide

Who can reach your Qdrant data, and how to control it before go-live

Access control for self-hosted Qdrant has to be designed before any application connects to it. The Qdrant security docs state that by default all self-deployed instances listen on all network interfaces and have no authentication configured, so a test install that a developer points at a notebook can become a production dependency without anyone deciding who may read or write vectors. This topic covers four decisions: which admin and read-only API keys exist, how JWT tokens carry per-collection read or write permissions, which authenticated operations are written to the JSON audit log, and where single sign-on applies. The open-source engine is licensed under Apache-2.0 and is free to self-host, so the access layer, including its token issuance and key handling, is your team's own work.

Enabling one setting is not the hard part. The difficulty is that a single Qdrant cluster often serves several consumers: ingestion pipelines that write embeddings, search services that read them, analysts running ad hoc queries, and administrators who manage collections and snapshots. Some collections hold data that different tenants or business units should not see, and service accounts outlive the people who created them. Token lifetimes decide how long a leaked credential stays useful, and auditors will ask who could read which collection on which date. Before go-live, list every consumer, map each one to a role and a set of collections, and decide how each credential is rotated and revoked.

Feature availability depends on the release you run. Qdrant documents admin and read-only API keys and TLS for REST and gRPC from v1.2.0, JWT-based granular access control with per-collection read or write permissions from v1.9.0, and JSON audit logging of authenticated API operations from v1.17.0. The latest release on the Qdrant GitHub releases page is v1.19.2, published October 5, 2026, so confirm the exact version in your environment and read the security documentation for that version before you design around any of these controls. Check the version in every environment, including staging, because a control that exists in production but not in the test cluster will not be tested.

Where SSO applies depends on how you deploy. The Qdrant pricing page lists SSO as a feature of the Premium tier in Qdrant Cloud, which has a minimum spend, and it lists Hybrid Cloud and Private Cloud as priced through Qdrant sales. Ask Qdrant in writing which identity features apply to your deployment model, whether SSO covers the Qdrant console, the API or both, and how user roles map to the key and JWT model. For a self-hosted cluster, your identity provider's role in practice is to issue the JWT tokens that Qdrant validates, so the design question is how your identity layer maps users and services to collection permissions and how quickly those permissions expire.

Which Qdrant access controls exist and what each one is for

Qdrant offers several access mechanisms that work at different layers: who holds a key, what a token may do on a given collection, how traffic is protected in transit, and how calls are attributed afterward. Read each card as one layer, then decide which combination fits your team, your callers and your identity provider.

Admin API key

The admin API key grants full control over the instance, including creating, changing and deleting collections and reading all data. It is the first control to enable on a self-hosted deployment, because by default Qdrant listens on all network interfaces with no authentication configured. It does not limit which collections a caller can reach, and it does not identify individual users. Confirm with your platform team who stores the key, how it is rotated, and which services hold it.

Read-only API key

The read-only API key lets a client run searches and read data but not change collections or points. It suits application services and analytics jobs that only query the index. It does not restrict access by collection, so any holder can read everything on the instance. Ask the application owner which workloads only query, and confirm that the key is delivered to them separately from the admin key.

JWT granular access control

JSON Web Token based access control, available since v1.9.0, lets an identity layer issue tokens that grant read or write permission per collection. It is the control that separates tenants, teams or environments sharing one cluster. It does not authenticate people by itself, so you still need a process that issues tokens only after a user is verified. Ask your identity owner which claims the tokens carry and who signs them.

JSON audit logging

Audit logging, available since v1.17.0, records authenticated API operations in JSON, so each write or query can be tied to the credential that made it. Its purpose here is attribution: answering which caller changed a collection and when. It does not prevent misuse, and it does not replace network or key controls. Confirm where the logs are shipped, who can read them, and how long they are retained under your own policy.

TLS for REST and gRPC

TLS, supported for REST and gRPC since v1.2.0, encrypts traffic between clients and Qdrant so API keys and JWT tokens are not sent in clear text. It protects the transport only and does not decide who may call the API. Certificate issuance, renewal and trust distribution to clients are your responsibility. Ask your network or platform team who owns the certificate authority and how certificates are rotated.

Qdrant Cloud SSO

Single sign-on is listed in Qdrant's pricing page as part of the Premium tier, which has a minimum spend. It governs how staff sign in to the managed Qdrant Cloud console, not how applications call a self-hosted cluster. Its scope applies only where you use Qdrant Cloud. Confirm the tier, the minimum spend and the identity provider supported with Qdrant sales before you assume SSO for self-hosted access.

Which access model fits your Qdrant deployment

This table compares four ways to control access to Qdrant: shared API keys, admin and read-only keys behind a gateway, JWT tokens from your identity layer, and SSO in Qdrant Cloud Premium. Read each row across the fit conditions, audit attribution and the operational work each model creates, since much of the cost sits in components you build and run. Match your number of consuming applications, scoping needs and hosting model to the trade-offs, then confirm open items with Qdrant before you commit.

Access model	When it fits	Audit attribution	Operational cost it creates
Shared API keys only	One or a few consuming applications, no need for per-team collection scoping, and a team that accepts shared credentials.	Operations are tied to the key, so logs show which key was used, not which person or service made the call.	Key rotation touches every consumer at once. Keys are hard to contain if leaked, and there are no per-collection limits.
Admin and read-only keys behind an application gateway	Several applications that need only two access levels, with a gateway that holds the keys and checks caller identity.	Caller attribution depends on the gateway's own logs, so confirm what it records and how long it keeps them.	You build and run the gateway, handle its upgrades, and rotate the keys it holds.
JWT tokens from your identity layer with per-collection permissions	Several teams or applications that need collection-level scoping and already run an identity provider you control.	Token claims can link operations to a caller. Confirm which claims appear in the audit logs of your Qdrant version.	You build and run a token issuance service, manage signing key custody and rotation, and design the permission claims.
SSO in Qdrant Cloud Premium	Managed Qdrant Cloud deployments where the vendor's SSO meets your requirements and the Premium tier fits your spend.	Depends on what the vendor's SSO and audit features expose. Confirm the details with Qdrant.	Premium tier with a minimum spend, plus dependence on the vendor's SSO implementation. Does not apply to self-hosted Qdrant.

How JWT tokens from your identity layer map to collection permissions

The core decision in this section is who issues the permissions and who enforces them. In a JWT-based setup, your identity layer authenticates the user or service, decides what that caller may do, and mints a signed token that carries those grants. The self-hosted Qdrant instance does not talk to your identity provider during each request. Instead, it holds the material it needs to verify the signature of incoming tokens and then checks each request against the permissions the token carries. Read this as a split of responsibilities: your team controls who receives which grants, and Qdrant controls whether a request matches those grants.

Your team owns four things. First, the token issuer itself, whether that is an existing identity provider, an internal token service or a gateway that exchanges a login for a Qdrant-scoped token. Second, the signing key lifecycle: where the key lives, who can read it, how it is rotated, and how Qdrant is updated when the verification material changes. Third, the mapping from groups or roles in your directory to collections and to read or write rights on each collection. This mapping is usually where access drifts over time, so it deserves a written owner and a review cadence. Fourth, token expiry. Short lifetimes limit the damage from a leaked token but add refresh traffic, so set the value with the application teams that will call Qdrant.

Qdrant enforces what the token says, and only that. It validates the signature, checks expiry, and applies the per-collection read or write permissions to each API call. It does not decide which groups deserve which collections, and it does not manage your users. The exact token payload structure, claim names and configuration keys must be taken from the Qdrant security documentation for the release you run, not from this page or from examples in blog posts. Confirm the verification setting, the expected claim names, and how permissions are expressed, then reproduce each decision on a test cluster before anything reaches production. Build test tokens for at least one reader, one writer, and one caller with no grant, and confirm each gets the result you expect.

Per-collection permissions remove the main reason to put one shared admin key into application code. Each service receives a token that can reach only the collections it needs, and a compromised service exposes only those collections. Admin and read-only API keys still exist and remain useful. Operators need the admin key for maintenance such as creating collections or taking snapshots, and simple internal services or dashboards may be better served by a read-only key with a narrow blast radius. Decide which callers keep static keys and which move to tokens, and record that split, because mixing both models without a plan is a common source of unreviewed access.

Build sequence for Qdrant access control, with the check that closes each step

This sequence takes a self-hosted Qdrant instance from open by default to a state where every caller reaches only the collections it needs, through channels you control, and every action is attributable to an identity. Each step ends with a check you can run and record.

Inventory callers and the collections they need
Before touching configuration, list every caller: applications, ingestion pipelines, operators, analysts and monitoring jobs. For each one, record the collections it reads, the collections it writes, and whether it needs administrative actions such as creating or deleting collections. Assign each caller an owner who can confirm the list. The output is a table with one row per caller and separate read and write columns per collection. The check is that a second person from the owning team reviews the table and confirms no caller is missing, and that every row has an explicit permission level rather than a blank or 'all'. Anything not in the table is denied later.
Restrict network exposure to approved sources
Qdrant listens on all network interfaces by default and has no authentication configured, so network restriction comes first. Bind the service to the interfaces you intend to use, then limit inbound access to the REST and gRPC ports to approved application subnets, bastion hosts and pipeline runners through security groups, firewall rules or Kubernetes network policies. Keep the node-to-node ports closed to everything except other cluster members if you run distributed mode. The check is a connection attempt from an unapproved host, which must fail at the network layer, and a connection from an approved host, which must succeed. Record both results.
Enable TLS for REST and gRPC
Issue certificates from your internal certificate authority or a managed certificate service, and configure Qdrant to serve TLS on both the REST and gRPC endpoints. Confirm the TLS settings against the Qdrant security documentation for your running version, since the options are version-specific. Clients must trust the issuing authority and verify the hostname. The check is that a client connecting without TLS is refused on both protocols, and a client using the trusted certificate completes a collection listing request on each. Keep the private key out of container images and configuration repositories.
Configure admin and read-only API keys in a secrets manager
Set an admin API key and a read-only API key, using the key settings documented for your version. The admin key is for operators performing structural changes and should not be used by applications. The read-only key covers analysts and dashboards. Store both values in your secrets manager, grant read access only to the workloads that need them, and set a rotation owner. The check is a request with the read-only key that attempts a write, such as inserting points into a test collection, which must be refused, and a read request with the same key, which must succeed. Also confirm that a request without any key is refused.
Decide the token issuer and signing key custody, then configure JWT verification
Choose which identity system issues tokens for Qdrant callers, such as your existing identity provider or a service that issues tokens to workloads, and decide who holds the signing key and where it is stored. Then configure Qdrant's JWT verification settings exactly as the documentation describes for the running version, pointing it at the signing secret or public key material your issuer uses. Confirm the signing algorithm and expiry behavior before rollout. The check is that a token signed with an untrusted key is refused and a token from the trusted issuer is accepted. Document the issuer, the key owner and the rotation procedure in the same record.
Map identity groups to per-collection permissions
Translate the inventory from step one into token claims. Each identity group, such as a pipeline service account or an analyst group in your identity provider, maps to a set of collections with read or write permission. Keep the mapping one group per purpose, and avoid granting a group access to collections it does not use. Where your identity provider adds groups, make the mapping step explicit so that a change in group membership is the only thing needed to change access. The check is a peer review of the mapping against the inventory, with every collection and permission traceable to a group and every group traceable to a caller.
Issue test tokens and confirm exact permissions
Issue one test token per role and per collection, using the same issuer and settings as production. For each token, run a read on its allowed collection, a write on its allowed collection, a read on a different collection and a write on a different collection. Only the first two should succeed for a read-write role, and only the first for a read-only role. The check is a result table that matches the mapping in step five exactly. Any token that reads a collection it should not reach, or writes where it should only read, means the mapping or the verification settings need correction before go-live.
Enable audit logging and confirm caller identity
Turn on JSON audit logging of authenticated API operations, using the settings for your Qdrant version. Route the log to your central logging platform. Then perform one action with each test token from step six and find the corresponding audit entries. Each entry must carry the caller identity you expect, such as the token subject or service account, along with the operation and collection. The check is that every test action appears once with the correct identity, and that you can filter the log by that identity. If entries show only a generic key or no identity, the authentication path is not what you designed and must be fixed.
Document the mapping and the operating procedure
Write down the final state: network sources, TLS configuration, key holders and rotation schedule, issuer and signing key custody, the group-to-collection mapping, and the audit log location. Include the test results from steps four, six and seven so the baseline is reproducible. Name the owner who approves any mapping change and the process for adding a collection. The check is that someone outside the implementation team can take the document and reproduce the step six test results on a staging instance. This record is also the evidence an auditor or internal reviewer will ask for first.

How access control changes across single node, cluster, Kubernetes and air-gapped setups

A single-node Qdrant deployment has one configuration file and one process to protect, so access control is the simplest to keep consistent. Qdrant does not ship secured by default, so the API key, JWT and TLS settings must be set deliberately on that one instance before any client connects. Because there is only one place where keys live, rotating them is a matter of updating one configuration and restarting one service, although you still need a client change window.

One source of truth: admin and read-only API keys are defined in a single configuration, which makes review and audit straightforward.
Simplest key rotation: a change touches one node, so the rotation plan is short, but clients must switch keys in step with the restart.
Free tier scope: the free single-node tier in Qdrant Cloud is a managed offering with its own limits (0.5 vCPU, 1 GB RAM, 4 GB disk). It is not a way to run the open-source engine without cost on your own infrastructure.
Network exposure still applies: the instance listens on all interfaces by default, so restrict the bind address and firewall rules even on a single node.
Snapshot protection: full-storage snapshots work on single-node deployments, so the snapshot store and its access need the same controls as the API.

Before go-live, confirm with Qdrant which access mechanisms your version supports and how your tier is billed if you use Qdrant Cloud.

What drives the effort and cost of Qdrant access control

This table lists the factors that change how much work Qdrant access control and SSO takes, and how to keep each one contained. Read each row as a question to answer about your own estate before asking for a quote. The main takeaway is that role design, one shared identity source, and a single token issuer usually matter more to effort than the number of clusters.

Driver	Effect on effort	How to keep it down	What to ask for in a quote
Consuming applications and services	Each application needs its own token issuance path, scopes and rotation handling, so effort grows with the number of callers.	Group callers by function and give them shared roles instead of individual permission sets. Retire unused callers before scoping.	A list of callers, the access each needs, and how each one obtains its credentials.
Collections and distinct permission sets	Per-collection read or write permissions multiply quickly when every collection has its own rule set.	Design a small set of roles, such as read-only search, ingest and admin, and map collections to those roles.	The number of collections, the number of distinct permission sets, and the test cases needed to prove each one.
Identity provider integration	An existing OIDC or SAML-capable provider lets the work focus on token claims and mapping. A new issuer adds build, hosting and security review work.	Reuse the identity provider your organization already operates and runs for other applications.	Confirm the provider type, the claims available, who administers it, and whether a new issuer is in scope.
Environments and clusters	Each environment repeats configuration, token trust and testing. Separate issuers per environment multiply key management.	Use one token issuer for all environments and separate only the signing keys, audiences or collection names that must differ.	The environments and clusters in scope, and whether they share one issuer and one role model.
Audit and evidence requirements	Audit logging of authenticated API operations must be enabled, retained, shipped and mapped to controls. Assessor requests for evidence add review cycles.	Agree the evidence list before build, and route Qdrant audit logs into the log platform you already use.	The control set or framework the evidence supports, retention periods, log destinations, and who reviews the samples.
Token lifetime and rotation policy	Short-lived tokens need an automated refresh path in every caller. Long-lived keys need a rotation procedure and a revocation test.	Set one lifetime and rotation standard for all callers, and automate refresh where the platform allows it.	Your required token lifetime, rotation interval, revocation expectations and who approves exceptions.
SSO in Qdrant Cloud required, and at which tier	Qdrant documents SSO as a Premium tier feature with a minimum spend. Choosing Qdrant Cloud changes which access features are available and what is priced separately.	Confirm whether self-hosted JWT access meets the requirement before choosing a managed tier, since the two paths differ.	Confirm with Qdrant the current tier that includes SSO, the minimum spend, and whether SSO applies to your deployment model.

Protecting keys, signing material and token flows

These controls protect the credentials that decide who can reach Qdrant: the JWT signing key, API keys, tokens and the scopes they carry. Each card names one control, its owner and the record that shows it works, so security, platform and identity teams can divide the work.

Signing key custody and rotation

Qdrant checks JWT signatures against a key your identity layer controls, so that key determines every collection grant that follows. Owner: the identity team. Keep the signing key in a managed key store, restrict who can read or export it, and name one accountable person. Write a rotation runbook that publishes the new verification key before retiring the old one, then test that tokens signed with each key are accepted or refused as expected. Evidence: custody record, rotation runbook and a dated test log.

Admin, read-only and scoped credentials

Qdrant supports admin and read-only API keys, so operators and query services should never share one credential. Owner: the platform team. Give each operator, CI job and application its own key, and use a read-only key wherever a service only searches. For JWT tokens, grant read or write permission per collection since v1.9.0, and avoid wildcard grants that cover every collection. Evidence: an inventory mapping each credential and token scope to its holder and purpose.

Secrets storage outside code and configuration

API keys and signing material should live in a secrets manager and reach Qdrant at runtime through injected environment variables or mounted files. Owner: the platform team with the repository administrators. Keep credentials out of source repositories, Helm values files committed to git, container images and deployment manifests. Scan repositories and CI logs for credential patterns, and confirm that rotating a key does not require rebuilding an image. Evidence: secret store access policy, scan reports and a rotation drill record.

Token lifetime and revocation

A stolen token is only as dangerous as its remaining lifetime, so the lifetime must be a deliberate setting. Owner: the identity team. Agree a maximum token lifetime, document how a token is revoked before it expires, and include the signing key rotation path for cases where many tokens must stop at once. When someone leaves, removal in the identity provider should end their ability to obtain new tokens, and you should confirm with your identity team how quickly already-issued tokens stop working. Evidence: lifetime setting, leaver checklist and a refused-token test.

TLS for keys and tokens in transit

Qdrant supports TLS for REST and gRPC since v1.2.0. Without it, API keys and tokens sent with each request are readable by anyone on the network path. Owner: the platform team. Enable TLS on both interfaces, confirm which connections your TLS settings cover, including traffic between cluster nodes, and make sure client libraries verify the server certificate instead of disabling verification. Track certificate owners and renewal dates. Evidence: TLS configuration for both ports, a certificate inventory and a client connection test.

Audit log review for admin use

Qdrant writes JSON audit logs of authenticated API operations since v1.17.0, but logs only help if someone reads them. Owner: the security operations team. Decide who reviews the logs, how often, and which events count as unexpected, such as admin calls from outside the operator network or collection deletions outside a change window. Forward logs to storage that the operators cannot edit, and confirm your retention requirement with your compliance lead. Evidence: review schedule, signed review records and the list of alert conditions.

How to test access control and what to hand over after go-live

The test plan for Qdrant access control starts from the negative cases, because a self-hosted instance is open by default and the controls only count if they refuse the wrong caller. For each caller type, write a test that proves refusal: an unauthenticated request to the REST and gRPC endpoints must fail, a read-only API key must be refused on any write such as upserting points or creating a collection, and a JWT carrying permissions for one collection must be refused on a second collection. Add two token tests: an expired token and a malformed or wrongly signed token must both be rejected. Run each test against the same network path your applications use, not only from an administrator workstation, because a test that passes on a trusted host proves little about the production route.

Positive tests come next. For every role in the permission mapping, confirm that the caller can perform the operations it was granted on the collections it was granted, and nothing more. A read-only consumer should run the search and retrieve calls its application makes. A write role should complete a representative upsert and a delete on its own collection. Record the exact request, the response code and the collection name in a script so the result can be rerun after an upgrade or a configuration change. Then run a failure check: trigger errors deliberately with bad filters, oversized requests and unknown collection names, and confirm that error bodies do not list other collection names, payload contents, vectors or key material. Log output and reverse proxy logs should be included in that check.

Operations after go-live depend on a few recurring procedures. Write a rotation runbook that covers API keys and the signing material used to validate JWTs, with the order of steps for issuing the new value, rolling it into client secret stores, and retiring the old value. Confirm with your identity team how often they rotate signing keys and how a rotation affects tokens already in circulation. Audit log entries, available in recent releases, should be shipped to your central logging platform and reviewed on a schedule you set with your security team. Define who reviews them, what counts as an exception, and how long entries are retained. Onboarding and offboarding of collections and consumers should go through the permission mapping, so every new caller appears in the access matrix before it receives a credential. Track the running version against the release notes for each feature you rely on, since access control and audit logging were added in different releases, and confirm the current version against the Qdrant GitHub releases page before each change window.

The handover package should let a new engineer or an assessor reconstruct the access model without asking the original team. It should contain the access matrix, which maps each caller to each collection and each permitted operation. It should contain configuration records for the Qdrant instances, the reverse proxy and the token issuer, with every secret referenced by its location in your secret manager rather than embedded in a file. It should contain the test scripts from both test groups, the rotation and offboarding runbooks, and the audit evidence procedure, which states what evidence is collected, when, by whom and where it is stored. DeployOpen prepares these controls, configuration and evidence for compliance assessments. Independent auditors issue any audit report or attestation, so confirm with your assessor which artifacts they need and in what format before go-live.

Questions teams ask before building Qdrant access control or hiring help

Does open-source Qdrant include SSO for self-hosted deployments?

No. The self-hosted Qdrant engine does not ship single sign-on, so people do not log in to the cluster through an identity provider. SSO is listed for Qdrant Cloud on the Premium tier, which carries a minimum spend and also adds private VPC links and a 99.9% uptime SLA. Confirm the supported protocols and identity providers with Qdrant sales before you assume they match your directory. For self-hosted clusters, the usual pattern is to let your identity layer issue JWT tokens that Qdrant checks, which controls who can call the API and which collections they can reach. The application or console in front of Qdrant still needs its own login, so plan for that separately.

Can our team set up Qdrant access control without an outside partner?

Yes, if you have an engineer who knows both your identity provider and Qdrant's security configuration, plus a test cluster to try changes on first. The core settings are admin and read-only API keys, TLS for REST and gRPC, and JWT-based access with per-collection read or write permissions, which Qdrant added in v1.9.0. The hard part is usually not the Qdrant configuration itself. It is deciding which services get which permissions, wiring token issuance into your identity layer, and proving the setup works with negative tests, such as confirming that a read-only token is refused on write calls. Ask who will maintain the token model after go-live, because that work recurs as services change.

What drives the cost and timeline of Qdrant access control work?

The main drivers are the number of consumers, the number of collections with different sensitivity levels, and how your identity provider issues and rotates tokens. Each service that calls Qdrant needs a defined permission model, and each collection holding regulated or customer data may need its own read and write rules. Cost also rises with TLS on both REST and gRPC across several environments, a token service you must build, and integration with existing logging and evidence collection. Expect a one-time design and build, plus recurring work when you add services, rotate signing keys or upgrade Qdrant. Most DeployOpen engagements are fixed-scope, so the quote follows from a written scope listing these drivers and their assumptions. Ask any provider to itemize them the same way.

What do we need to provide before Qdrant access control work starts?

Plan to provide five things: access to your identity provider, a list of every consumer that calls Qdrant, a list of collections with their data classification, a test environment close enough to production to trust the results, and a decision on who owns signing keys and how they rotate. You also need a named owner for audit evidence. The JSON audit logging Qdrant added in v1.17.0 records authenticated API operations, so someone must decide where those logs go, how long they are kept and who reviews them. Name the people who approve changes to tokens and keys as well. Missing any one of these usually delays the design more than the build itself.

Are API keys enough to secure Qdrant in production?

API keys can be enough for a small number of trusted services, provided admin keys stay away from applications and read-only keys cover services that only read. They do not scope access per collection, though. Once several teams or services share a cluster and different collections hold different data, JWT tokens with per-collection read or write permissions are the stronger fit, available since v1.9.0. Keys also need rotation, and a leaked admin key grants full control of the cluster. Put network controls in front of Qdrant either way, because by default self-deployed instances listen on all network interfaces with no authentication configured. Settle the access model before you load production data.

How does an implementation partner differ from a managed Qdrant Cloud plan?

A managed Qdrant Cloud plan provides the hosted service, and SSO is available on its Premium tier with a minimum spend. An implementation partner works inside your own infrastructure. The self-hosted engine runs in your cloud accounts, data centers or air-gapped network, and the partner plans, configures, integrates, hardens and documents it. This matters when data residency, network isolation or identity policy prevent use of a vendor-hosted control plane. A partner does not take over ownership of your keys, tokens and audit logs, and it does not issue audit reports or certifications. Qdrant also offers Hybrid Cloud and Private Cloud options, priced through its sales team, so compare those terms directly with any quote you receive.

Which Qdrant access control mistakes cause exposure or outages first?

Common mistakes include leaving a self-deployed instance unauthenticated and reachable on all interfaces, which is the default state. Next is giving applications the admin key, so one leaked secret controls the whole cluster. Teams also enable JWT but never test denial, so a read-only token still performs writes. Token signing keys are sometimes copied across environments or never rotated. Finally, audit logging is switched on but the logs are not shipped anywhere, so nobody can answer who changed a collection. Test each path with a credential that should fail. Confirm exact configuration keys against the Qdrant version you run, because behavior can change between releases.

How DeployOpen scopes, builds and hands over Qdrant access control

DeployOpen scopes Qdrant access control as part of a fixed-scope engagement inside your own infrastructure. Self-hosted Qdrant listens on all interfaces with no authentication by default, so the work starts by deciding who reaches which collection. We build the API key, JWT and audit layers against your identity provider, then document and hand them over.

How we scope

The written scope names every Qdrant node, collection and API client that needs access control.
Access roles are mapped to admin, read-only and per-collection read or write permissions before any build starts.
We confirm which SSO path applies, since Qdrant Cloud SSO depends on the plan you choose.

How we build

Enable API key authentication and TLS for REST and gRPC before exposing any node to client networks.
Issue JWT tokens from your identity layer carrying per-collection read or write claims, tested against each role.
Configure JSON audit logging for authenticated API operations and route the logs to your existing log platform.

How we hand over

Test each role with allowed and denied requests, and record the results in a verification report.
Document key issuance, token lifetimes, rotation steps and collection permission mappings in a runbook.
Walk your security and platform teams through the access model and the evidence they can use in assessments.

How we support

Ongoing support is available as a retainer that can cover key rotation, role changes and audit log review.
Version upgrades are checked against your access settings before rollout, with a backup taken first.
Confirm with Qdrant which SSO and access features your chosen deployment path includes before scoping begins.

Qdrant access control and SSO