文章目录

代理凭据出现在公共构建日志中的频率比人们想象的要高。一个不小心的curl -v，一个明文变量，一个URL中的密码——你的用户名和密码就可能出现在流水线历史中，对整个团队可见。在本指南中，我们将讨论如何避免这种情况。

简介：代理凭据如何泄露到日志和历史记录中

想象一个典型场景。你正在配置一个构建，该构建通过Proxeon代理访问外部资源。为了快速测试连接，你直接在地址中写入密码：http://user:pass@host:port。构建通过，你很高兴。但一周后，你发现密码在每次运行的日志中、在runner的shell历史中，甚至在客户端的调试输出中都可见。

这不是罕见情况，而是一种规律。代理凭据有一个令人不快的特性：几乎每个网络调用都需要它们，因此很容易同时渗透到十几个地方。

你将获得什么

完成本指南后，你将能够配置CI/CD，使代理凭据不会出现在任何日志、命令历史或存储库中。你将学会使用流行系统的秘密管理功能，禁用危险的调试模式，在不停机的情况下安全更改密码，并使用现成的脚本检查所有内容。

本指南适合谁

本材料面向中级工程师：DevOps、后端开发人员、QA自动化工程师。如果你已经知道如何运行流水线并了解环境变量是什么，你会感到轻松。高级读者会找到有关轮换和审计的部分。

你需要提前了解什么

我们在这里不再赘述http_proxy和no_proxy变量的基本配置——这有单独的材料。假设你已经可以正常连接到代理，现在的任务是使凭据存储安全。

需要多长时间

阅读和理解大约需要40分钟。在一个流水线中实施大约需要30分钟到1.5小时，具体取决于CI系统。轮换和泄露检查可以在之后添加，每个需要15-20分钟。

初步准备：需要什么

在开始之前，收集所有必要的东西。这将节省时间并避免工作中断。

工具和权限

  • 访问您的CI/CD项目，并具有编辑设置和秘密的权限。
  • 有效的Proxeon代理订阅，包含用户名、密码、主机和端口。
  • 本地机器已安装curl、git，以及Python 3和Node.js解释器（如果您计划使用这些示例）。
  • 用于编辑流水线配置的文本编辑器。

系统要求

没有特殊要求。一切都可以在Linux、macOS和Windows上运行。CI runner通常基于Linux，因此大多数示例使用bash语法。对于Windows runner，我们会单独提到差异。

提前准备什么

将当前的代理凭据记录在可靠的密码管理器中。它们在配置秘密时会用到。不要将它们存储在桌面上的普通文本文件中。

提示：如果您的Proxeon套餐允许，为CI创建一个单独的代理账户。这样构建凭据的泄露不会影响您的个人凭据，反之亦然。

配置备份

在更改流水线之前，备份当前配置文件。只需将.gitlab-ci.yml、workflow文件或Jenkinsfile复制到存储库之外的单独文件夹中。

⚠️ 注意：切勿通过提交带有密码的备份到同一存储库来创建备份。即使是在临时分支中，凭据也会永远留在git历史中。

基本概念：简单术语

让我们分解关键术语，以便后续不混淆。

代理凭据

这是您的客户端用来确认有权使用Proxeon代理的用户名和密码。有时使用IP绑定而不是用户名/密码，但这里我们专门讨论用户名/密码对。

CI中的秘密

秘密是CI系统内部的一种特殊存储，您将敏感值放入其中。系统对其进行加密，并在构建中将其作为环境变量注入，同时在日志中自动隐藏。

掩码

掩码是CI将输出中秘密的值替换为星号。如果密码意外打印，您将看到类似[MASKED]的内容。它并不总是完美工作，因此我们将组合使用多种保护措施。

Proxy-Authorization头

当客户端在代理上进行身份验证时，它会发送带有编码凭据的Proxy-Authorization头。在许多客户端的详细调试模式下，此头会被完整打印。解码它非常容易，因此这种输出被视为泄露。

范围

范围决定哪些构建可以访问秘密。正确限制范围的秘密仅对受保护的分支可见，不会出现在fork或外部拉取请求中。

提示：记住主要原则：秘密在进程内存中存在的时间应尽可能短，并且不应在磁盘和输出中留下任何痕迹。

步骤1：理解主要陷阱——URL中的密码

