实现keycloak实现istio的rbac

envoy rbac介绍

基于角色的访问控制(RBAC)为服务提供服务级别和方法级别的访问控制。RBAC政策是附加的。依次检查策略。根据操作以及是否找到匹配的策略,允许或拒绝请求。

策略配置主要包括两个部分。

  • permissions

由AuthorizationPolicy中to转换过来

定义角色的权限集.每个权限都与OR语义匹配.为了匹配此策略的所有操作,应使用any字段设置为true的单个Permission。
  • principals

由AuthorizationPolicy中to和when字段转换过来

根据操作分配/拒绝角色的主体集.每个主体都与OR语义匹配.为了匹配此策略的所有下游,应使用any字段设置为true的单个Principal。

本文将基于istio和keyclock应用envoy的rbac策略,实现基于jwt的权限控制。

启动keycloak

docker run -d  -p 8443:8443 -p 80:8080 -e PROXY_ADDRESS_FORWARDING=true  -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:11.0.0

配置keycloak

创建istioclient

创建clientrole

分配role

创建rolemapper,如果不创建信息会保存在resource_access.istio.roles,但是istio的jwt auth无法获取子路径下的信息,需要将信息映射出来

安装服务

为ingressgate配置认证策略

为服务httpbin创建Gateway

创建vs

应用授权策略,只有通过认证的服务才能访问

测试访问

获取token

http://127.0.0.1:5556/dex/token -d "client_id=istio" -d "response_type=code token" -d "grant_type=password" -d "username=admin" -d "password=admin" -d "scope=openid"

可以正常访问

使用jwt对特定路径进行认证授权

应用以下策略在GET/POST时判断headers时验证客户端是否具有fuckistio角色,

验证

尝试请求/headers POST method,可以访问,但是需要添加token

get /headers 无需认证即可访问

ip 接口无需认证即可使用访问任意方法访问

总结

使用keycloak结合istio可以实现细粒度的认证授权策略,客户端只需要到认证授权中心获取token,服务端无需关心任何认证授权细节,专注以业务实现,实现业务逻辑与基础设施的解耦

参考:

扫描关注我:

微信

Last updated

Was this helpful?