kubernetes中基于路径的微服务授权

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

您必须在外部authZ提供程序中定义的管理组中才能命中/admin端点，否则，您将得到401。您必须在用户组中才能访问/user端点

我将把每个端点公开为一个在docker容器中运行的服务。问题是-在Kubernetes中添加路由和基于路径的授权的正确方法是什么

比如，如果我在浏览器中转到/admin，我需要Kubernetes检查我是否在admin组中，然后将我发送到admin服务；否则，它应该返回401

---

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

您可以探索istio的流量管理。它们提供基于用户身份的路由。但他们通过从请求头中查找用户来实现这一点。如果您有一个管理组，则不确定该组是否可以按原样使用

虚拟服务示例：

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网关从集群外部访问上述服务

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

不，L7网络策略没有内置的解决方案。在Kubernetes中是L4级别的，所以速率限制、基于路径的防火墙规则等都是不可能的。尽管您可以查看服务网格，例如，或者甚至使用基于eBPF的不同CNI插件，例如

Cilium有一个CRD CiliumNetworkPolicy，它将帮助您处理用例。如果您想减轻身份验证/授权过程的负担，您可以将任何代理（如Nginx/Caddy/HAProxy）或API网关（如Kong）放在它前面。您可以应用以下网络策略，这将限制标签为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"