Feast项目权限系统升级：支持多名称模式匹配

在Feast项目的权限控制系统中，开发团队正在对RBAC（基于角色的访问控制）功能进行重要升级。本次升级的核心内容是扩展权限规则中的资源名称匹配机制，从单一模式匹配提升为支持多模式匹配，这将显著提升权限配置的灵活性和便利性。

当前权限系统的局限性

目前Feast的权限配置中，每个Permission对象只能指定一个name_pattern正则表达式来匹配资源名称。例如，要控制对特征视图（FeatureView）的访问权限，开发者需要这样配置：

Permission(
    name="reader",
    types=[FeatureView],
    name_pattern=".*risky.*",
    policy=RoleBasedPolicy(roles=["trusted"]),
    actions=[AuthzedAction.QUERY_OFFLINE],
)

这种设计存在明显不足：当需要为多个不同命名模式的资源设置相同权限时，开发者不得不创建多个几乎相同的Permission对象，导致配置冗余和维护困难。

新方案的技术实现

升级后的权限系统将引入name_patterns（复数形式）字段，支持传入一个正则表达式列表。系统会检查资源名称是否匹配列表中的任意一个模式，从而实现"或"逻辑的匹配规则。新的配置方式如下：

Permission(
    name="reader",
    types=[FeatureView],
    name_patterns=[".*risky.*", "critical_data"],
    policy=RoleBasedPolicy(roles=["trusted"]),
    actions=[AuthzedAction.QUERY_OFFLINE],
)

这一改进具有以下技术优势：

1. 配置简化：单个Permission对象即可覆盖多个命名模式的资源
2. 逻辑清晰：避免了创建多个相似权限规则带来的混淆
3. 维护便利：修改权限时只需调整一个配置项

向后兼容性考虑

由于Feast的RBAC功能尚未正式发布，开发团队决定直接使用name_patterns作为新字段名，而不是保留原有的name_pattern字段。这种设计选择避免了未来可能出现的兼容性问题，同时也使API命名更加准确反映其功能。

应用场景示例

假设一个金融机构使用Feast管理其机器学习特征，可能需要为以下敏感数据设置特殊访问权限：

• 包含"risk"字样的风险模型特征
• 名为"customer_credit_score"的信用评分特征
• 前缀为"fraud_"的欺诈检测特征

旧方案需要创建三个独立权限规则，而新方案只需一个配置即可覆盖所有情况：

Permission(
    name="sensitive_data_access",
    types=[FeatureView],
    name_patterns=[".*risk.*", "customer_credit_score", "fraud_.*"],
    policy=RoleBasedPolicy(roles=["senior_analyst"]),
    actions=[AuthzedAction.QUERY_OFFLINE, AuthzedAction.QUERY_ONLINE],
)

技术实现细节

在底层实现上，系统会将多个正则表达式编译成模式对象，并在检查权限时依次尝试匹配。为提高性能，可以考虑以下优化策略：

1. 对频繁使用的模式进行缓存
2. 实现短路逻辑：任一模式匹配成功即返回
3. 对固定字符串模式使用直接比较而非正则匹配

这一改进体现了Feast项目对开发者体验的持续关注，通过简化配置逻辑来降低使用门槛，同时保持系统的灵活性和强大功能。随着机器学习在企业中的普及，这种细粒度的权限控制将变得越来越重要。