本阶段目标：学会识别最常见的泄露来源，并永久放弃它。

最常见的错误是将凭据直接写入代理地址：http://user:pass@host:port。这很方便，因此几乎所有初学者都这样做。问题在于，这样的URL会在意想不到的地方出现。

URL中的密码具体在哪里出现

  1. 进程列表。 runner上的ps命令将显示完整的命令行，包括密码。同一台机器上的任何进程都可以读取它。
  2. 代理本身的日志。一些服务器日志会记录连接字符串。如果URL包含密码，密码就会进入日志。
  3. Shell命令历史。.bash_history文件存储您输入的所有内容，包括URL中的密码。
  4. 客户端调试输出。使用详细模式标志运行时，客户端会打印目标地址以及凭据。
  5. CI日志。如果包含URL的变量未标记为秘密，它会在echo步骤或错误提示中明文打印。

立即检查。在任意机器上运行一个无害命令并查看进程列表。

curl -x http://myuser:mypass@proxy.proxeon.net:8080 https://example.com & ps aux | grep curl

您将在ps输出中看到明文密码。这就是我们要消除的泄露。

⚠️ 注意：即使构建是私有的，runner上的其他进程、共享runner上的其他作业或监控工具也可能访问进程列表。将URL中的密码视为公开的。

预期结果：您了解了五个泄露位置，并且永远不会在代理地址中写入密码。

✅ 检查：运行上述测试命令并确认您在ps输出中看到密码。如果看到了，您正确复现了问题并准备解决它。

步骤2：正确方法——环境变量和凭据文件

本阶段目标：将凭据从URL移动到安全存储——环境变量和特殊文件。

这个想法很简单。用户名和密码与地址分开存储。客户端从环境或权限受限的文件中读取它们，而不是从命令行。这样它们不会出现在进程列表或历史记录中。

选项A：环境变量

许多客户端可以从环境中读取代理凭据。让我们看一些例子。

通过环境变量使用curl

设置代理地址而不包含凭据，并通过单独的标志传递用户名和密码，其值从变量中获取。

  1. 将包含凭据的变量导出到环境中（在CI中，这将由秘密完成；在本地，则由安全来源提供）。
  2. 通过-U标志传递其值，而不是在URL中。
export PROXY_CREDS="$PROXEON_USER:$PROXEON_PASS"; curl -x http://proxy.proxeon.net:8080 -U "$PROXY_CREDS" https://example.com

使用带有变量的-U标志比在URL中放入密码更好，但它在ps中仍然可见。因此，下面提到的凭据文件是首选。

Python requests

在Python中，通过os.environ从环境中读取凭据，并在内存中构建proxies字典。不要打印任何内容。

import os, requests; user=os.environ['PROXEON_USER']; pwd=os.environ['PROXEON_PASS']; proxy=f'http://{user}:{pwd}@proxy.proxeon.net:8080'; r=requests.get('https://example.com', proxies={'http':proxy,'https':proxy}); print(r.status_code)

在这里，密码保持在Python进程内的变量中，不会进入命令行。关键是不要记录整个proxy变量。

Node.js

在Node.js中，也从process.env获取凭据，并在代码中构建代理agent。

const user=process.env.PROXEON_USER; const pass=process.env.PROXEON_PASS; const proxyUrl=`http://${user}:${pass}@proxy.proxeon.net:8080`; const {HttpsProxyAgent}=require('https-proxy-agent'); const agent=new HttpsProxyAgent(proxyUrl); fetch('https://example.com',{agent}).then(r=>console.log(r.status));

提示：在任何语言中，只记录响应状态，必要时记录目标主机。切勿打印包含代理设置的整个对象——其中包含密码。

选项B：.netrc文件

.netrc文件是存储凭据而不在命令中显示它们的经典方法。curl可以自动读取它。

  1. 在runner的主目录中动态创建.netrc文件，从CI秘密中获取。
  2. 写入包含机器、用户名和密码的行。
  3. 设置权限为600，使文件只能由所有者读取。
  4. 使用netrc标志运行curl。
printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

现在密码不会出现在命令行或进程列表中。它位于具有600权限的文件中，您将在构建结束时删除它。

⚠️ 注意：权限600是强制性的。否则，curl可能拒绝读取文件，并且文件可能对其他用户可见。

