# Security Best Practices for Production Deployment of the MCP Ambari API Server

> Secure your MCP Ambari API server in production with essential best practices. Enable token auth, use strong secrets, terminate TLS at a proxy, and restrict network access.

- Repository: [JungJungIn/mcp-ambari-api](https://github.com/call518/mcp-ambari-api)
- Tags: best-practices
- Published: 2026-02-26

---

**Enable bearer token authentication via `REMOTE_AUTH_ENABLE=true`, use a cryptographically strong `REMOTE_SECRET_KEY`, terminate TLS at a reverse proxy, and restrict network exposure to trusted subnets to secure the MCP Ambari API server in production.**

Deploying the `call518/mcp-ambari-api` server in production requires hardening its default configuration to protect sensitive Hadoop cluster credentials and API endpoints. While the repository ships with optional authentication and plain HTTP for local development, production workloads demand strict transport security, strong secret management, and network isolation. This guide covers the essential security best practices for production deployment derived directly from the source code implementation.

## Enable Bearer Token Authentication for Remote Access

The server supports two transport modes—**stdio** for local execution and **streamable-http** for remote clients. When exposing the HTTP endpoint, you must enable token-based authentication to prevent unauthorized access to Ambari cluster operations.

In [`src/mcp_ambari_api/mcp_main.py`](https://github.com/call518/mcp-ambari-api/blob/main/src/mcp_ambari_api/mcp_main.py), the authentication flow is controlled by the `REMOTE_AUTH_ENABLE` environment variable. The `_parse_bool_env` helper normalizes truthy values (`true`, `1`, `yes`, `on`) at line 3814 to determine whether to install the `StaticTokenVerifier`.

When enabled, the `_build_static_token_auth` function (line 66) constructs a `StaticTokenVerifier` using the `REMOTE_SECRET_KEY`. The server then injects this verifier into `mcp.auth` before calling `mcp.run()` (lines 3832–3836).

If authentication is disabled while running in HTTP mode, the server emits a warning at line 3828: `"SECURITY WARNING: Remote access authentication is disabled..."`.

To enable authentication, set the following in your `.env` file:

```dotenv

# .env (production)

REMOTE_AUTH_ENABLE=true
REMOTE_SECRET_KEY=5f8e3c2a9d6b4a7d8e1f2c3b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3
FASTMCP_TYPE=streamable-http
FASTMCP_HOST=0.0.0.0
FASTMCP_PORT=8000

```

## Secure Secret Management and Rotation

The default `.env.example` ships with a weak placeholder secret (`my-test-secret-key-12345`) that must never be used in production. The `StaticTokenVerifier` performs a constant-time comparison of the Bearer token against `REMOTE_SECRET_KEY`, but the security of this mechanism depends entirely on the entropy of the secret itself.

Generate a production-grade secret using:

```bash
openssl rand -hex 32

```

Store this value exclusively in environment variables or a dedicated secret manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Avoid committing `.env` files to version control by ensuring `.env` is listed in `.gitignore`.

Implement a rotation policy that updates `REMOTE_SECRET_KEY` quarterly or immediately after any suspected compromise. When rotating, generate a new secret, update the environment variable, and restart the server process. Clients must update their Bearer tokens simultaneously to avoid service interruption.

## Transport Layer Security and Network Hardening

The MCP server itself runs plain HTTP on the internal port specified by `FASTMCP_PORT` (default 8000). It does not handle TLS termination internally, relying instead on external infrastructure for encryption.

For production deployment, place the server behind a reverse proxy such as NGINX, Traefik, or Caddy that handles TLS termination. This architecture ensures that the `REMOTE_SECRET_KEY` and all API traffic travel encrypted over the public internet.

Example NGINX configuration:

```nginx
server {
    listen 443 ssl;
    server_name ambari-mcp.example.com;
    
    ssl_certificate /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;
    
    location /mcp {
        proxy_pass http://localhost:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

```

Restrict network exposure by binding the MCP server to localhost (`127.0.0.1`) rather than `0.0.0.0` when running behind a reverse proxy on the same host. If deploying in a container environment, use internal Docker networks or Kubernetes NetworkPolicies to ensure only the reverse proxy can reach the MCP container on port 8000.

Docker Compose example with network isolation:

```yaml
services:
  mcp-server:
    image: call518/mcp-server-ambari-api:latest
    env_file: .env
    networks:
      - internal
    expose:
      - "8000"

  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on:
      - mcp-server
    networks:
      - internal

networks:
  internal:

```

## Operational Security and Monitoring

The repository uses standard Python logging controlled by `MCP_LOG_LEVEL` (default `INFO`). Authentication events, including failed token validations, generate log entries via `logger.info`, `logger.warning`, and `logger.error` calls in [`mcp_main.py`](https://github.com/call518/mcp-ambari-api/blob/main/mcp_main.py).

Configure centralized log aggregation to a SIEM platform such as Splunk, ELK Stack, or Datadog. Create alerts for patterns indicating brute-force attacks, such as:

- Multiple 401 Unauthorized responses within short time windows
- Requests missing Authorization headers from external IP addresses
- Sudden spikes in authentication failure rates

Set `MCP_LOG_LEVEL=WARNING` in production to reduce noise while retaining security-relevant events. Enable `DEBUG` level only in staging environments when troubleshooting specific auth flows.

Dependency security is managed through [`pyproject.toml`](https://github.com/call518/mcp-ambari-api/blob/main/pyproject.toml), which pins versions for `aiohttp>=3.12.15` and `fastmcp>=2.12.3`. Regularly update dependencies using `uv sync --upgrade` or enable Dependabot to receive automated security patches. Implement pre-commit hooks with `gitleaks` to prevent accidental commits of secrets.

Client configuration must include the Bearer token in the Authorization header. When configuring external LLM clients like Claude Desktop or OpenWebUI, provide the token as follows:

```json
{
  "mcpServers": {
    "mcp-ambari-api": {
      "type": "streamable-http",
      "url": "https://ambari-mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer 5f8e3c2a9d6b4a7d8e1f2c3b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3"
      }
    }
  }
}

```

## Summary

- **Enable authentication** by setting `REMOTE_AUTH_ENABLE=true` to activate the `StaticTokenVerifier` in [`src/mcp_ambari_api/mcp_main.py`](https://github.com/call518/mcp-ambari-api/blob/main/src/mcp_ambari_api/mcp_main.py).
- **Use strong secrets** generated with `openssl rand -hex 32` and store them in environment variables or secret managers, never in code repositories.
- **Terminate TLS externally** using a reverse proxy (NGINX, Traefik, Caddy) since the server runs plain HTTP internally.
- **Restrict network access** by binding to `127.0.0.1` or using container network policies to limit exposure.
- **Monitor authentication events** via centralized logging and alert on 401/403 patterns to detect brute-force attempts.
- **Maintain dependency hygiene** by regularly updating pinned versions in [`pyproject.toml`](https://github.com/call518/mcp-ambari-api/blob/main/pyproject.toml) and scanning for leaked secrets.

## Frequently Asked Questions

### Is authentication enabled by default in the MCP Ambari API server?

No, authentication is disabled by default. The `REMOTE_AUTH_ENABLE` environment variable defaults to `false` in the example configuration, and the server emits a security warning at startup when running in HTTP mode without authentication. You must explicitly set `REMOTE_AUTH_ENABLE=true` to enable the `StaticTokenVerifier` that validates Bearer tokens against `REMOTE_SECRET_KEY`.

### How should I generate and store the REMOTE_SECRET_KEY for production?

Generate a cryptographically secure secret using `openssl rand -hex 32` to create a 64-character hexadecimal string. Store this value exclusively in environment variables loaded from a protected `.env` file (excluded from version control via `.gitignore`) or inject it through a secret manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Never hardcode the secret in application files or commit it to repositories.

### Does the MCP Ambari API server support HTTPS natively?

No, the server runs plain HTTP on the internal port specified by `FASTMCP_PORT` (default 8000) and does not handle TLS termination internally. For production deployments, you must place the server behind a reverse proxy such as NGINX, Traefik, or Caddy that handles TLS termination. This ensures that the `REMOTE_SECRET_KEY` and all API traffic travel encrypted over the public internet while the internal server communicates over plain HTTP.

### What logging configuration helps detect unauthorized access attempts?

Set `MCP_LOG_LEVEL=INFO` or `WARNING` to capture authentication events logged by [`mcp_main.py`](https://github.com/call518/mcp-ambari-api/blob/main/mcp_main.py), including failed token validations that generate 401 Unauthorized responses. Configure centralized log aggregation to a SIEM platform such as Splunk, ELK Stack, or Datadog, and create alerts for patterns indicating brute-force attacks. Specifically, monitor for multiple 401 responses within short time windows, requests missing Authorization headers from external IP addresses, and sudden spikes in authentication failure rates.