KubeCon + CloudNativeCon Japan 2026 举办前夕，KeycloakCon Japan 将于 7 月 28 日 09:00 至 12:30 在横滨举行。活动标题把两个正在快速交汇的方向放在了一起：云原生身份管理，以及 AI 带来的新型身份与授权问题。来源摘要没有披露具体议程和讲者，因此更值得提前梳理的是：开发团队应该带着哪些工程问题进入这场讨论。
身份系统进入 Kubernetes 后，难点不只是部署
把 Keycloak 放进 Kubernetes，创建 Deployment 和 Service 并不困难。真正影响生产可用性的，是身份系统本身的状态、密钥和升级约束。
需要重点检查这些问题：
- Keycloak 实例是否无状态，数据库是否由独立、高可用的服务承载。
- Realm、Client、Role 等配置如何进入版本控制，并在环境之间迁移。
- 管理员凭据、客户端密钥和签名材料是否由 Secret 管理系统托管。
- Pod 滚动升级时，登录流程和已有会话会受到什么影响。
- 外部域名、代理转发头、TLS 终止位置是否与回调地址一致。
- 指标、日志和审计事件能否回答“谁在何时访问了什么”。
身份服务位于几乎所有业务请求的入口处。普通应用短暂不可用，影响一个功能；身份服务不可用，则可能同时阻断控制台、API 和自动化任务。因此，Keycloak 的容量测试、备份恢复和升级演练应该被视为平台工程的一部分。
可以这样实践：在本地 Kubernetes 验证 OIDC 链路
下面是一个最小实验环境，适合验证 Kubernetes 网络、OIDC Discovery 和令牌签发流程。它使用 start-dev 和临时管理员密码，只适用于本地测试，不能直接作为生产配置。
将以下内容保存为 keycloak-dev.yaml，或者直接通过标准输入执行：
apiVersion: v1
kind: Namespace
metadata:
name: identity-lab
---
apiVersion: v1
kind: Secret
metadata:
name: keycloak-bootstrap
namespace: identity-lab
type: Opaque
stringData:
username: admin
password: change-me-now
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: keycloak
namespace: identity-lab
spec:
replicas: 1
selector:
matchLabels:
app: keycloak
template:
metadata:
labels:
app: keycloak
spec:
containers:
- name: keycloak
image: quay.io/keycloak/keycloak:latest
args: ["start-dev"]
env:
- name: KC_BOOTSTRAP_ADMIN_USERNAME
valueFrom:
secretKeyRef:
name: keycloak-bootstrap
key: username
- name: KC_BOOTSTRAP_ADMIN_PASSWORD
valueFrom:
secretKeyRef:
name: keycloak-bootstrap
key: password
ports:
- name: http
containerPort: 8080
readinessProbe:
tcpSocket:
port: http
initialDelaySeconds: 20
periodSeconds: 5
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: "1"
memory: 1Gi
---
apiVersion: v1
kind: Service
metadata:
name: keycloak
namespace: identity-lab
spec:
selector:
app: keycloak
ports:
- name: http
port: 8080
targetPort: http
执行部署并等待 Pod 就绪：
kubectl apply -f keycloak-dev.yaml
kubectl -n identity-lab rollout status deployment/keycloak
kubectl -n identity-lab port-forward service/keycloak 8080:8080
保持端口转发运行，再打开另一个终端检查 OpenID Connect 元数据：
curl --fail --silent \
http://127.0.0.1:8080/realms/master/.well-known/openid-configuration
这个实验只证明基础链路可以工作。进入生产前，应固定镜像版本，接入外部数据库和密钥管理系统，配置 TLS、主机名与代理模式，并使用 HTTP 级健康检查替代简单的 TCP 探测。
AI Agent 让“用户身份”变成复合问题
传统 Web 应用通常围绕两类主体设计：人类用户和服务账号。AI Agent 会把边界变得更复杂。一次操作可能同时涉及登录用户、Agent 运行时、模型供应商、工具服务，以及由 Agent 临时启动的子任务。
这时，仅仅知道“令牌有效”并不足够。系统还需要回答：
- Agent 是代表哪位用户执行操作，还是使用自身的机器身份。
- 用户授权是否能够传递给下游工具，传递范围有多大。
- Agent 能否读取令牌、刷新令牌或客户端密钥。
- 一个用于查询日历的权限，是否被复用于发送邮件或修改文件。
- Prompt injection 诱导 Agent 调用工具时，授权层能否阻止越权操作。
- 审计日志能否区分用户意图、Agent 决策和工具执行结果。
一个可行的设计原则是：模型负责提出工具调用建议，确定性的授权组件负责批准或拒绝。不要让模型生成角色名、扩大 scope，或者自行决定访问控制结果。
下面是一个可改造的 Agent 工具授权伪项目。假设上游网关已经验证 OIDC 令牌，并把可信 claims 传给工具服务：
from dataclasses import dataclass
@dataclass(frozen=True)
class Identity:
subject: str
scopes: frozenset[str]
actor: str | None = None
TOOL_SCOPES = {
"calendar.read": "calendar:read",
"calendar.write": "calendar:write",
"email.send": "email:send",
}
def authorize_tool(identity: Identity, tool_name: str) -> None:
required_scope = TOOL_SCOPES.get(tool_name)
if required_scope is None:
raise PermissionError("unknown tool")
if required_scope not in identity.scopes:
raise PermissionError(f"missing scope: {required_scope}")
identity = Identity(
subject="user-123",
actor="agent-runtime",
scopes=frozenset({"calendar:read"}),
)
authorize_tool(identity, "calendar.read")
print("allowed: calendar.read")
try:
authorize_tool(identity, "email.send")
except PermissionError as exc:
print(f"denied: {exc}")
实际服务中，subject、actor 和 scopes 必须来自经过签名验证的令牌或可信网关，不能接受模型输出或普通请求头直接赋值。高风险工具还应加入资源级权限、人工确认、调用次数限制和完整审计记录。
参会或评估技术时，带上可验证的问题
围绕云原生身份与 AI，抽象概念很容易掩盖运行时细节。评估 Keycloak 相关方案时，可以使用下面这份清单：
- 是否展示过多副本、数据库故障和滚动升级条件下的行为。
- Realm 与 Client 配置是否能审查、回滚和自动部署。
- 工作负载身份与终端用户身份是否采用不同生命周期。
- Token Exchange、委托访问或机器身份是否限制了 audience 和 scope。
- AI Agent 调用工具时，授权判断是否独立于模型。
- 是否记录用户、Agent、令牌主体、工具、资源和决策结果。
- 密钥轮换后，旧令牌、缓存和下游服务会如何响应。
KeycloakCon Japan 2026 的意义，不只在于讨论如何运行一个身份服务器。更现实的问题是：当 Kubernetes 承载越来越多服务、AI Agent 开始代表用户采取行动时，平台能否清楚地证明每一次访问是谁发起、代表谁、被授予了什么，以及为什么被允许。