RBAC - cturner8/kube-mcp GitHub Wiki

Since kube-mcp runs in-cluster, it leverages Kubernetes' native Role Base Access Control (RBAC) system to provide granular resource-level access control. This adds an additional security layer on top of the MCP tool allow/disallow mechanism.

The server uses a Kubernetes ServiceAccount to authenticate to the Kubernetes API. The permissions granted to this ServiceAccount determine which Kubernetes resources kube-mcp can access, regardless of which MCP tools are enabled.

1. OIDC Authentication: Users must authenticate via OIDC to access the MCP server
2. Tool Restrictions: Configure mcp.tools.allowed or mcp.tools.disallowed to control which MCP tools are available
3. Kubernetes RBAC: The ServiceAccount's RBAC permissions determine which resources can actually be accessed

The Helm chart creates the following RBAC resources by default:

rbac:
  create: true
  rules:
    # Core resources
    - apiGroups: [""]
      resources:
        - pods
        - services
        - persistentvolumeclaims
        - persistentvolumes
        - nodes
        - namespaces
        - events
      verbs:
        - get
        - list

    # Apps resources
    - apiGroups: ["apps"]
      resources:
        - deployments
      verbs:
        - get
        - list

    # Networking resources
    - apiGroups: ["networking.k8s.io"]
      resources:
        - ingresses
      verbs:
        - get
        - list

Note: Secrets and ConfigMaps are intentionally excluded from the default RBAC rules, even though tools exist for them. This ensures sensitive data cannot be accessed unless explicitly granted.

You can customize the RBAC rules in your Helm values file to align with your security requirements.

If you want to allow access to Secrets (and have enabled the corresponding tools):

rbac:
  create: true
  rules:
    - apiGroups: [""]
      resources:
        - pods
        - services
        - secrets # Add secrets
        - configmaps # Add configmaps
        - persistentvolumeclaims
        - persistentvolumes
        - nodes
        - namespaces
        - events
      verbs:
        - get
        - list
    - apiGroups: ["apps"]
      resources:
        - deployments
      verbs:
        - get
        - list
    - apiGroups: ["networking.k8s.io"]
      resources:
        - ingresses
      verbs:
        - get
        - list

To only allow access to Pods and Deployments:

rbac:
  create: true
  rules:
    - apiGroups: [""]
      resources:
        - pods
        - namespaces # Still needed for namespace operations
      verbs:
        - get
        - list
    - apiGroups: ["apps"]
      resources:
        - deployments
      verbs:
        - get
        - list

Only grant access to resources actually needed by your enabled MCP tools.

Ensure your mcp.tools.allowed/disallowed configuration matches your RBAC rules:

• If a tool is allowed but RBAC denies access, users will get permission errors
• If RBAC grants access but a tool is disallowed, the tool won't be available in MCP clients

After deployment, verify the ServiceAccount has the expected permissions:

# Check the ClusterRole
kubectl get clusterrole kube-mcp -o yaml

# Check the ClusterRoleBinding
kubectl get clusterrolebinding kube-mcp -o yaml

# Test specific permissions (replace <namespace> with your deployment namespace)
kubectl auth can-i list pods --as=system:serviceaccount:<namespace>:kube-mcp
kubectl auth can-i get secrets --as=system:serviceaccount:<namespace>:kube-mcp

To use a pre-configured ServiceAccount with custom RBAC:

serviceAccount:
  create: false
  name: my-existing-serviceaccount

rbac:
  create: false # Don't create new RBAC resources

Ensure your existing ServiceAccount has the necessary permissions for the MCP tools you plan to use.

The ServiceAccount lacks permission to access pods. Add the resource to rbac.rules.

Secrets are not included in default RBAC. Either:

• Add secrets to rbac.rules, or
• Disable secret-related tools via mcp.tools.disallowed

The API group is missing from RBAC rules. Check the resource's API group:

kubectl api-resources | grep <resource-name>

Then add the appropriate rule to your RBAC configuration.