Skip to content

feat(mysql-mcp-server): restore --secret_arn for custom-secret auth (#3643, #4099) - #4585

Open
warren830 wants to merge 1 commit into
awslabs:mainfrom
warren830:fix/3643-mysql-secret-arn
Open

feat(mysql-mcp-server): restore --secret_arn for custom-secret auth (#3643, #4099)#4585
warren830 wants to merge 1 commit into
awslabs:mainfrom
warren830:fix/3643-mysql-secret-arn

Conversation

@warren830

@warren830 warren830 commented Sep 4, 2026

Copy link
Copy Markdown

Issues

Fixes #3643. Closes #4099.

Problem

mysql-mcp-server 1.0.21 removed the ability to authenticate with an operator-supplied Secrets Manager secret: secret_arn is now derived exclusively from the cluster/instance's AWS-managed MasterUserSecret. This silently forces connections as the master user — a privilege regression (#3643) for setups that previously connected as a dedicated least-privilege user (e.g. read-only) via a custom secret. mssql-mcp-server still supports --secret_arn, so the two servers are also out of parity (#4099).

The connection layer (AsyncmyPoolConnection / RDSDataAPIConnection) already accepts an arbitrary secret_arnserver.py simply never exposed a way to set it.

Fix

  • Add a --secret_arn CLI flag, wired exactly like the existing --ca_bundle (module global configured_secret_arn, declared in internal_connect_to_database and main, set from args.secret_arn).
  • When provided, it overrides the derived MasterUserSecret ARN for the mysqlwire (non-IAM) and rdsapi methods.
  • It is ignored for mysqlwire_iam, which authenticates via IAM and uses no secret (that path's secret_arn stays '').
  • README documents the least-privilege use case.

Tests

Added to tests/test_server.py::TestInternalConnectToDatabaseRouting:

  • --secret_arn overrides MasterUserSecret on the wire path;
  • --secret_arn overrides it on the RDS Data API path;
  • --secret_arn is not applied to IAM auth (secret_arn == '').

Strict red→green verified: neutralizing the override makes the two override tests fail (connection would use arn:master-user-secret); the fix makes them pass, and the IAM-ignored test passes both ways. Full test_server.py (28 tests) green; ruff check / ruff format --check clean.

Compatibility

No behavior change when --secret_arn is omitted (the managed MasterUserSecret is still used), so existing deployments are unaffected.


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

…wslabs#3643, awslabs#4099)

1.0.21 removed the ability to authenticate with an operator-supplied Secrets Manager secret; secret_arn was derived exclusively from the cluster/instance MasterUserSecret, silently forcing connections as the master user (a privilege escalation for setups that previously used a least-privilege secret). The connection layer already accepts an arbitrary secret_arn, but server.py never exposed it. Add a --secret_arn CLI flag (module global configured_secret_arn, wired exactly like --ca_bundle) that overrides the derived MasterUserSecret ARN for the mysqlwire and rdsapi methods, and is ignored for mysqlwire_iam (IAM auth uses no secret). Restores the removed capability (awslabs#3643) and reaches parity with mssql-mcp-server (awslabs#4099). Adds tests asserting the override reaches the connection constructor on both wire and Data-API paths and does not leak into IAM auth; documents the least-privilege use case in the README.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: To triage

1 participant