选项C：curl配置文件

curl可以从配置文件中读取标志。将代理和凭据放入其中，并设置权限600。

printf 'proxy = http://proxy.proxeon.net:8080\nproxy-user = "%s:%s"\n' "$PROXEON_USER" "$PROXEON_PASS" > ~/.curlrc; chmod 600 ~/.curlrc; curl https://example.com

当存在具有600权限的.curlrc时，凭据在进程中不可见，也不会写入历史记录。

选项D：应用程序客户端配置

如果您的应用程序读取配置，将代理凭据存储在存储库之外。在存储库中，只保留带有占位符的模板，并在runner上从秘密中替换实际值。

预期结果：在任何示例中，密码都不会出现在命令行或进程列表中。它要么存在于进程内的变量中，要么存在于具有600权限的文件中。

✅ 检查：运行任何示例，并同时运行ps aux | grep curl。输出中不应有密码。如果使用netrc，请使用ls -l ~/.netrc检查权限——应该是-rw-------。

步骤3：流行CI中的秘密——GitHub Actions、GitLab CI、Jenkins

本阶段目标：将代理凭据放在CI系统的安全存储中，并无泄漏地在构建中使用它们。

GitHub Actions

在GitHub中，秘密存储在仓库或组织级别。

  1. 打开存储库并转到Settings设置部分。
  2. 在左侧找到Secrets and variables，然后点击Actions。
  3. 点击New repository secret按钮。
  4. 输入名称，例如PROXEON_USER，以及值——您的用户名。保存。
  5. 对PROXEON_PASS重复操作，输入密码。

在工作流中，通过secrets上下文访问秘密，并将它们作为环境变量传递给步骤。

steps: - name: request env: PROXEON_USER: ${{ secrets.PROXEON_USER }} PROXEON_PASS: ${{ secrets.PROXEON_PASS }} run: printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

GitHub会在日志中自动掩码秘密的值。如果密码意外打印，您会看到三个星号。

⚠️ 注意：默认情况下，从fork通过pull_request启动的工作流无法访问秘密。除非绝对必要，否则不要将其更改为pull_request_target——否则外部贡献者可能获取您的凭据。

GitLab CI

在GitLab中，秘密称为CI/CD变量，在项目中配置。

  1. 打开项目，进入Settings，然后点击CI/CD。
  2. 展开Variables部分，点击Add variable。
  3. 输入键PROXEON_USER和值。
  4. 勾选Masked选项，使值在日志中隐藏。
  5. 勾选Protected选项，使变量仅对受保护的分支和标签可用。
  6. 对PROXEON_PASS重复操作。

在.gitlab-ci.yml中，变量自动作为环境变量可用。

request: script: - printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc - chmod 600 ~/.netrc - curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

提示：GitLab中的Masked标志仅适用于满足规则的值：最小长度，无换行符，base64兼容字符集。如果密码未掩码，GitLab在保存时会显示警告。在这种情况下，请将密码更改为符合要求。

Jenkins

在Jenkins中，凭据存储在Credentials部分，并通过Credentials Binding插件注入。

  1. 打开Manage Jenkins，然后点击Credentials。
  2. 选择所需域，例如System和Global credentials。
  3. 点击Add Credentials。
  4. 选择Username with password类型。
  5. 输入代理用户名和密码，设置一个明确的ID，例如proxeon-creds。

在Jenkinsfile中，使用withCredentials块包裹使用。Jenkins会在控制台中掩码值。

withCredentials([usernamePassword(credentialsId: 'proxeon-creds', usernameVariable: 'PROXEON_USER', passwordVariable: 'PROXEON_PASS')]) { sh 'printf "machine proxy.proxeon.net login %s password %s" "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com' }

⚠️ 注意：Jenkins只掩码通过Credentials Binding设置的值。如果您在Groovy中手动拼接密码并打印，掩码将不起作用。仅在withCredentials块内并在sh步骤中处理凭据。

预期结果：凭据存储在CI系统的安全存储中，作为环境变量注入构建，并在日志中掩码。

✅ 检查：运行构建并打开日志。确保密码显示为星号或掩码标记。尝试通过echo故意输出变量——系统应该隐藏它。

步骤4：日志——禁用打印Proxy-Authorization的模式

本阶段目标：移除详细输出，特别是显示授权头的部分，并保持安全的日志级别。

