Add EKS Node Diagnostics MCP server

[shyamkulkarni]

Description

Adds the AWS EKS Node Diagnostics MCP server (mcp/aws-eks-node-diagnostics-mcp): a CDK-deployed MCP server that lets the DevOps Agent collect and analyze EKS worker node logs via SSM Automation (the AWS-managed AWSSupport-CollectEKSInstanceLogs document), with 19 tools across four tiers (core operations, log analysis, cluster-level diagnostics, and 41 structured SOP runbooks).

Key design points:

• Human-in-the-loop collection approval (on by default): the only mutating tools, collect and batch_collect, run through wrapper SSM Automation documents whose first step is the native aws:approve action. The execution pauses in SSM until a designated approver (IAM principals fixed at deploy time via APPROVAL_APPROVER_ARNS) approves in the Systems Manager console. Decisions are IAM-authenticated and CloudTrail-audited; the MCP Lambda has no ssm:SendAutomationSignal permission, so an agent cannot approve its own request. The agent just polls status() and collection proceeds automatically on approval.
• Fail-closed security defaults: cluster allowlist required at synth time, region restriction, SSM document restriction, per-tool client ACLs, per-caller rate limiting, presigned URL expiry caps, and response redaction.
• Auth and transport: Cognito OAuth2 in front of a BedrockAgentCore Gateway MCP endpoint; optional VPC deployment with S3/KMS endpoints.

Type of change

• New skill
• New custom agent
• Update to an existing skill or agent
• Documentation or infrastructure change (new MCP server)

Testing

• npm run build (tsc) — passes
• npm test — 12/12 jest tests passed (fast-check property tests for construct IAM and KMS/S3 policies), 44/44 pytest tests passed (approval workflow, region validation, tool validation wiring)
• Manually deployed via deploy.sh and exercised the approval flow end to end: collect returns pending_approval with an SSM console deep link, approval in the console resumes collection, and status() reports the approval state and collection progress

License confirmation

• By submitting this pull request, I confirm that my contribution is made under the terms of the Apache License 2.0.

[LearningNewbie]

Nitpicking, not a blocker: this JSDoc block (lines 2267–2278) describes the old DynamoDB/Function-URL approval mechanism (approvalId, token, DynamoDB record, approvalViaPublicUrl) that this exact PR removes. Looks like it got orphaned above getUnzipLambdaCode() during the refactor to native aws:approve — the function body below it is correct and unrelated to approval logic, just the comment is stale. Suggest deleting the second JSDoc block so it doesn't mislead the next reader into thinking there's a DynamoDB-based approval path elsewhere in the file.

[shyamkulkarni]

Addressed the review feedback in 44c60b8:

Comment 2 (idempotent replay loses approval context) — fixed. find_execution_by_idempotency_token now returns the execution's documentName, resolved region, and full execution snapshot, and the idempotent-return branch in start_log_collection runs the same augment_wrapper_status enrichment that status() uses whenever the existing execution is an approval wrapper. A retried collect() with the same token now reports humanApproval.state: pending with the SSM console deep link and polling guidance instead of a bare InProgress. The replay response also reports the execution's actual region rather than the current request's resolved region. Two regression tests cover the wrapper and plain-collection replay paths.

Comment 3 (single-region approval gate) — warning added. Single-region approval-gated collection is intentional for now: the wrapper documents are regional SSM documents owned by the stack, and embedding deployment-owned approvers/role/topic per region means the right fix is a stack per region rather than cross-region document sharing. Per the suggestion, synthesis now emits a cdk.Annotations warning when requireCollectionApproval is enabled and allowedRegions spans multiple regions, so operators learn at deploy time that approval-gated collect()/batch_collect() only works in the stack's home region.

Comment 4 (IAM document scoping) — agreed, deferring as a follow-up. Two corrections worth noting for whoever picks it up: (1) the scoped document list must also include the tcpdump approval wrapper, otherwise approval-gated captures break when the restricted tools are enabled; (2) the automation-definition/* resources in the same statements need the same scoping (with version qualifiers, e.g. automation-definition/<name>:$DEFAULT), otherwise the tightening is cosmetic since that resource type still authorizes StartAutomationExecution. The per-region lists also differ: wrapper documents exist only in the home region, while AWSSupport-CollectEKSInstanceLogs is AWS-owned in every allowed region.

Validation: 46 Python tests pass (including the 2 new regression tests) and the TypeScript build is clean. The pre-existing jest property-test failures (test-file parse errors and the missing lib/sops/runbooks asset) reproduce identically on the unmodified head and are unrelated; happy to fix those separately.