如果使用higress，对外暴露多个端口(listener),每个listener进行不同的[证书]配置。 about higress

[alexzzh]

good news！！！

我这边测试了envoy的ingress-gateway crd的效果，发现其支持配置多个端口。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
    tls:
      httpsRedirect: true
  - port:
      number: 443
      name: https-443
      protocol: HTTPS
    hosts:
    - "*"
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key

higress 既然全面兼容istio的crd, 那是不是意味着我们可以在higress的部署环境下，使用istio的 ingress-gateway来解决我们的需求，经过测试，确实可以，但需要调整上述资源文件的2处配置:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    higress: higress-system-higress-gateway ===> 1
  servers:
  - port:
      number: 11111
      name: http
      protocol: HTTP
    hosts:
    - "*"
  - port:
      number: 443
      name: https-443
      protocol: HTTPS
    hosts:
    - "*"
    tls:
      mode: PASSTHROUGH
  - port:
      number: 22222
      name: https-22222
      protocol: HTTPS
    hosts:
    - "*"
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt. =====> 2
      privateKey: /etc/istio/ingressgateway-certs/tls.key

• 针对这2处配置，想问下理解是否有误:

  • 问题1: 针对第1点配置调整， 需要将原来的istio: ingressgateway 调整为 higress: higress-system-higress-gateway, 因为只有这样才能match到higress的gateway pod？
  • 问题2:针对第2点配置调整， istio的gateway crd会通过 serverCertificate、privateKey来指定证书在gateway pod内部的文件路径，这些文件是通过创建指定名称(ingressgateway-certs)的secret来自动加载的， 但目前的higress的gateway pod肯定没有这套逻辑(目前虽然也是通过secret，但不会在pod内存放证书文件，而是直接转成加密的配置内容)， 所以证书如何配置还是一个问题，当然属于小问题。

  问题3: istio 提供了 apiVersion: networking.istio.io/v1beta1 的 Gateway crd ，能做到同时配置多个端口，可以配合istio其他crd 一起使用，比如virtual service 、destnationrule等，同时也支持了传统意义上的apiVersion: gateway.networking.k8s.io/v1alpha2 的 gateway api ，可以配合http-route crd使用。 我看higress其实也支持传统意义gateway api，但不辛的是gateway api在我们的应用场景下，还需要考虑如何结合istio的envoy filter实现ext_authz、如何控制wasm plugin外挂插件作用在http-route上等一系列问题，相关问题已在其他issue提到，所以，gateway api对于我们来说也不是一个好的解决方案，所以要是higress也能提供类似istio的Gateway crd就好了，这样遇到我们这样的需求将迎刃而解，也不用考虑使用istio的Gateway crd，也不排除未来其他企业也会遇到类似需求， 当然我这么理解不一定对哈。

  问题4: 目前来看，使用istio的Gateway crd虽然需要做些调整，但好在可以解决我们的场景，但引出另一个延伸点: 我们这样做，是否还可以运用higress可以对接多种注册中心的优势，理论上应该可以。

  问题5: 对于我们来说，独立部署也是刚需，技术选型是也是重要考量点，我们了解像hango、contour、istio以及刚"出生"的gateway-api目前都无法standalone部署，higress的standalone在这块绝对是优势，至少国内大部分厂商都没有做到完全k8s化，这块的市场空间还是有的，所以standalone的mock api-server接下来是否可以适配下istio的crd, 我想即便现在没有像我们这样的需求，将来肯定也会有场景需要在standalone模式下使用istio的其他crd。

  作为刚刚接触higress以及istio的初学者来说，问的问题可以比较低级，请多包涵，期待老师的回答，感谢。

[johnlanni]

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    higress: higress-system-higress-gateway ===> 1
  servers:
  - port:
      number: 11111
      name: http
      protocol: HTTP
    hosts:
    - "*"
  - port:
      number: 443
      name: https-443
      protocol: HTTPS
    hosts:
    - "*"
    tls:
      mode: PASSTHROUGH
  - port:
      number: 22222
      name: https-22222
      protocol: HTTPS
    hosts:
    - "*"
    tls:
      mode: SIMPLE
      credential_name: "mysecret"

第二个问题，使用这个credential_name就可以，standalone下后续也可以支持

[alexzzh]