CI掩码不是万灵药。如果客户端打印base64编码的Proxy-Authorization头，而系统不知道原始密码，掩码可能无法生效。因此，我们在源头禁用危险模式。

curl

-v标志，尤其是--trace，会打印头，包括代理授权。在CI中，使用静默模式。

  1. 从构建命令中移除-v、--verbose、--trace和--trace-ascii。
  2. 对于错误控制，使用-sS：静默，但显示错误。
  3. 如果需要调试，只在本地使用--trace，绝不在CI中使用。
curl -sS --netrc -x http://proxy.proxeon.net:8080 https://example.com -o /dev/null -w '%{http_code}'

这样，您只获得响应代码，输出中没有任何头。

Python requests

requests库本身不会打印凭据，但启用的urllib3 DEBUG日志会输出请求头。将日志级别保持在WARNING或INFO。

import logging; logging.getLogger('urllib3').setLevel(logging.WARNING)

提示：如果确实需要DEBUG进行诊断，请添加一个日志过滤器，从消息中剥离Proxy-Authorization头。但更简单的是在本地进行诊断，在CI中保持WARNING。

Node.js

在Node.js中，避免在CI中设置NODE_DEBUG=http——它会输出头。也不要打印整个agent对象或请求对象。

  1. 从runner环境中移除NODE_DEBUG。
  2. 在错误处理程序中，只打印error.message，而不是整个对象。
  3. 不要在构建中使用HTTP请求记录库。

⚠️ 注意：未处理异常的回溯也可能包含带有凭据的代理URL（如果您构建了带密码的URL）。这是另一个不要在URL中放入密码，而使用netrc或单独字段的原因。

预期结果：CI中没有工具打印授权头或完整的代理URL。

✅ 检查：运行构建，并在日志中搜索Proxy-Authorization、Basic和您的用户名。不应有任何匹配。

步骤5：实现代理密码轮换而无需停机

本阶段目标：学习如何更改密码，使构建不会失败，并且旧密码停止工作。

代理密码需要定期更改，并且必须在怀疑泄露后立即更改。目标是无需停机窗口。

重叠策略

理想情况是旧密码和新密码同时有效一段时间。如果您的Proxeon套餐允许创建第二个账户或额外的凭据集，请使用此功能。

  1. 在Proxeon个人账户中创建新凭据，而不删除旧凭据。
  2. 在CI秘密中添加新值，使用临时名称，例如PROXEON_USER_NEW。
  3. 在单独的分支中切换流水线到新名称，并运行构建。
  4. 确认构建使用新凭据成功。
  5. 将主秘密PROXEON_USER和PROXEON_PASS的值替换为新值。
  6. 移除临时秘密。
  7. 在Proxeon账户中撤销旧凭据。

这样，在任意时间点都有一组有效的凭据，构建不会失败。

如果重叠不可用

如果只能使用一对凭据，请在低峰期操作。

  1. 选择构建活动最少的时间。
  2. 暂停新流水线的启动几分钟。
  3. 在Proxeon账户中更改密码。
  4. 立即更新CI中的秘密值。
  5. 启动测试构建。
  6. 恢复正常操作。

提示：制定简短的轮换规则，并将其放在流水线描述附近。在泄露后的压力情况下，准备好的步骤列表可以节省时间和精力。

⚠️ 注意：更改密码后，务必删除runner上可能缓存的旧netrc或curlrc文件。否则，客户端将继续使用旧凭据。

预期结果：密码已更改，新构建使用新凭据，旧密码不再有效。

✅ 检查：尝试使用旧密码执行请求——应返回代理身份验证错误。同时，新构建成功。

步骤6：泄漏检查——现成的审计脚本

本阶段目标：确保制品、日志和存储库中没有凭据，并自动化此检查。

在哪里查找

  • 构建制品：构建的文件、报告、转储。
  • 流水线日志，包括旧运行。
  • git存储库历史记录。
  • Runner缓存和临时文件。

在制品和日志中搜索

将制品和日志下载到本地文件夹，并搜索特定标记：用户名、部分密码、单词Basic和授权头。

grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}|proxeon.*login|:[^@/]+@proxy' ./artifacts ./logs

