[RORDEV-2028] AI/MCP API keys example#6
Open
coutoPL wants to merge 2 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AI/MCP API Keys
This example demonstrates how ReadonlyREST enables AI/MCP-style access to Elasticsearch using Elasticsearch-native API keys. It shows how to issue per-user, read-only, index-restricted, expirable, and revocable API keys for use by AI assistants or MCP (Model Context Protocol) clients, and how those keys are audited through ROR's audit log.
What this example demonstrates
indices:data/read/*)*-reports, not*-logs)readonlyrest_audit-*indexUser simulation
Alice and Bob are simulated using ReadonlyREST local users with
auth_keycredentials defined in theuserssection ofreadonlyrest.yml. LDAP is intentionally not used in this PoC. In a production deployment, Alice and Bob would correspond to real users from an identity provider (LDAP, SAML, OIDC). The local users stand in for per-user access rules that would be defined in the production ACL.Fake AI/MCP service
fake-ai-mcp-query.shis not a real MCP server or AI assistant. It is a minimal shell script that simulates an AI/MCP client querying Elasticsearch using a user-specific API key viaAuthorization: ApiKey <encoded-key>. In a real deployment, the MCP server or AI assistant would obtain and store the API key and make equivalent Elasticsearch requests. The important aspects of this PoC are authentication, authorization, revocation, expiration, and audit behaviour — not AI logic.Architecture
ROR enforces the read-only constraint and the AI/MCP index scope (
alice-reports,bob-reports). AI/MCP tokens cannot reach the operational log indices (alice-logs,bob-logs) regardless of which user's key is used.How to run
Start
From the repository root:
Run the demo
cd examples/ai-mcp-api-keys bash scripts/demo.shdemo.shperforms the full lifecycle:fake-ai-mcp-query.shManual fake AI/MCP queries
After
demo.shhas run once (to create API keys in.runtime-keys/):The
ESenvironment variable can be set to override the default Elasticsearch address:Stop and clean up
From the repository root:
Generated API key files are stored in
examples/ai-mcp-api-keys/.runtime-keys/and are excluded from version control via.gitignore.Expected results
alice-reportsalice-logsbob-reportsalice-logsalice-reportsbob-reportsalice-reportsAuditability
ROR writes an audit event for every request to the
readonlyrest_audit-*index. The index pattern is created automatically by the init script. To inspect events:admin:adminreadonlyrest_audit-*index patternAudit fields visible in this example:
userai-mcp(the username assigned to the ROR ACL block for all API key requests)acl_blockAI/MCP API key access(allowed) orFORBIDDEN(denied)actionindices:data/read/searchindicestypeALLOWEDorFORBIDDENNote: the audit log records the logical username configured in the
token_authenticationblock (ai-mcp), not the identity of the API key creator. The API key name and id are not directly available in ROR audit fields in this configuration. Use Elasticsearch's ownGET /_security/api_keyendpoint (with admin credentials) to correlate key ids with named keys.Security notes
.runtime-keys/and are excluded from version control.