企业官网建设流程全解析

Infisical 如何配置密钥验证规则，强制命名规范与内容策略？

【免费下载链接】infisicalInfisical is the open-source platform for secrets, certificates, and privileged access management.项目地址: https://gitcode.com/GitHub_Trending/in/infisical

当你需要保证项目中的密钥命名统一（例如 key 必须使用UPPER_SNAKE_CASE）、值不能过短或空、连接字符串必须以特定前缀开头时，Infisical 的Secret Validation Rules可以在密钥被创建、更新或生成时自动校验：静态密钥不符合约束会被直接拒绝并报错；动态密钥与密钥轮换则按约束直接生成合规的密码。规则在保存后立即生效，作用于其范围内的每一次密钥写入。

规则类型与支持的 Provider

Infisical 支持三种规则类型，各自针对不同的密钥来源：

• Static Secrets（静态密钥）——在用户管理的密钥被创建或更新时校验。
• Dynamic Secrets（动态密钥）——在签发动态密钥租约时，对生成的凭据生效，需指定适用的 provider。
• Secret Rotations（密钥轮换）——在每次轮换生成凭据时生效，同样需指定 provider。

动态密钥与轮换规则必须选择一个或多个provider，目前支持范围如下（来自 Secret validation rules 文档）：

注意：当动态密钥或轮换规则覆盖了某个 provider 时，该动态密钥/轮换上用户自行配置的password configuration / password requirements会被忽略，以规则的约束为准；受影响表单的 UI 会显示警告提示。

可用的约束类型

每条规则包含一个或多个约束（constraint），一条规则的所有约束都必须同时满足：

约束作用的目标（Applies To）按规则类型区分：

• Static Secrets——每个约束作用于密钥的key或value（创建规则时需为每个约束二选一）；Prevent Value Reuse只作用于 value。
• Dynamic Secrets与Secret Rotations——约束统一作用于生成的密码（generated password）。

规则的生效范围（Scoping）

每条规则都会限定作用范围，可以为项目不同部分设置不同的校验标准：