该脚本搜索授权头、Basic后的base64字符串、netrc中的用户名模式以及URL中在@符号前有密码的模式。任何匹配都值得调查。

在git历史中搜索

密码可能已进入旧提交。检查整个历史。

git log -p -S 'proxy.proxeon.net' --all | grep -nE ':[^@/]+@proxy|password [^ ]+'

⚠️ 注意：如果在git历史中找到密码，仅删除文件是不够的——它仍会留在旧提交中。必须使用特殊工具重写历史，更重要的是，立即更改密码。将此类密码视为已泄露。

在流水线中自动化

添加一个单独的作业，在发布之前扫描构建的制品，并在找到时失败。这种保护措施可以在泄露传播之前捕获它。

leak_check: script: - if grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}' ./artifacts; then echo 'LEAK DETECTED'; exit 1; fi

提示：此外，在本地配置pre-commit钩子，使用现成的秘密扫描器。它们可以在凭据进入存储库之前捕获它们。

预期结果：手动审计和自动作业确认没有凭据存在。

✅ 检查：运行审计脚本——应无匹配。然后故意在制品中放置包含Basic标记的测试字符串，并确认脚本找到它并失败。

步骤7：部署流水线前检查清单

本阶段目标：在将流水线投入生产前进行最终检查。

逐项检查列表并勾选每一项。如果任何一项未完成，不要部署流水线。

  1. 代理密码未以user:pass@host格式写在URL中。
  2. 用户名和密码仅存储在CI秘密中，不在存储库文件中。
  3. 秘密标记为可掩码和受保护。
  4. 秘密对外部fork和拉取请求不可用。
  5. 从命令中移除了详细模式和跟踪标志。
  6. HTTP库日志级别不是DEBUG。
  7. Runner环境中没有NODE_DEBUG等调试变量。
  8. netrc和curlrc文件在运行时创建，权限为600。
  9. 凭据文件在构建结束时删除，或位于临时runner上。
  10. 流水线中有泄漏检查作业。
  11. git历史已检查，不包含凭据。
  12. 有密码轮换计划。

提示：将此清单保存为模板，并将其附加到每个使用代理的新流水线。一致性可减少错误。

✅ 检查：所有十二项均已勾选。只有这样，流水线才能部署。

验证结果：如何确保一切正常

让我们将最终检查合并为一个场景。

功能检查清单

  • 构建成功通过Proxeon代理访问目标资源。
  • 构建日志中没有密码、用户名、授权base64字符串或完整代理URL。
  • 在请求期间，runner进程列表中没有密码。
  • 制品干净，审计脚本无匹配。
  • 即使故意echo，秘密也会被掩码。

如何测试

  1. 端到端运行完整流水线。
  2. 打开日志，搜索用户名——不应有匹配。
  3. 下载制品并运行审计脚本。
  4. 检查泄漏检查作业——应通过。

成功指标

成功看起来像这样：构建是绿色的，通过代理的请求成功，并且对所有可能位置的搜索都找不到任何凭据片段。如果是这样，您已经达到了指南的目标。

典型错误和解决方案

让我们按问题、原因、解决方案的结构来讨论常见问题。

问题1：密码仍然在日志中可见

原因：变量创建为普通变量，而不是秘密，或者未标记为掩码。

解决方案：将值移动到秘密部分，启用掩码，并检查配置和存储中的变量名称是否匹配。

问题2：GitLab中的掩码未生效

原因：密码包含掩码不允许的字符或换行符。

解决方案：将密码更换为符合掩码要求的足够长的字母、数字和允许字符组合。

问题3：curl无法读取netrc

原因：文件权限错误或不在主目录中。

解决方案：使用chmod设置权限600，并确保路径正确，或者使用netrc-file标志指定路径。

问题4：错误发生时密码出现在回溯中

原因：代理URL包含凭据，客户端在异常中打印了它。

解决方案：改用netrc或单独的用户名/密码字段，使URL不含凭据，并仅打印错误消息。

问题5：轮换后旧密码仍在使用

原因：缓存的netrc或curlrc文件残留在runner上。

解决方案：在每次构建结束时删除凭据文件，并使用临时runner，其文件系统在运行之间被清理。

问题6：秘密泄露给fork拉取请求

原因：启用了允许外部PR访问秘密的模式。

解决方案：禁用此模式，仅对受信任的分支运行使用秘密的构建，外部PR的检查在无代理访问的情况下进行。

