Kubernetes中基于路径的微服务授权 [英] Path-based authorization for microservices in kubernetes

问题描述

我的任务是将AWS lambda微服务迁移到Kubernetes。为简单起见，有两个服务端点：/admin和/user，您可以在其中获取或发布完成某件事的请求。

您必须属于admin组(在外部AuthZ提供程序中定义)才能达到/admin终结点，否则将获得401。您必须属于user组才能访问/user终结点。

我将每个端点公开为在停靠容器中运行的服务。问题是，在Kubernetes中添加路由和基于路径的授权的正确方式是什么？

比如，如果我在浏览器中进入/admin，我需要Kubernetes检查我是否在admin群中，然后将我路由到admin服务；否则，它应该返回401。

我可以自己编写此路由器，但我想检查Kubernetes中是否有内置的解决方案。

推荐答案

检查Kubernetes中是否有内置解决方案

不，没有针对L7网络策略的内置解决方案。Network Policies在Kubernetes中是L4级别的，因此不可能进行速率限制、基于路径的防火墙规则等。虽然您可以研究服务网格，如Linkerd、Istio，甚至使用基于eBPF的不同CNI插件，如Cilium。

纤毛有CRDCiliumNetworkPolicy，这将帮助您的用例。如果您想要卸载身份验证/授权过程，您可以在前面放置任何代理，如nginx/Caddy/HAProxy或像Kong这样的API Gateway。您可以应用以下网络策略，这将限制标签为app: customapp的任何Pod上的/admin终结点，并且只允许来自标签为app: proxyapp的Pod。

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"

这篇关于Kubernetes中基于路径的微服务授权的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！