搜索不再只是网站上的一个框。在许多部署中，Manticore Search 更像一个内部数据服务：应用程序向它查询，导入任务更新它的表，仪表盘从它读取数据，而运维人员修改模式。当这一切都只依赖网络层面的信任时，访问控制很快就会变得脆弱。
这就是 Manticore Search 现在具备内置认证与授权的原因。它在 27.x 发布线中引入，并发布在 27.1.5 发布文章 中，让 Manticore 能够检查谁在连接，以及该用户被允许做什么。
该功能适用于 SQL、HTTP/HTTPS 客户端、分布式远程代理以及复制相关操作。
Manticore 新增了什么
Manticore 现在为核心访问路径提供认证与授权支持：
- SQL/MySQL 客户端使用用户名和密码进行身份验证。
- HTTP 客户端可以使用 Basic 认证或 Bearer 令牌。
- 权限按操作和目标授予。
- 认证事件可以按可配置级别记录日志。
- 用户和权限通过专门的 SQL 命令管理。
授权模型使用五种操作：
read用于搜索和只读访问。write用于数据变更。schema用于表和模式管理。replication用于集群操作。admin用于认证与授权管理。
目标是普通名称和通配符，例如 products、logs_* 或 *。这样这个模型就更贴近人们对 Manticore 表和集群的既有认知。
对运维人员意味着什么
常见的情况是，某个客户端应用可以搜索一张表，但没有写入权限。数据导入流程可以更新文档，但不能修改模式。模式迁移任务可以运行，但不会被授予安全管理员权限。运维人员可以管理认证与授权，而不会自动获得业务数据的读取权限。
一旦搜索成为共享基础设施的一部分，这些权限边界就很重要。重点不只是把外部人挡在外面，而是让每个受信任的客户端都只被限制在它真正需要的范围内。
Manticore 现在为这些控制提供了原生落点。用户通过他们已经在用的协议进行认证。Manticore 根据操作和目标检查权限。运维人员通过 SQL 命令管理访问。应用程序继续保持原有的 SQL 或 HTTP 集成方式。
为什么这对 SaaS 和共享搜索很重要
SaaS 和共享服务团队通常需要一层搜索来服务多个产品、团队或租户。有些集成面向客户，有些是内部工具，还有些在后台运行。它们不应默认继承同样的信任级别。
在内置认证出现之前，团队往往不得不在 Manticore 外部解决其中的大部分问题。一个常见的变通方法是在 Manticore 前面放置 nginx，并在那一层依赖 HTTP Basic 认证。这样可以保护一个入口点，但不能让 Manticore 拥有自己的用户和权限模型。现在，团队可以在数据实际提供的地方更直接地建模这些控制。
这让 Manticore 更适合用于面向客户的敏感数据搜索、具有不同权限级别的内部工具，以及多个服务共用的搜索集群。
认证与授权本身并不是一套合规方案。不过，它们属于审查人员希望看到的那类控制。对于 GDPR、SOC 2 以及内部安全审查，展示具名用户、受限权限和认证日志，比展示一个能做所有事情的共享凭据更有说服力。
部署说明
运维人员可以启用认证、引导首个管理员，然后用熟悉的 SQL 命令管理用户和权限。应用程序无需为了开始发送凭据就引入一个新的、Manticore 特定的网关。SQL 客户端使用用户名和密码。HTTP 客户端使用 Basic 认证或 Bearer 令牌。
对于现有部署，要把这次切换当作一次正式上线，而不只是一次配置变更。默认情况下，认证在配置前是禁用的。一旦启用，未发送凭据的客户端应当失败，因此应先更新应用程序，并在切换生产流量之前测试预期中的拒绝情况。
对于分布式或复制拓扑，请仔细规划部署。先升级远程代理和复制对等节点，再升级查询或管理它们的主节点，并且只在整个拓扑都运行兼容版本后再启用认证。
了解更多
如需实操演示，请参阅这篇实践发布文章：
如何使用内置认证与授权保护 Manticore Search
如需了解现有部署的处理方式，请查看上线清单：
Manticore Search 现有部署的认证迁移加固清单
如需完整参考，请查看手册页面：