但使用gateway api虽然能同时对外监听多个端口，还存在一个比较别扭的点: 如果我们的业务经常会增加不同的监听端口，那对于higress来说，不仅仅要调整kind: Gateway 资源内的port， 还要同步调整 higress-gateway service的port，相当于要调整2处

--- 针对这点，zty已反馈: 后面可以通过工具做自动化管理 现在是得先调整svc

[johnlanni]

ingress 可以用这个注解来开启mtls：higress.io/auth-tls-secret
例如:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # 这里的要求是必须以域名上配置证书secret名称后缀加上-cacert
    higress.io/auth-tls-secret: tls-secret-cacert
  name: bar
  namespace: default
spec:
  ingressClassName: higress
  rules:
  - host: bar.com
    http:
      paths:
      - backend:
          service:
            name: bar-service
            port:
              number: 5678
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - bar.com
    secretName: tls-secret
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: foo
  namespace: default
spec:
  ingressClassName: higress
  rules:
  - host: foo.com
    http:
      paths:
      - backend:
          service:
            name: foo-service
            port:
              number: 5678
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - foo.com
    secretName: tls-secret

tls-secret-cacert 这个 secret 的内容中必须有 cacert 这个key，例如：

apiVersion: v1
data:
  cacert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURDekNDQWZPZ0F3SUJBZ0lVQ0tMSGM5SFhBbEFYNUdFR2dHVk1zVXhzUFhBd0RRWUpLb1pJaHZjTkFRRUwKQlFBd0ZURVRNQkVHQTFVRUF3d0tSWGhoYlhCc1pTQkRRVEFlRncweU16RXlNakl3T1RNek1ESmFGdzB5TkRFeQpNakV3T1RNek1ESmFNQlV4RXpBUkJnTlZCQU1NQ2tWNFlXMXdiR1VnUTBFd2dnRWlNQTBHQ1NxR1NJYjNEUUVCCkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDaW1jaWQ4VWx4VzA4a1RTcmc1UnAzTlMvSmFMQWt3bVZzeWdEanc0TUEKSjh6Q2FWWHFmU2xpbCtTRFdLcllRYUtPQ1JRWjlWdXBwODl4UnRJTkpUVmlBZUpHYzh6SDY2Sy82aUZJZ2N4ZQplczVaaDdqQXdENzZ4eEtMUjJPbkRSb0xpVlFVOGxkekVNclVHRytCOXJ1TzFsNjkxNlRjQ0dqS3VGUklQNzJCCjlJcEI0ekxZUUNLWldmZ1cxVmU0alpYTUZ0MVhUc0dWdkhCaEt0MSt5eXMrNnc3WndxMW43NysxdXcya2dmM3cKaXNCbXBzTlRPVVJSZzVvdEdYVUUxaGl3dC9KeW9PQkt1YmVyY2dwd05OYzAvNHZ6eWRHMm83UFFpTHcyallPbwppbFptYUZzVXEyclU4S0hCdWlSbVkyTXlOWEU2R0liY29sVGZRQWM2NE5EWEFnTUJBQUdqVXpCUk1CMEdBMVVkCkRnUVdCQlNOZC9vYTkyemFGWFNaRVJoRXJMSElqRE8zYWpBZkJnTlZIU01FR0RBV2dCU05kL29hOTJ6YUZYU1oKRVJoRXJMSElqRE8zYWpBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFBTwpjMDNIYWFDRHhhR0phdzlrYkJxMW1DbUVvR3pWZ0loYkhveTQ0Q0IxbGpnS0xOWHo2bnZ5bDVCdWRzWXJkT1lXCmJMMEJGdGxLbWRqeUFHemtnOThGSkpVNExTVFM1ZDNySlBkQU1lcXFOQ2R5NVh0c2l2VDlIbzh5QVBiUGFmZlkKTmozN29JVEQrdXhQbTNVMGhOTU5YSGdGdnJ4bGV6U2MyOHFWL1VxVDBWcnNJR3IyblNiaEYrR3g1WS92aTZocQp5RTJsYWJXdDQ3VlBYcTNFL2lHRWhTSmFndTdhN2xBSDhYWWlqMUtCMkU4bjlERy80R2ZDMEVpTnNXbUpzWVNjCk9tdXlmRGpXaHQ2LzlUVkh4YkNZMzZGQ08vOTcraThqUGhxVlkxRlJzUG5WRUtiRXBNemdXb3Y0UXNKeHoxS3gKdHN2eHlVRnJsaU5wUk1OQmVEODIKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
