恰当地管理安全凭据
前言
如何在不到一个月的时间内赚到 4000 美金闲钱？你可以试试在 GitHub 上搜索 “api-key” 试试。
2019 年 10 月一名叫做 vinothkumar 的程序员偶然在 GitHub 上搜到了星巴克员工不小心泄漏的云平台 Jumbcloud 的 API Key。他把个问题上传到了漏洞众测平台 HackerOne ，并演示了如何利用泄漏的 API Key 接管星巴克的 AWS 账号。星巴克的工程师立马在四天后修复了这个问题，并在 11 月奖励了 vinothkumar 4000 美金。而星巴克平时在该平台提供的奖金通常仅在 250 - 375 美金之间。
（图片为 HackerOne 平台上的报告截图）
安全凭据作为敏感信息，如果被硬编码在配置文件内，将会有极大安全隐患。比如像星巴克这次事件，云平台上具有管理员权限的 API 密钥被硬编码并提交到 GitHub 公共仓库中，看到该密钥的所有人都具备了该云账户的完全访问权限，该云服务上储存的所有用户敏感信息、保密数据等都可能被轻易窃取，这类数据的泄漏可能会导致企业或团队面临巨额赔偿，承担相应法律责任；信息泄漏等安全问题对企业品牌也会构成严重打击，造成企业信誉降低、用户大量流失等严重后果。与这些后果相比，星巴克支付的 4000 美金也就不值一提了。
（在 GitHub 上可以轻易搜到泄露安全凭据的代码）
在持续集成过程中，需要和很多第三方平台及应用进行交互，比如在 GitHub 上拉取代码、连接执行持续集成任务的服务器等等。在交互过程中都需要对应的安全凭据提供访问权限。项目的复杂性，需要交互的平台和安全凭据类型的多样性也使得安全凭据难以管理。如何恰当的管理安全凭据是项目持续集成中首要考虑的问题。
通过这篇文章，你将收获：
- 什么是安全凭据，安全凭据有哪些常见类型？
- 如何利用 CODING DevOps 恰当的管理安全凭据？
什么是安全凭据
当用户对第三方平台或应用进行访问时，需要提供安全凭据，该平台/应用会通过安全凭据判断用户是否有访问权限，以及是否有具体资源的获取权限。比如在持续集成的过程中，如果想要从第三方代码托管平台检出代码，需要有安全凭据来访问该平台和用户指定项目仓库。用户可以生成接下来提到的几种安全凭据，配置在持续集成文件内，使持续集成任务可以拉取到用户提交的最新代码，完成构建。
在持续集成中所用到的安全凭据有以下几种常见类型，用户可以根据不同使用场景选择生成不同类型的安全凭证，配置在持续集成任务中：
用户名 + 密码
用户在登录第三方平台或应用时，都需要注册并登录。例如如果用户想要在代码托管平台上托管自己的代码，需要用邮箱完成注册。注册完毕后，邮箱 + 密码的形式给用户提供了自己参与的项目访问和代码改动权限。
SSH 公私钥对
公私钥对顾名思义由一对公钥和私钥组成，它们的关系是一一对应的。由公钥加密的信息可以通过私钥解析，反之亦然。信息接收方为信息发送方提供公钥，并自己保存私钥。信息提供方将信息通过公钥加密，发送给信息接收方，信息接收方再用私钥解析加密信息。例如用户在本地生成一对公私钥，将公钥传送到代码托管平台上。在拉取平台上的代码时，代码托管平台通过公钥将信息加密，传送给用户，用户再用私钥解密信息，成功将代码拉取到本地。
访问令牌
访问令牌是一种定义用户的权限信息的安全凭据，信息所有者可以在创建访问令牌时设定令牌的权限范围和有效期限等。例如代码托管平台的仓库管理员可以为某一个仓库创建一年之内的访问令牌，获得令牌的用户可以通过用户名 + 访问令牌的方式拉取该仓库的代码。
证书
证书是对信息所有者的身份证明。证书内容通常包括一对公私钥对中的公钥信息和私钥拥有者的身份信息。例如安卓平台要求应用开发者使用数字证书对其发布的应用进行签名，以此保证应用后续更新是来自应用开发者。
API 密钥
API 密钥由 Access Key ID 和 Access Key Secret 组成，用于识别正在调用云平台上 API 的请求方项目。云 API 密钥通常由云平台颁发给云主机所有者，提供了项目识别和检验项目授权的功能。它与上述安全凭证的区别是 API 密钥验证的是调用方项目（应用或网站），而其他安全凭证验证的是正在使用应用或网站的用户。
如何利用 CODING DevOps 恰当的管理安全凭据
一个项目中可能需要跟多个第三方平台进行交互，并且包含多个持续集成构建计划，这会涉及到许多包含重要敏感信息的安全凭据。直接在持续集成任务的配置文件中保存安全凭据会有极大的安全隐患。为了最大程度的保证安全凭据的安全性和管理便捷性，CODING DevOps 提供了项目安全凭据管理功能，您可以将安全凭据储存在 CODING 项目凭据管理系统中。在使用凭据时，您只需要将 CODING 生成的凭据 ID 写入到相关的配置文件中，持续集成任务就可以通过凭据 ID 获得凭据信息。
下图展示了使用 CODING 凭据管理前后持续集成任务获取安全凭据的不同流程：
CODING DevOps 凭据管理列表
对项目的凭据管理可以从项目页面右下角【项目设置】-> 【开发者选项】->【凭据管理】进入凭据管理列表。在列表中，您可以看到您的项目关联的所有凭据，并迅速了解凭据大致情况：
凭据使用示例
下面我们以【SSH 公私钥对】类型的凭据为例，为您演示如何在持续集成中管理您的安全凭据。
步骤一： 使用命令创建 SSH 密钥
在控制台使用命令创建 SSH 密钥。
ssh-keygen -m PEM -t rsa -b 4096 -C "your.email@example.com"步骤二：将生成的公钥录入个人设置中
在控制台查看生成的公钥，并复制 ssh-rsa 及其之后的内容（包含 ssh-rsa）。
cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDXFNt7NvSZDR+c/CZ59SqYudCwOTNphpNi+qlp22eh
...进入【个人设置】-> 【SSH 公钥】，点击【新增公钥】。
将复制的内容粘贴到公钥内容中。
步骤三：将生成的私钥录入凭据管理中
在控制台查看生成的私钥并复制。注意私钥第一行应包含 “BEGIN RSA PRIVATE KEY”，否则后续使用时可能会报错 “invalid private key”。
cat ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAACFwAAAAdzc2gtcn
...从项目页面右下角【项目设置】-> 【开发者选项】->【凭据管理】进入凭据管理列表，点击【录入凭据】，在【SSH 私钥内容】中粘贴私钥。
在【凭据授权】中选择授权的构建计划。然后点击【创建】。
步骤四：将生成的 Credential ID 配置到持续集成计划中
创建凭据成功后，回到凭据列表，复制生成的 Credential ID。
进入【持续集成】，新建构建计划或选择想要配置安全凭证的构建计划，进入配置流程。在对应的环境变量名中输入新生成的 Credential ID。
配置完成后，就可以安全的执行构建计划。
总结
在本次介绍中，我们了解了什么是安全凭据以及如何恰当地在持续集成中管理安全凭据的重要性。CODING DevOps 的凭据管理功能可以帮助我们安全、高效地管理项目内的安全凭据。
参考链接。
最近更新在阅读中是否遇到以下问题？
您希望我们如何改进？