@HALOZ 中转的消费

@zed1018 好吧 这个 bug 真的有点烦

@shitshit666 我也在问 这个问题好讨厌

@milesbai6022 他们指的是的 DE 支持太差，做 GPU 运算又不需要 DE

@sunzhenyucn typo error, Ultra haha

This is what i wanted now, already purchase Urltra subscription!!!

@veotax ？这是一个东西吗？别瞎推广行吗？

not impressed, 从 4.0 版本开始就料到迟早会进行闭源的, 4.0 的整体架构设计在商业层面就是为了进一步商业化推进

@Aether sorry, 这个确实是我的 wx ，但是不知为何您无法找到，您可以尝试通过 MTc2MjEyMjYzNzE=这个号码找到我

哇 连个回复都没有 我已经退坏境了吗 :(

run

@sunzhenyucn 这里最重要的、具有挑战性的是如何配合智库团队理解他们的工作思维和方式，将其“教”给模型，反而技术层面都是次要的了

不少都是在圈地自萌，没有需求凭拍脑袋造需求。
我这里倒是最近 focus 在一个比较具有挑战性的需求上：
结合当地智库团队的思维能力和经验，将其固化给模型，并配合自建的工具或自托管 MCP Server ，结合将智库近年来的一些知识文档和互联网搜索能力实现 Deep Research ，为智库编写内参或研究报告提供生成工具，最终在软件形态上会是一个 MAS

Wiz 的报告我也看了，虽说前面的层主有提到过确实有安全大佬在幻方，但依照结果来看确实有些地方犯了一些本不应该去犯的错误

Ingress, Ingress 不只是为 http 类端口服务的, 你像 APISIX 就提供了 Stream Proxy 来帮助代理基于 TCP 或 UDP 协议的面向流式的流量, 不过这并不是一个银弹, 适用场景可以参考官方文档。

P.S. 无利益相关

@qiujianzhong 正在准备，准备好之后发给您

@COW 因为我们使用 IAM 的目的是为我们自己的应用云平台上的所有 SaaS 或 On-Permis 应用提供统一的认证和鉴权框架，包括我们自己的应用云平台上的 Open API 类产品也是托管在我们平台上进行认证和鉴权的，这种场景的细粒度授权 RBAC 不合适所以我们自己基于 Keycloak 封装了一套 PBAC

1. 关于你说的利用 LDAP 集成，这边建议是统一采用泛用性更强的 OIDC 协议
2. Keycloak 的 Audit 和其他系统的 Audit 并不相同，Keycloak 的 Audit 更关注的是认证与授权事件的审计，而类似于 Jenkins 等系统的审计更关注的是系统本身的业务操作审计
3. Keycloak 的角色权限较为复杂，Authorization 功能也仅限于 OIDC 协议使用，如果需要做集成的话可能需要对客户端（类似但不限于 Jenkins 、Gitea 等）做二次开发才能够实现

P.S. 我们对于 Keycloak 的 Authorization 等概念做了一些更高层的抽象，并且我们的鉴权模型为 PBAC ，我们的做法是通过开发 Keycloak 插件将 Authorization 内的一些概念类似但不限于 Permission, Scope, Resource 等与 PBAC 中的概念做了一一映射。

我们在用它搭建企业内的 IAM ，你的问题是什么呢？