澄潭

需求挺合理的，可以实现，我已经加上 help wanted 标签，看看有没有社区同学有兴趣认领

@hanxiantao 好的，钉钉上联系一下我吧，交流一下实现细节，这块功能需要在 https://github.com/alibaba/higress/tree/feat/istio-1.19.0 这个分支上做

@alexzzh 我们在controller SIG里一起讨论吧

https://github.com/alibaba/higress/blob/9c112a03db25f33f56dde3bc6019e335629955f1/pkg/ingress/kube/ingressv1/controller.go#L440 如上代码，机制上是可以支持的，这个需求也是合理的，一般ingress可能放在业务ns下给开发管理，secret更希望统一管理在系统ns下给运维统一管理。 Gateway API通过Gateway资源管理secret可以比较好解决这个问题，同时也支持了referenctGrant。 Ingress API要解决这个问题，直接让不同ns里的ingress跨ns使用secret不太合理，有安全隐患。 我们可以基于系统ns下的一份配置，来统一管理不同域名需要用到的证书，虽然底层也是跨ns引用secret，但ingress的创建者无法自己去配置secret，把权限收口在系统ns下。 这个 @2456868764 这边已经在开发能支持自动签发证书的管理工具，可以一并考虑在系统ns下全局配置证书的方式。例如可以对一个域名配置开启自动签发证书，或者对域名直接指定一个secret。

@2456868764 这个功能是ingress nginx的痛点，可以优先实现一下，你看是跟自动签发证书一起实现，还是先实现这个。

可以调整下 把对应端口开放出来，请@CH3CHO看下

> 现在有一个问题是 Gateway 的 15000 端口监听的是 127.0.0.1。按照 https://stackoverflow.com/questions/52513336/is-there-a-way-to-expose-a-docker-container-port-bound-to-127-0-0-1-to-host 的说法，这种端口是没法 expose 出来的。 > > 我们是否需要调整这一端口监听配置呢？ @johnlanni 这个不建议，有安全风险，那看来只能hgctl直接集成docker exec

@CH3CHO 这两个端口暴露也有安全风险，我建议还是统一通过docker exec来搞

@Fkbqf 可以先整理下实现思路，周会讨论下，不急着编码

@Fkbqf 你说的第一种CSRF防御方式跟OIDC本身没什么关系，这个是web业务自身防范要做的事情。OIDC容易被CSRF攻击主要在于使用code换取token的机制，可以被攻击者用于将自己的三方平台账号跟被攻击者的站点登陆账号关联，从而用自己的三方平台账号轻而易举地获取到用户在该站点的个人信息。可以参考这篇[文章](https://zq99299.github.io/note-book/oath2/02/02.html#csrf-%E6%94%BB%E5%87%BB)介绍的攻击方式，举了一个用攻击者的微信账号拿到被攻击者极客时间账号信息的例子。 要解决这个问题，本质就是要引入状态机制，你上面方案中的nonce方式是可行的，但是有两个问题： 1. 应该使用state参数而不是nonce参数，可以参考Auth0对这块的[state参数说明](https://auth0.com/docs/secure/attack-protection/state-parameters)，如果在Authorize阶段传递了state参数，那么后面通过code获取token阶段，也必须传正确的state参数，才能拿到token，Auth0，Keycloak等OIDC Provider都实现了这样的机制 2. state参数应该加签存储在cookie中，而不是直接在cookie中存储明文，这样可以防止state通过url参数被泄漏后，攻击者进行伪造