• Environment——限定到某个具体环境（如production），或选择 "All Environments"。
• Folder Path——限定到特定文件夹路径，支持 glob 模式（如/**表示全部路径，/services/*表示/services的直接子文件夹）。
• Providers（仅动态密钥与轮换规则）——规则只在范围内的动态密钥/轮换同时匹配所选 provider 之一时才触发。

文档给出的典型组合是：生产环境执行更严格的命名规范，开发环境保持宽松；或对生产数据库轮换要求更长的生成密码。

创建一条密钥验证规则

操作路径来自文档中的Creating a rule章节，在 Infisical 控制台中完成：

1. 打开 Policies 标签页：进入Project Settings，选择Policies标签页，找到Secret Validation Rules区域。

2. 点击 Create Rule：打开规则创建表单。

3. 配置规则：

   • Rule Details：
     • Name——描述性名称（如 "Production key naming convention"）；
     • Description（可选）——简述规则强制的内容与原因；
     • Rule Type——Static Secrets、Dynamic Secrets 或 Secret Rotations；
     • Providers（动态密钥/轮换规则）——选择一个或多个适用 provider；
     • Environment——选择具体环境或 "All Environments"；
     • Folder Path——路径范围，支持 glob（如/**）。
   • Constraints：点击Add Constraint选择约束类型。静态密钥规则需为每个约束指定作用于key还是value；动态密钥/轮换规则则针对生成的密码给出长度、正则、前缀或后缀参数。一条规则可添加多个约束，全部必须满足。

4. 保存：点击Create Rule。规则立即生效，此后范围内每一次密钥写入都会被校验。

文档给出的策略示例

以下示例均取自文档，可作为命名规范与内容策略的直接参考：

1. 强制UPPER_SNAKE_CASE命名：创建作用范围为所有环境的规则，对secret key添加Regex Pattern约束，Pattern 为^[A-Z][A-Z0-9_]*$。所有密钥 key 必须形如DATABASE_URL、API_KEY，mySecret或api-key这样的命名会被拒绝。

2. 强制最小值长度：对secret value添加Min Length约束，Minimum 设为8，防止保存过短或类空值，可捕捉误粘贴或占位符值。

3. 强制连接串格式：创建作用范围为特定文件夹路径（如/database/*）的规则，对secret value添加Required Prefix约束，Prefix 为postgresql://，保证该文件夹内的密钥都是合法的 PostgreSQL 连接串。

4. 环境级 key 后缀：作用范围为production环境，对secret key添加Required Suffix约束，Suffix 为_PROD，用于区分生产环境密钥。

5. 防止复用旧值：对secret value添加Prevent Value Reuse约束，Previous versions 设为10。更新密钥时新值会与最近 10 个历史版本比对，适合执行轮换策略、避免密钥被"回收利用"。

6. SQL 动态密钥生成强密码：创建Dynamic Secrets规则，范围为所有环境 +/**，provider 选择SQL Database，约束为Min Length24+Required PrefixINF_。此后项目内签发的每个 SQL 动态密钥租约产生的密码都至少 24 字符且以INF_开头；规则生效期间，单个 SQL 动态密钥上的 password configuration 会被忽略。

7. Postgres 轮换按模式生成密码：创建Secret Rotations规则，范围为production环境，provider 选择PostgreSQL Credentials，约束Regex Pattern为^[A-Z][A-Z0-9]{19,29}$。生产环境的 PostgreSQL 轮换将生成以大写字母开头、20–30 位大小写字母数字的密码。

动态密钥与轮换规则的行为差异

静态密钥规则是拒绝式的：写入不符合约束即报错。而动态密钥与轮换规则驱动的是生成过程——签发租约或执行轮换时，Infisical 会按匹配规则的约束直接生成密码，替代默认密码生成逻辑。两点需要注意：

• 如果规则设置了Regex Pattern，密码直接按该模式生成，规则上的min/max length 约束被忽略；需要用正则表达长度时把长度窗口写进模式里（如[A-Z0-9]{16,24}）。上面示例 7 的正则^[A-Z][A-Z0-9]{19,29}$即通过模式本身约束 20–30 位长度。
• 如果规则约束在保存时即不可行（如非法正则、min 长度大于 max 长度），规则会在保存时被拒绝，问题当场暴露而不是等到签发/轮换时才发现。

重叠规则冲突

Infisical 会拒绝互相冲突的规则：两条规则作用范围重叠（environment 和 folder path 交集），且含有同类型、作用于同一字段的约束时，第二条会被拒绝。例如作用范围重叠的两条规则不能同时各自带一个 "Regex Pattern on key" 约束，应合并为一条规则。

对动态密钥/轮换规则，仅当选中的provider 集合相交时才构成冲突：例如/db/*下有一条仅 PostgreSQL 的轮换规则，/**下再建一条 PostgreSQL 轮换规则，两者在 PostgreSQL + 路径 glob 上重叠，第二条会被拒绝；而同一路径下仅 Milvus 的规则与 PostgreSQL 规则不冲突。

验证规则是否生效

文档提供的验证方式有两类：

1. 写入时行为（主路径）

• 静态密钥：在规则范围内尝试写入不合规的 key 或 value，写入会被拒绝，错误信息会描述违反了哪条规则的哪个约束；写入合规值则成功。规则只对创建/更新（mutations）生效，规则添加之前已存在的密钥不会被追溯校验。
• 动态密钥/轮换：触发一次租约签发或轮换，检查生成的密码是否符合约束（长度、前缀或正则）。
• 保存规则本身也是一次校验：不可行的约束组合（非法正则、min > max）在保存时即被拒绝。

2. 存量密钥合规检查（Secret Insights，付费功能）

规则不追溯存量密钥，要找出"规则存在之前创建、或已不再满足长度/正则/前缀约束"的存量密钥，可借助 Secret Insights 的Audit Reports：

1. 在项目侧边栏打开Insights标签页，找到Audit Reports卡片；
2. 点击Generate Report；
3. 在对话框中勾选Secret Validation Compliance报告类型（内容即"违反某条密钥验证规则的存量密钥"）；
4. （可选）填写逗号分隔的收件人邮箱，留空则发送给自己；
5. 再次点击Generate Report。生成是异步的，每个项目同一时刻最多有一个报告在生成，完成后以邮件附 CSV 发送；报告状态可在历史表中实时查看（Pending / Generating / Completed / Partial / Failed）。

注意两点前提：Secret Insights 是付费功能（Infisical Cloud 的 Pro/Enterprise 计划可用，自托管需向 sales@infisical.com 获取 license）；审计报告包含敏感元数据（密钥名、路径、访问模式、收件人邮箱），文档明确提醒只发给可信收件人并把 CSV 当作机密文件处理。

边界与限制

• 静态密钥规则只在写入（创建/更新）时强制，不会追溯校验存量密钥；
• 规则覆盖 provider 后，该 provider 上用户自配的 password configuration 被忽略（UI 会给出警告）；
• 设置了 Regex Pattern 的动态密钥/轮换规则，其 min/max length 约束不再生效，长度需写进正则；
• 重叠范围 + 同类型同字段约束的规则会被拒绝，需合并为一条；
• Prevent Value Reuse仅适用于静态密钥的 value，不适用于动态密钥与轮换规则。

完整字段说明与更多示例可参考仓库中的 Secret validation rules 文档 与 Secret insights 文档。

【免费下载链接】infisicalInfisical is the open-source platform for secrets, certificates, and privileged access management.项目地址: https://gitcode.com/GitHub_Trending/in/infisical