Demo Cnd France 2026

演示CND法国2026

此演示展示了Kyverno策略如何强制MCP网关工具调用的身份验证和授权。

先决条件

• 使用Kyverno Envoy插件运行的Kind集群
• Keycloak已配置用户和组
• 已部署代理网关和KGateway
• 应用的策略： no-unauthenticated-calls 和 create-from-url-authz

设置

1. 确保所有组件都在运行：

   kubectl get pods -n kyverno
   kubectl get pods -n keycloak

1. 获取不同用户的身份验证令牌：

   # Get token for a user in kube-dev group
   ./get-token.sh alice

   # Get token for a user in kube-admin group
   ./get-token.sh admin

______________________________________________________________________

示例1：限制所有未经授权的呼叫

此示例演示了 no-unauthenticated-calls 强制所有MCP网关请求的身份验证和组成员身份的策略。

政策概述

这 no-unauthenticated-calls 政策：

• 从Authorization标头验证JWT令牌
• 使用Keycloak JWKS端点验证令牌签名
• 检查用户是否属于允许的组(kube-dev 或 kube-admin)
• 返回401无效或丢失的令牌未经授权

测试用例1.1：未经身份验证的请求（应失败）

# Make a request without authentication token
curl -X POST https://gateway.kind.cluster/mcp \
  -H 'Content-Type: application/json' \
  -d '{
    "method": "tools/call",
    "params": {
      "name": "k8s_list_resources",
      "arguments": {}
    }
  }'

预期结果：

• 状态： 401 Unauthorized
• 策略拒绝请求，因为不存在JWT令牌

测试用例1.2：具有授权组的有效令牌（应成功）

# Get token for alice (member of kube-dev group)
TOKEN=$(./get-token.sh alice)

# Make authenticated request
curl -X POST https://gateway.kind.cluster/mcp \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "method": "tools/call",
    "params": {
      "name": "k8s_list_resources",
      "arguments": {
        "namespace": "default"
      }
    }
  }'

预期结果：

• 状态： 200 OK
• 策略允许该请求，因为：

- 存在有效的JWT令牌 - 令牌已正确签名和验证 - 用户属于 kube-dev 组（允许组）

\[可选\]测试用例1.3：无效令牌（应失败）

# Make a request with an invalid token
curl -X POST https://gateway.kind.cluster/mcp \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer invalid-token-here' \
  -d '{
    "method": "tools/call",
    "params": {
      "name": "k8s_list_resources",
      "arguments": {}
    }
  }'

预期结果：

• 状态： 401 Unauthorized
• 策略拒绝请求，因为JWT令牌无效或无法解码

\[可选\]测试用例1.4：具有未经授权组的有效令牌（应失败）

# Get token for a user not in kube-dev or kube-admin groups
TOKEN=$(./get-token.sh unauthorized-user)

# Make authenticated request
curl -X POST https://gateway.kind.cluster/mcp \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "method": "tools/call",
    "params": {
      "name": "k8s_list_resources",
      "arguments": {}
    }
  }'

预期结果：

• 状态： 401 Unauthorized
• 策略拒绝请求，因为用户组不在允许的列表中

______________________________________________________________________

示例2：限制通过SAR从URL创建

此示例演示了 create-from-url-authz 使用Kubernetes主题访问审查（SAR）验证用户是否有权从URL创建资源的策略。

政策概述

这 create-from-url-authz 政策：

• 拦截MCP工具调用 k8s_create_resource_from_url
• 从MCP请求参数中提取命名空间和URL
• 从URL获取并解析Kubernetes清单
• 从清单中提取资源种类
• 创建主题访问审查（SAR），以检查用户是否可以在指定的命名空间中创建该资源类型
• 如果SAR拒绝操作，则返回403 Forbidden

测试用例2.1：授权创建操作（应成功）

# Get token for alice (has create permissions in dev namespace)
TOKEN=$(./get-token.sh alice)

# Create a deployment manifest URL (example)
MANIFEST_URL="https://raw.githubusercontent.com/example/deployment.yaml"

# Make authenticated request to create resource from URL
curl -X POST https://gateway.kind.cluster/mcp \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $TOKEN" \
  -d "{
    \"method\": \"tools/call\",
    \"params\": {
      \"name\": \"k8s_create_resource_from_url\",
      \"arguments\": {
        \"namespace\": \"dev-team\",
        \"url\": \"$MANIFEST_URL\"
      }
    }
  }"

预期结果：

• 状态： 200 OK
• 策略允许该请求，因为：

- 用户已通过身份验证（来自示例1） - SAR检查确认用户已 create 中资源类型的权限 dev-team 命名空间 - 资源创建成功

测试用例2.2：未经授权的创建操作（应失败）

# Get token for alice (does NOT have create permissions in production namespace)
TOKEN=$(./get-token.sh alice)

# Attempt to create resource in production namespace
MANIFEST_URL="https://raw.githubusercontent.com/example/deployment.yaml"

curl -X POST https://gateway.kind.cluster/mcp \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $TOKEN" \
  -d "{
    \"method\": \"tools/call\",
    \"params\": {
      \"name\": \"k8s_create_resource_from_url\",
      \"arguments\": {
        \"namespace\": \"production\",
        \"url\": \"$MANIFEST_URL\"
      }
    }
  }"

预期结果：

• 状态： 403 Forbidden
• 策略拒绝请求，原因如下：

- SAR检查失败-用户没有 create 资源许可 production 命名空间 - 资源创建被阻止

______________________________________________________________________

摘要

这些例子表明：

1. 身份验证强制：所有请求都必须包含来自Keycloak的有效JWT令牌，并且用户必须属于授权组。

1. 授权执行：即使有有效的身份验证，用户也只能执行他们授权的操作，并通过Kubernetes Subject Access Review进行验证。

1. 最小特权：基于Kubernetes RBAC，用户仅限于其分配的命名空间和资源类型。

1. 每用户责任：每个请求都与JWT令牌中的实际用户身份相关联，从而能够进行适当的审计跟踪。

1. 基于策略的护栏：Kyverno策略提供了基本RBAC之外的额外验证，允许复杂的业务规则。