如何在RunDeck ACL中配置‘除view外全部拒绝’的快捷规则？

好问题！这种场景确实很常见——既要锁定特定作业只能查看，又不想每次系统新增操作都手动更新deny列表，担心遗漏导致权限泄露。

直接说结论：大多数这类基于规则的ACL系统，暂时不支持deny: [!view]这种直接的否定快捷写法，但有两种更健壮的替代方案，能完美解决你的顾虑：

方案一：先允许view，再拒绝所有其他操作（兼容性最强） #

利用ACL规则的「顺序匹配优先级」，先明确允许目标作业的view操作，再拒绝该作业的所有其他操作，最后放开所有其他作业的权限。这样不管未来系统新增什么操作，都会被第二条规则拦截：

context:
  project: '.*'
for:
  job:
    # 第一步：允许目标作业的查看权限
    - allow: [view]
      equals:
        uuid: ee70e193-733c-4cb2-bdf0-0d6672da563f
    # 第二步：拒绝目标作业的所有其他操作（包括未来新增的）
    - deny: '*'
      equals:
        uuid: ee70e193-733c-4cb2-bdf0-0d6672da563f
    # 第三步：允许所有其他作业的全部操作
    - allow: '*'
by:
  group: [users]

这个方案的优势是兼容性拉满，几乎所有规则型ACL系统都支持，完全不用担心未来操作更新的问题。

方案二：尝试否定通配符语法（更简洁，需验证系统支持） #

部分ACL引擎支持「先匹配所有，再排除特定项」的语法，比如deny: ['*', '!view']（注意顺序，先写通配符，再写排除项）。如果你的系统支持这种写法，配置会更简洁：

context:
  project: '.*'
for:
  job:
    - deny: ['*', '!view']
      equals:
        uuid: ee70e193-733c-4cb2-bdf0-0d6672da563f
    - allow: '*'
by:
  group: [users]

不过要注意：不是所有系统都支持这种否定通配符，建议先在测试环境验证，或者查阅你所用系统的ACL语法文档确认。

小提醒 #

对比两种方案，方案一虽然代码行数多一点，但胜在稳妥，不会因为系统版本更新或语法差异出问题；方案二更简洁，但依赖系统的语法支持。根据你的实际情况选择就好。

内容的提问来源于stack exchange，提问作者The Tomahawk