问题7：在git历史中发现密码

原因：凭据曾经被提交到配置文件中。

解决方案：立即更改密码，然后重写存储库历史，从所有提交中删除敏感数据。

额外功能：高级保护

当基本保护到位后，您可以进一步强化它。

外部秘密管理器

将凭据存储在CI系统外部，连接到外部秘密管理器。流水线仅在构建期间通过短期令牌获取凭据。这样秘密不会持续存储在项目设置中。

短期令牌而非密码

如果Proxeon基础设施及您的访问方案支持，优先使用具有有限生命周期的临时令牌。即使泄露，令牌也会很快失效。

按环境分离凭据

为测试和生产构建使用不同的凭据。测试凭据的泄露不会影响生产流程。

提示：为代理账户设置异常活动警报。请求突然激增或从意外来源连接是潜在泄露的信号，需要立即轮换。

自动轮换

高级团队自动化轮换：脚本创建新凭据，更新秘密，并在无需人工干预的情况下撤销旧凭据。从手动流程开始，当流程成熟后添加自动化。

常见问题

我可以只相信CI掩码而不做其他吗？

不行。掩码只会捕获已知值的精确匹配。base64编码的头或部分输出可能会被漏掉。将掩码与不在URL中使用密码和禁用详细日志相结合。

环境变量和netrc文件哪个更安全？

对于curl，netrc文件（权限600）是首选，因为值不会出现在进程列表中。对于Python和Node.js代码，环境变量在进程内读取更为方便。两者在小心处理时都是安全的。

构建后是否需要删除凭据文件？

是的，如果runner被重用。在临时runner上，构建后机器会被销毁，这不太关键，但无论如何，在结束时删除是一种好习惯。

如果代理密码包含特殊字符怎么办？

在netrc和单独字段中，特殊字符通常不是问题。当插入URL时才会出现问题，@和:等字符会破坏解析。这是不要将密码放在URL中的另一个理由。

requests会自己打印凭据吗？

默认不会。当启用urllib3的DEBUG日志或打印代理设置对象时，会发生泄露。保持日志级别为WARNING，并且不要打印整个设置。

使用proxy-user标志时，密码在进程列表中是否可见？

是的，命令行中的标志在ps中可见。因此，对于curl，首选netrc或curlrc，其中凭据不会作为参数传递。

我应该多久更改一次代理密码？

计划轮换应定期进行，例如每季度一次，并且在任何怀疑泄露时立即进行。步骤5中的轮换计划将帮助您快速完成。

我可以将凭据存储在存储库中的加密文件中吗？

技术上可以，但这会使过程复杂化，并增加加密密钥泄露的风险。CI秘密和外部秘密管理器更简单、更安全。除非必要，不要发明自己的存储。

如果已经发生泄露怎么办？

按顺序操作：立即更改代理密码，撤销旧凭据，使用审计脚本查找所有泄露位置，必要时重写git历史，并分析原因以防止再次发生。

这些建议适用于Windows runner吗？

是的，原则相同。语法不同：使用shell的设置变量方式代替export，使用文件属性设置代替chmod。存储和禁用日志的逻辑是相同的。

结论

您已经走过了从在URL中写密码的不安全习惯到在CI/CD中完全保护代理凭据的旅程。让我们回顾一下所做的工作。

您学会了识别五个泄露位置，并放弃了在代理地址中写密码。您将凭据移至环境变量和netrc、curlrc以及客户端配置文件（权限为600）。您在GitHub Actions、GitLab CI和Jenkins中配置了秘密，具有掩码和范围限制。您在curl、Python requests和Node.js中禁用了打印授权头的详细日志。您掌握了不停机轮换密码的方法，并构建了现成的泄露审计脚本。最后，您通过了部署前最终检查清单。

下一步。将清单作为所有使用Proxeon代理的流水线的强制审查步骤。在所有项目中添加泄漏检查作业。当基本流程成为习惯后，逐步过渡到外部秘密管理器和短期令牌。

进一步发展方向。研究组织范围内秘密管理的实践、自动轮换以及代理账户异常监控。凭据安全不是一次性设置，而是一种持续的工程纪律。但您现在有了可靠的基础，可以在此基础上构建一切。祝您构建顺利且安全。