kind: Secret
metadata:
  name: tls-secret-cacert
  namespace: default
type: Opaque

[alexzzh]

感谢您的回复，了解了ingress如何设置mtls.

不过，我们的业务场景，不仅仅是mtls的问题，更多的是针对同一个listener，比如443端口的listener，从envoy底层就无法同时支持双向认证和单向认证两种配置，如下

• 针对4005某个listener设置单向认证

- "@type": type.googleapis.com/envoy.config.listener.v3.Listener
  name: double-v4
  address:
    socket_address: { address: 0.0.0.0, port_value: 4005} #监听地址   
    。。。 
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
        require_client_certificate: true #强制认证
        session_timeout: 7200s
        common_tls_context:
          alpn_protocols: ["http/1.1"] 
          tls_params:
             tls_minimum_protocol_version: TLSv1_1
             tls_maximum_protocol_version: TLSv1_2
          tls_certificate_sds_secret_configs: 
            name: sds-double
            sds_config:
              path: /config/sds-double.yaml
          validation_context_sds_secret_config: #指定证书验证上下文，xds方式加载
            name: sds-validation
            sds_config:
              path: /config/sds-validation.yaml

• 针对4006端口的listener设置双向认证

- "@type": type.googleapis.com/envoy.config.listener.v3.Listener
  name: double-v4
  address:
    socket_address: { address: 0.0.0.0, port_value: 4006} #监听地址   
    。。。 
   transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
        require_client_certificate: false #非强制认证
        session_timeout: 7200s
        common_tls_context:
          alpn_protocols: ["http/1.1"]
          tls_params:
            tls_minimum_protocol_version: TLSv1_1
            tls_maximum_protocol_version: TLSv1_2
          tls_certificate_sds_secret_configs:
            name: sds-single
            sds_config:
              path: /config/sds-single.yaml

因为envoy的单向和双向证书配置(包括 require_client_certificate 和 validation_context_sds_secret_config) 内容是互斥的， 所以我们需要同时监听多个端口，每个端口要么设置单向认证，要么设置双向认证， 而ingress好像不能暴露多个端口，所以此时gateway api 显得更加match，如下：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: higress-gateway
  namespace: higress-system
spec:
  gatewayClassName: higress-gateway
  listeners:
 - name: 单向
    port: 4005
    protocol: HTTPS
    allowedRoutes:
      namespaces:
        from: All
    tls:
      certificateRefs:
      - kind: Secret
        name: wildcard-foobar-com
  - name: 双向
    port: 4006
    protocol: HTTPS
    allowedRoutes:
      namespaces:
        from: All
    tls:
      certificateRefs:
      - kind: Secret
        name: wildcard-foobar-com

但是，higress对于gateway api的支持目前肯定没有ingress全，所以想知道ingress针对此场景有否有解决方案?

[johnlanni]

envoy是支持的，listener里可以有多个filter chain，匹配不同的sni决定要不要开mtls，我上面给的ingress的例子就是443端口下bar.com开启mtls，foo.com只是单向认证

[alexzzh]

envoy是支持的，listener里可以有多个filter chain，匹配不同的sni决定要不要开mtls，我上面给的ingress的例子就是443端口下bar.com开启mtls，foo.com只是单向认证

还有一个关键点: 就是我们的客户端是sdk ，不是浏览器，而且我们无法控制客户端访问服务端时的传递的sni(实际现在传的都是服务端对外的ip地址)，所以服务端无法使用sni多域名方式区分不同的virtual host，也就是说当前服务端的domain都配置的*.
这也是为什么之前提过一个feature(在刚发布的1.3.5上已经支持): 在https下可以配置域名为*。

所以基于这个前提，ingress 有否有解决方案？

[alexzzh]

higress ingress为什么不能像istio的ingress-gateway(注意:这里指的不是gateway api)那样配置同时监听多个端口? 如果可以的话，那就太好了。

[johnlanni]

主要是ingress没有这样的规范，你的这个需求确实目前只能基于Gateway API来做

[alexzzh]

主要是ingress没有这样的规范，你的这个需求确实目前只能基于Gateway API来做

好的