istio external auth 观察

问题

想明白平台中的 external auth

related files

InstallationYTung/manifests/infra-charts/istio-controller/templates/configmap.yaml

    {{- if .Values.global.enableExtAuthz }}
    extensionProviders:
    - name: "aaa-authz-grpc"
      envoyExtAuthzGrpc:
        service: "pch-bff-pipeline.apulis.svc.cluster.local"
        port: "9000"
        includeHeadersInCheck: ["Authorization"]
    {{- end }}

InstallationYTung/manifests/infra-charts/istio-controller/templates/authz-grpc.yaml

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: aaa-grpc
  namespace: istio-system
spec:
  action: CUSTOM
  provider:
    # The provider name must match the extension provider defined in the mesh config.
    name: aaa-authz-grpc
  rules:
  - when:
    - key: request.headers[From]
      values: ["fronted"]
    to:
    - operation:
        paths: ["/api/v1*"]

background

https://istio.io/latest/blog/2021/better-external-authz/

remark: well-written

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ext_authz_filter#arch-overview-ext-authz

The External authorization filter calls an authorization service to check if the incoming request is authorized or not. The filter can be either configured as a network filter, or as a HTTP filter or both. If the request is deemed unauthorized by the network filter then the connection will be closed. If the request is deemed unauthorized at the HTTP filter the request will be denied with 403 (Forbidden) response. The external authorization service cluster may be either statically configured or configured via the Cluster Discovery Service. If the external service is not available when a request comes in then whether the request is authorized or not is defined by the configuration setting of failure_mode_allow configuration in the applicable network filter or HTTP filter. If it is set to true then the request will be permitted (fail open) otherwise it will be denied. The default setting is false.

envoy: from https://blog.csdn.net/gengzhikui1992/article/details/117449972

3.3 Envoy API xDS常用术语
Host(主机): 一个具有网络通信能力的端点
Cluster(集群): 集群是Envoy连接到一个逻辑上相似的端点;在v2中,RDS通过路由指向集群,CDS提供集群配置,而Envoy通过EDS发现集群成员,即端点.
Downstream下游: 下游主机连接到Envoy,发送请求并响应,它们是Envoy的客户端.
Upstream上游: 上游主机接收来自Envoy的连接和请求并返回响应,它们是Envoy代理的后端服务器.
Endpoint端点: 即上游主机,是一个或多个集群的成员,可通过EDS发现
Listener侦听器: 是能够由下游客户端连接的命名网络位置.如:端口,unix套接字等
Locality位置: 上游端点运行的区域拓扑,包括地域,区域和子区域等
Management Server管理服务器: 实现v2 API的服务器,它支持复制和分片,并且能够在不同的物理机上实现针对不同xDS API的API服务
Region地域: 区域所属地理位置
Zone区域: AWS中的可用区AZ或GCP中的区域等
Sub Zone子区域: Envoy实例或端点运行的区域内的位置,用于支持区域内的多个负载均衡目标
xDS: CDS,EDS,HDS,LDS,RLS,RDS,SDS,VHDS,RTDS等API的同城
Mesh和Envoy Mesh

Front Proxy访问单个Service: Envoy访问ServiceA的边车的Ingress Listener,Sidecar将请求转发给ServiceA.

访问调用其他Service的Service: Envoy访问Ingress,Ingress将请求转给ServiceA,ServiceA对ServicerB有请求,ServiceA通过Egress Listener将请求正向代理到ServiceB的Ingress Listener,再有Ingress 将求情反向代理给ServiceB

访问有外部调用的Service: Envoy访问Ingress,Ingress将请求转给ServiceA,ServiceA对外部(External Service)有请求,ServiceA通过Egress Listener将请求正向代理到Egress网关,再有Egress网关转发到外部,并由外部的External Service进行应答响应

4.2.3 Cluster如何发现Endpoint
Static 通过静态配置直接给定IP和Port
给定的是主机名称和端口,借助于DNS来将主机名称转成IP,一个主机名可以对应多个ip,ip与port的组合就是一个Endpoint
Strict DNS,严格DNS: 一个名称只会解析到有限个数的IP地址上.会把DNS解析结果中的所有ip配置为一个Endpoint
Logical DNS,逻辑DNS: 解析到不确定个数的地址.仅把DNS解析结果中的第一个IP配置为一个Endpoint
EDS: 通过基于GRPC和REST-JSON API的xDS管理服务器获取收集群成员的服务发现方式:
Original destination : 当传入连接通过iptables的REDIRRECT或TPROXY target或使用代理协议重定向到Envoy时,可以使用原始目标集群;
Custom cluster: Envoy还支持在集群配置上的cluster_type字段中指定使用自定义集群发现机制

https://blog.csdn.net/qq_29974229/article/details/127012006

One thing puzzled me. How do people find out how to implement an EDS? The answer may lie here:

Endpoint discovery service (EDS)

The endpoint discovery service is a xDS management server based on gRPC or REST-JSON API server used by Envoy to fetch cluster members. The cluster members are called “endpoint” in Envoy terminology. For each cluster, Envoy fetch the endpoints from the discovery service. EDS is the preferred service discovery mechanism for a few reasons:

Envoy has explicit knowledge of each upstream host (vs. routing through a DNS resolved load balancer) and can make more intelligent load balancing decisions.

Extra attributes carried in the discovery API response for each host inform Envoy of the host’s load balancing weight, canary status, zone, etc. These additional attributes are used globally by the Envoy mesh during load balancing, statistic gathering, etc.

The Envoy project provides reference gRPC implementations of EDS and other discovery services in both Java and Go.

NOTE! Reference implementations! In Java and Go.

It also occurs to me that, some if not many blogs might just be translating stuff of official documentation, and they transate just so so, if not badly.

And, our iam.ExtAuthzServerV3, is implementing AuthorizationServer. which dwelves in envoy/service/auth/v3/external_auth.pb.go, of the reference Go project exactly.

On further thought, the reference Go project might not be the canonical source -- maybe we should import other packages?

As the comment show(see below), maybe, we are entitled to generate pb.go by ourselves and include the generated files in our own projects.

// Code generated by protoc-gen-go. DO NOT EDIT.
// versions:
// 	protoc-gen-go v1.25.0
// 	protoc        v3.19.1
// source: envoy/service/auth/v3/external_auth.proto

So, here, we get an extensible system at work.

Maybe we can reflect upon the design of our pipeline a bit. I am still not sure how guys from other companies can implement componets and then incorporate them into our pipeline without a compilation. Maybe, it is me who is wrong?

GitLab