我的任务是将AWS Lambda微服务迁移到Kubernetes。为简单起见,有两个服务端点:/admin
和/user
,您可以在其中获取或发布请求以完成任务。
您必须处于admin
组(在外部authZ提供程序中定义)才能命中/admin
端点,否则,您将获得401。您必须处于user
组中才能有权访问/user
端点。
我将每个端点公开为在Docker容器中运行的服务。问题是-在Kubernetes中添加路由和基于路径的授权的正确方法是什么?
就像,如果我在浏览器中转到/admin
,我需要Kubernetes来检查我是否属于admin
组,然后将我路由到admin
服务;否则,它将返回401。
我可以自己编写该路由器,但是我想检查Kubernetes中是否有内置的解决方案。
答案 0 :(得分:1)
检查Kubernetes中是否有内置解决方案
不,没有针对L7网络策略的内置解决方案。 Kubernetes中的Network Policies处于L4级别,因此不可能进行速率限制,基于路径的防火墙规则等。尽管您可以研究诸如Linkerd,Istio之类的Service Mesh,甚至可以使用基于eBPF
的不同CNI插件,例如Cilium。
Cilium具有CRD CiliumNetworkPolicy
,可帮助您解决用例。如果要卸载身份验证/授权过程,可以在其前面放置任何代理(例如Nginx / Caddy / HAProxy)或API网关(例如Kong)。您可以应用以下网络策略,该策略将限制/admin
端点在任何标签为app: customapp
的容器上,并且只能从标签为app: proxyapp
的容器中使用。
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "allow-from-proxy"
specs:
- endpointSelector:
matchLabels:
app: customapp
ingress:
- fromEndpoints:
- matchLabels:
app: proxyapp
toPorts:
- ports:
- port: "8080"
protocol: "TCP"
rules:
http:
- method: "GET"
path: "/admin"
答案 1 :(得分:0)
您可以探索istio的流量管理。它们提供基于用户身份(https://istio.io/docs/tasks/traffic-management/request-routing/#route-based-on-user-identity)的路由。但是他们通过从请求标头中找到用户来做到这一点。如果您有管理员组,则不确定是否可以按原样使用。
虚拟服务示例:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
...
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
可以使用istio网关从群集外部访问上述服务。