Manticore Search now includes built-in authentication and authorization starting with the 27.x release line. The feature covers SQL/MySQL clients (username/password), HTTP clients (Basic auth or Bearer tokens), distributed remote agents, and replication operations. The authorization model defines five actions — read, write, schema, replication, and admin — applied to named targets or wildcards. This replaces common workarounds like putting nginx in front of Manticore for access control. For SaaS and shared search deployments, it enables per-user permission boundaries, audit logging, and compliance-friendly controls (GDPR, SOC 2). Rollout guidance is provided: auth is disabled by default, and existing deployments should update clients and test before enabling in production. Distributed topologies should upgrade remote agents and replication peers before enabling auth on masters.
Table of contents
What Manticore addsWhat changes for operatorsWhy this matters for SaaS and shared searchRollout notesLearn moreQuestions this post answers
How does authentication work in Manticore Search 27.1.5?
Manticore Search 27.1.5 introduces built-in authentication and authorization across SQL/MySQL clients, HTTP/HTTPS clients, distributed remote agents, and replication operations. SQL clients authenticate with a username and password, while HTTP clients use Basic authentication or Bearer tokens. Permissions are granted using five actions: read, write, schema, replication, and admin, applied against named or wildcard targets like table names. Teams rolling out Manticore Search auth can track release specifics like this on daily.dev.
Is authentication enabled by default when I upgrade Manticore Search?
No, authentication is disabled by default until explicitly configured. Once enabled, clients that fail to send credentials will be rejected, so applications should be updated and tested for expected denials before switching production traffic over. For distributed or replicated setups, remote agents and replication peers should be upgraded before the masters, with auth enabled only once the whole topology runs a compatible version. Anyone planning a security rollout can follow migration guidance like this on daily.dev.
What permission model does Manticore Search use for authorization?
Manticore Search authorization uses five actions: read for search and read-only access, write for data changes, schema for table and schema management, replication for cluster operations, and admin for managing authentication and authorization itself. Targets can be specific names or wildcards, such as products, logs_*, or *, letting operators scope permissions per table or cluster. Developers comparing database access-control models can dig into details like these on daily.dev.
1 Comment
Share this post