.. contents:: :depth: 2
::
git secrets --scan [-r|--recursive] [--cached] [--no-index] [--untracked] [<files>...]
git secrets --scan-history
git secrets --install [-f|--force] [<target-directory>]
git secrets --list [--global]
git secrets --add [-a|--allowed] [-l|--literal] [--global] <pattern>
git secrets --add-provider [--global] <command> [arguments...]
git secrets --register-aws [--global]
git secrets --aws-provider [<credentials-file>]
git-secrets 会扫描提交、提交信息以及 --no-ff 合并操作,以防止将机密信息添加到你 git 仓库中。如果某个提交、提交信息或 --no-ff 合并历史中的任何提交匹配到你配置的禁止正则表达式模式,则该提交将被拒绝。
git-secrets 必须放置在你的 PATH 环境变量中的某个位置,这样 git 在运行 git secrets 时才能找到它。
*nix(Linux/macOS)
你可以使用提供的 Makefile 中的 ``install`` 目标来安装 ``git secrets`` 及其手册页。你可以通过 PREFIX 和 MANPREFIX 变量自定义安装路径。
::
make install
Windows
~~~~~~~
运行提供的 ``install.ps1`` PowerShell 脚本。该脚本会将所需文件复制到安装目录(默认为 ``%USERPROFILE%/.git-secrets``),并将该目录添加到当前用户的 ``PATH`` 中。
::
PS > ./install.ps1
Homebrew(macOS 用户)
::
brew install git-secrets
.. warning::
**你还没有完成!你必须为每个你想使用** ``git secrets --install`` **的仓库安装 git 钩子**。
以下是一个快速示例,展示如何确保每次提交时都扫描 git 仓库中的机密信息::
cd /path/to/my/repo
git secrets --install
git secrets --register-aws
如果你希望以后初始化或克隆的所有仓库都自动添加钩子,请添加一个配置模板。
::
git secrets --register-aws --global
为所有本地仓库添加钩子。
::
git secrets --install ~/.git-templates/git-secrets
git config --global init.templateDir ~/.git-templates/git-secrets
添加自定义提供程序以扫描安全凭证。
::
git secrets --add-provider -- cat /path/to/secret/file/patterns
使用 git-secrets 还可以扫描仓库的所有修订版本:
::
git secrets --scan-history
操作模式
每个选项必须出现在命令行首位。
``--install``
为仓库安装 git 钩子。一旦为某个 git 仓库安装了钩子,该仓库的提交和非快进合并操作将被阻止提交机密信息。
``--scan``
扫描一个或多个文件中的机密信息。当某个文件包含机密信息时,被扫描文件中匹配的文本将输出到 stdout,脚本将以非零状态退出。每个匹配行会输出文件名、冒号、行号、冒号以及匹配的文本行。如果未提供任何文件,则扫描 ``git ls-files`` 返回的所有文件。
``--scan-history``
扫描仓库的所有修订版本。当某个文件包含机密信息时,被扫描文件中匹配的文本将输出到 stdout,脚本将以非零状态退出。每个匹配行会输出文件名、冒号、行号、冒号以及匹配的文本行。
``--list``
列出当前仓库或全局 git 配置中的 ``git-secrets`` 配置。
``--add``
添加一个禁止或允许的模式。
``--add-provider``
注册一个机密提供程序。机密提供程序是可执行文件,调用时会输出 ``git-secrets`` 应视为禁止的模式。
``--register-aws``
将常见的 AWS 模式添加到 git 配置,并确保 ``~/.aws/credentials`` 中的密钥不会出现在任何提交中。会添加以下检查:
- 通过 ``(A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}`` 匹配 AWS 访问密钥 ID
- Amazon Bedrock API 密钥。长寿命:``ABSK[A-Za-z0-9+/]{109,}=*``,短寿命:``bedrock-api-key-YmVkcm9jay5hbWF6b25hd3MuY29t``
- 通过“:”或“=”以及可选引号包围的 AWS 秘密访问密钥赋值
- 通过“:”或“=”以及可选引号包围的 AWS 账户 ID 赋值
- 允许的示例 AWS 密钥模式(``AKIAIOSFODNN7EXAMPLE`` 和 ``wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY``)
- 来自 ``~/.aws/credentials`` 的已知凭证
.. note::
虽然此命令注册的模式应该能捕获大多数 AWS 凭证实例,但这些模式 **不能** 保证捕获 **所有** 实例。``git-secrets`` 应作为额外保险手段——你仍需尽职尽责,确保不会将凭证提交到仓库中。
``--aws-provider``
输出 INI 文件中找到的凭证的机密提供程序。你可以选择提供 INI 文件的路径。
``--install`` 的选项
-f, --force
覆盖现有钩子(如果存在)。
<target-directory>
如果提供,则将 git 钩子安装到指定目录。如果未提供 <target-directory>,则假定当前目录。
如果提供的 ``<target-directory>`` 不在 git 仓库中,该目录将被创建,钩子将放在 ``<target-directory>/hooks`` 中。这对于创建 git 模板目录很有用,可与 ``git init --template <target-directory>`` 一起使用。
你可以在已初始化的仓库上再次运行 ``git init``。来自 `git init 文档 <https://git-scm.com/docs/git-init>`_:
根据 git 文档:在现有仓库中运行 ``git init`` 是安全的。它不会覆盖已有的内容。重新运行 ``git init`` 的主要原因是应用新添加的模板(或者如果指定了 ``--separate-git-dir``,则将仓库移动到其他位置)。
将安装以下 git 钩子:
1. ``pre-commit``:用于检查提交中更改的文件是否使用了禁止模式。
2. ``commit-msg``:用于判断提交消息是否包含禁止模式。
3. ``prepare-commit-msg``:用于判断合并提交是否会引入包含禁止模式的历史记录。请注意,此钩子仅在非快进合并时调用。
.. note::
Git 每个钩子只允许执行一个脚本。如果仓库包含 Debian 风格的子目录,如 ``pre-commit.d`` 和 ``commit-msg.d``,则 git 钩子将安装到这些目录中,这假定你已经配置了相应的钩子来执行这些目录中的所有脚本。如果这些 git 子目录不存在,则 git 钩子将安装到 git 仓库的 ``.git/hooks`` 目录。
示例 ^^^^^^^^
将 git 钩子安装到当前目录:::
cd /path/to/my/repository
git secrets --install
将 git 钩子安装到非当前目录的仓库:::
git secrets --install /path/to/my/repository
创建包含 git-secrets 的 git 模板,然后将该模板复制到 git 仓库中:::
git secrets --install ~/.git-templates/git-secrets
git init --template ~/.git-templates/git-secrets
覆盖现有钩子(如果存在):::
git secrets --install -f
--scan 的选项
``-r, --recursive``
递归扫描给定文件。如果遇到目录,将扫描该目录。如果未提供 ``-r``,目录将被忽略。
``-r`` 不能与 ``--cached``、``--no-index`` 或 ``--untracked`` 同时使用。
``--cached``
搜索索引文件中注册的 blob。
``--no-index``
搜索当前目录中未由 git 管理的文件。
``--untracked``
除了搜索工作树中已跟踪的文件外,``--scan`` 还会搜索未跟踪的文件。
``<files>...``
要扫描的磁盘上一个或多个文件的路径。
如果未提供文件,则扫描 ``git ls-files`` 返回的所有文件。
示例
^^^^^^^^
扫描仓库中的所有文件:::
git secrets --scan
扫描单个文件中的机密信息:::
git secrets --scan /path/to/file
递归扫描目录中的机密信息:::
git secrets --scan -r /path/to/directory
扫描多个文件中的机密信息:::
git secrets --scan /path/to/file /path/to/other/file
你可以使用通配符扫描:::
git secrets --scan /path/to/directory/*
从 stdin 扫描:::
echo 'hello!' | git secrets --scan -
``--list`` 的选项
--global
仅列出全局 git 配置中的 git-secrets 配置。
--add 的选项
``--global``
将模式添加到全局 git 配置
``-l, --literal``
转义提供模式中的特殊正则表达式字符,以便字面搜索该模式。
``-a, --allowed``
将模式标记为允许而不是禁止。允许的模式用于过滤误报。
``<pattern>``
要搜索的正则表达式模式。
示例
^^^^^^^^
向当前仓库添加一个禁止模式:::
git secrets --add '[A-Z0-9]{20}'
向全局 git 配置添加一个禁止模式:::
git secrets --add --global '[A-Z0-9]{20}'
添加一个进行字面扫描的字符串(``+`` 被转义):::
git secrets --add --literal 'foo+bar'
添加一个允许模式:::
git secrets --add -a 'allowed pattern'
``--register-aws`` 的选项
--global
将 AWS 特定的配置变量添加到全局 git 配置。
--aws-provider 的选项
``[<credentials-file>]``
如果提供,则指定要扫描的 INI 文件的自定义路径。如果未提供,则假定为 ``~/.aws/credentials``。
``--add-provider`` 的选项
--global
将提供程序添加到全局 git 配置。
<command>
要调用的提供程序命令。调用时,该命令应输出以换行符分隔的禁止模式到 stdout。提供的任何额外参数都会传递给该命令。
示例 ^^^^^^^^
注册一个带有参数的机密提供程序:::
git secrets --add-provider -- git secrets --aws-provider
从文件中 cat 出机密信息:::
git secrets --add-provider -- cat /path/to/secret/file/patterns
使用与 egrep 兼容的正则表达式来判断提交或提交消息是否包含禁止模式。这些正则表达式通过 git config 命令定义。需要注意的是,不同系统使用不同版本的 egrep。例如,在 macOS 上运行时,你会使用与 Ubuntu(BSD 与 GNU)不同的 egrep 版本。
你可以使用 git secrets --add <pattern> 将禁止的正则表达式模式添加到 git 配置中。
有时正则表达式可能会匹配误报。例如,git 提交 SHA 看起来很像 AWS 访问密钥。你可以使用以下命令指定多个不同的正则表达式模式作为误报:
::
git secrets --add --allowed 'my regex pattern'
你还可以将正则表达式模式添加到仓库根目录的 .gitallowed 文件中,以过滤误报。以 # 开头的行被跳过(注释行),空行也被跳过。
首先,git-secrets 会从文件中提取所有包含禁止匹配的行。匹配结果将包含匹配文件的完整路径,后面跟着“:”,然后是匹配的行号,再跟着由秘密模式匹配的整行内容。然后,如果你定义了允许的正则表达式,git-secrets 会检查所有匹配的行是否都至少与一个已注册的允许正则表达式匹配。如果所有被标记为秘密的行都被允许匹配抵消,那么主题文本不包含任何秘密。如果任何匹配的行没有被允许的正则表达式匹配,那么 git-secrets 将拒绝提交/合并/消息。
.. important::
就像添加过于贪婪的禁止模式是不好的做法一样,添加过于宽松的允许模式也是不好的做法。请务必使用对 ``git secrets --scan $filename`` 的临时调用来测试你的模式,确保它们按预期工作。
有时你想针对一组已知的机密信息检查精确模式匹配。例如,你可能想确保 ~/.aws/credentials 中的凭证永远不会出现在提交中。在这种情况下,最好将这些机密信息保留在一个位置,而不是将它们分散到 git 配置中的多个 git 仓库中。你可以使用“机密提供程序”来获取这些类型的凭证。机密提供程序是一个可执行文件,在调用时会输出以换行符分隔的禁止模式。
你可以使用 --add-provider 命令添加机密提供程序:::
git secrets --add-provider -- git secrets --aws-provider
注意使用了 --。这确保了每次在扫描机密信息时调用提供程序时,与提供程序相关的任何参数都会传递给提供程序。
让我们看一个示例。给定以下主题文本(存储在 /tmp/example 中):::
This is a test!
password=ex@mplepassword
password=******
More test...
以及以下注册的模式:
::
git secrets --add 'password\s*=\s*.+'
git secrets --add --allowed --literal 'ex@mplepassword'
运行 git secrets --scan /tmp/example,结果将输出以下错误信息:::
/tmp/example:3:password=******
[ERROR] Matched prohibited pattern
Possible mitigations:
- Mark false positives as allowed using: git config --add secrets.allowed ...
- List your configured patterns: git config --get-all secrets.patterns
- List your configured allowed patterns: git config --get-all secrets.allowed
- Use --no-verify if this is a one-time false positive
分解一下,禁止模式值 password\s*=\s*.+ 将匹配以下行:::
/tmp/example:2:password=ex@mplepassword
/tmp/example:3:password=******
...但第一项匹配由于匹配了允许的正则表达式 ex@mplepassword 而被过滤掉。因为仍存在未匹配的剩余行,所以它被视为秘密。
由于匹配行出现在以文件名和行号开头的行上(例如 /tmp/example:3:...),你可以创建允许模式,在正则表达式中考虑文件名和行号。例如,你可以使用类似以下方式白名单整个文件:::
git secrets --add --allowed '/tmp/example:.*'
git secrets --scan /tmp/example && echo $?
# 输出: 0
或者,如果文件的某一行不太可能更改,你可以使用类似以下方式允许该特定行号:
::
git secrets --add --allowed '/tmp/example:3:.*'
git secrets --scan /tmp/example && echo $?
# 输出: 0
创建允许模式时要记住这一点,以确保你的允许模式不会因文件名包含在允许模式匹配的主题文本中而意外被匹配。
在提交、合并或提交消息中出现误报匹配时,可以使用 --no-verify 选项。这将跳过执行 git 钩子,允许你进行提交或合并。
Michael Dowling <https://github.com/mtdowling>_https://github.com/awslabs/git-secrets <https://github.com/awslabs/git-secrets>_ 找到Copyright 2015 Amazon.com, Inc. or its affiliates. All Rights Reserved.