Security

This chapter describes authentication, write-tool controls, deployment hardening, and security considerations for AI-assisted operations.

The MCP Server can query and modify managed infrastructure. Treat it as a privileged administrative interface.

1. Security model

The server supports two authentication paths:

Basic SUSE Multi-Linux Manager authentication

In a stdio or trusted deployment, the server logs in with UYUNI_USER and UYUNI_PASS. All MCP clients that use that process receive the permissions of this account.

OAuth bearer token

In an authenticated HTTP deployment, the MCP Server validates the caller’s token and forwards it to the SUSE Multi-Linux Manager OIDC login endpoint. SUSE Multi-Linux Manager then maps the token to an existing active user.

Use a dedicated, least-privileged SUSE Multi-Linux Manager account for basic authentication. For a multi-user HTTP deployment, use OAuth so that actions retain individual user identity and permissions.

2. OAuth configuration

The MCP Server expects an OpenID Connect issuer. It retrieves signing keys from:

<UYUNI_AUTH_SERVER>/protocol/openid-connect/certs

Tokens accepted by the MCP Server must:

  • Have an issuer that exactly matches UYUNI_AUTH_SERVER.

  • Include the mcp-server-uyuni audience.

  • Include the mcp:read scope.

  • Include the mcp:write scope when write tools are enabled.

Configure the same identity provider on the SUSE Multi-Linux Manager Server in /etc/rhn/rhn.conf:

web.oidc.enabled = true
web.oidc.idp.issuer = https://idp.example.com/realms/mcp

You can explicitly set the JSON Web Key Set path:

web.oidc.idp.jwks_path = /realms/mcp/protocol/openid-connect/certs

If the path is not set, SUSE Multi-Linux Manager discovers it from the issuer’s /.well-known/openid-configuration document.

The default SUSE Multi-Linux Manager audience and username claim are:

web.oidc.jwt.audience = uyuni-server
web.oidc.jwt.username_claim = preferred_username

The token forwarded to SUSE Multi-Linux Manager must include:

  • The uyuni-server audience, in addition to the mcp-server-uyuni audience.

  • A sub claim.

  • A configured username claim whose value matches an existing active SUSE Multi-Linux Manager user.

Restart the relevant SUSE Multi-Linux Manager services after changing rhn.conf.

3. Write tool controls

State-changing tools are not registered unless UYUNI_MCP_WRITE_TOOLS_ENABLED=true.

When write tools are enabled, the server asks for confirmation before a change if the MCP client advertises the MCP elicitation capability. Clients without elicitation support do not receive this server-side confirmation. Such clients are responsible for their own approval user experience.

Do not rely on elicitation as the only authorization control. Use SUSE Multi-Linux Manager role-based access control permissions, OAuth scopes, network restrictions, and client-side tool approval policies.

Enable write tools only for a deployment where they are required. For high-risk operations:

  • Resolve and verify the target system ID.

  • Review the generated arguments before approval.

  • Apply changes to a small scope first.

  • Verify the resulting scheduled action in the SUSE Multi-Linux Manager Web UI.

Using the remove_system tool is a destructive operation. When cleanup=true, the tool requests forced deletion and cleanup of the system.

4. Hardening the deployment

You can harden the MCP Server deployment by applying the following controls:

  • Provide TLS termination for HTTP deployments.

  • Never expose unauthenticated HTTP mode to an untrusted network.

  • Keep UYUNI_MCP_SSL_VERIFY=true.

  • Store passwords, OAuth configuration, and SSH private keys in a secrets-management system or protected environment file.

  • Pin the MCP Server container to a reviewed release.

  • Use INFO or WARNING logging in production and protect log files from unauthorized access.

  • Restrict network access from the MCP Server to the required SUSE Multi-Linux Manager and identity-provider endpoints.

5. AI and prompt security

An AI assistant can use text from prompts and external content when deciding whether and how to call a tool. This content might contain misleading or malicious instructions. Treat any tool call based on untrusted content as untrusted until you review it.

Configure the MCP host to require explicit approval for state-changing tools. Before approval, verify the tool name, target IDs, update or action IDs, and all arguments. Do not provide secrets in prompts. Do not ask the model to reproduce environment variables, access tokens, passwords, or private keys.