使用 AWS CLI 安全管理凭证的最佳实践

了解保护您的 AWS CLI 凭证的权威最佳实践。本指南涵盖凭证加载顺序、配置文件的正确使用、环境变量,以及至关重要的如何利用 IAM 角色和 AWS SSO 来消除存储长期静态访问密钥的风险。实施这些策略,可在您的 AWS 自动化和管理工作流中实现强大的安全性。

37 浏览量

使用 AWS CLI 安全管理凭证的最佳实践

通过命令行界面 (CLI) 与 Amazon Web Services (AWS) 交互时,安全管理凭证至关重要。访问密钥(访问密钥 ID 和私有访问密钥)授予对云资源的编程访问权限,因此它们的泄露会带来重大的安全风险。本文概述了存储、管理和使用这些凭证的关键最佳实践,以最大程度地减少泄露并保持强大的安全态势,无论是在自动化任务还是通过 CLI 管理资源时。

AWS CLI 依赖特定的方法来查找凭证。了解这些方法——从配置文件到环境变量和 IAM 角色——是保护您的环境的第一步。我们将探讨推荐的优先级顺序,并强调比硬编码秘密更现代化、更安全的替代方案。

了解 AWS CLI 凭证加载顺序

AWS CLI 使用定义的层次结构来解析凭证。了解此顺序有助于您理解 CLI 首先在哪里查找凭证,并确保您预期中最安全的配置具有优先权。

CLI 按以下顺序(从最高优先级到最低优先级)检查凭证:

  1. 命令行选项: 通过标志 (--access-key-id--secret-access-key) 直接传递的凭证。
  2. 环境变量: 在当前 shell 会话中设置的凭证。
  3. 凭证进程: 来自配置的凭证进程的输出(通常由 SSO 或外部工具使用)。
  4. AWS 凭证提供商链: 此链按以下顺序检查:
    a. 分配给正在运行的 EC2 实例或 ECS 任务的 IAM 角色中的凭证。
    b. 存储在共享凭证文件 (~/.aws/credentials) 中的凭证。
  5. 配置文件: 如果未找到凭证,CLI 将停止搜索。

安全提示: 通常不建议在日常使用中依赖命令行标志,因为命令历史记录 (.bash_history) 可能会暴露敏感信息。

1. 在配置文件中保护凭证 (~/.aws/credentials)

默认情况下,AWS CLI 将凭证存储在共享凭证文件(通常位于 ~/.aws/credentials)中。虽然方便,但此文件必须受到保护。

文件保护和权限

限制对此文件的读取访问权限至关重要。在 Linux/macOS 系统上,设置权限以确保只有所有者可以读取或写入文件:

chmod 600 ~/.aws/credentials

使用配置文件进行隔离

使用不同的配置文件允许您为不同的环境(例如,开发、预生产、生产)或不同的账户分离凭证。这可以防止意外的跨环境操作。

~/.aws/credentials 示例:

[default]
aws_access_key_id = AKIABCDEFGHIJKLMNO
aws_secret_access_key = xYzdEfGhIjKlMnOpQrStUvWxYz1234567890

[production-user]
aws_access_key_id = AKIA9876543210ZYXWVU
aws_secret_access_key = aBcDeFgHiJkLmNoPqRsTuVwXyZ9876543210

使用命名配置文件时,必须使用 --profile 标志指定它:

aws s3 ls --profile production-user

2. 利用环境变量

环境变量提供了一种动态方式来向 CLI 会话提供凭证,而无需将它们写入磁盘。这通常是临时访问或在磁盘写入受限或不需要的脚本环境中的首选方法。

在您的 shell 会话中设置以下变量:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_DEFAULT_REGION="us-east-1"

关于优先级的说明: 通过环境变量设置的凭证始终会覆盖~/.aws/credentials 文件中找到的凭证,因为它们在凭证加载链中的优先级更高。

安全警告: 在导出环境变量时要小心,尤其是在共享终端或可能被记录的脚本中。使用后务必立即取消设置:
bash unset AWS_ACCESS_KEY_ID unset AWS_SECRET_ACCESS_KEY

3. 最安全的方案:IAM 角色(实例配置文件/Web 身份)

对于在 AWS 基础设施运行的工作负载(例如 EC2 实例、Lambda 函数或 ECS 任务),最安全的做法是永不使用静态凭证。相反,应使用 IAM 角色。

IAM 角色允许您通过实例元数据服务向资源分配临时的、自动轮换的安全凭证。AWS CLI 会自动检测并使用这些凭证,而无需将它们存储在磁盘上或环境变量中。

工作原理:

  1. 启动一个关联了 IAM 角色的 EC2 实例。
  2. 在该实例上运行的 CLI 会查询实例元数据服务 (IMDS) 以获取临时凭证。
  3. CLI 将这些临时凭证用于所有后续的 API 调用。

这完全消除了与长期访问密钥相关的风险。

4. 利用凭证进程和 SSO

现代凭证管理越来越依赖外部身份验证提供商,通常通过 credential_process 配置进行集成。

AWS SSO (单点登录)

AWS SSO 提供了一种统一的方式,可使用现有的身份提供商 (IdP) 管理跨多个账户和角色的访问。AWS CLI 与 SSO 无缝集成,抽象化了临时会话令牌的管理。

要开始使用 SSO,您首先执行登录命令:

aws sso login --profile <profile-name>

这将打开一个浏览器窗口进行身份验证。成功后,CLI 会存储必要的会话令牌,通常在内部利用 credential_process 机制自动刷新令牌,这意味着您无需处理原始的私有密钥。

配置 credential_process

您可以将 CLI 配置为调用外部工具(如 vault 代理或 SSO 辅助程序)以动态获取凭证。这在配置文件中指定:

~/.aws/config 示例:

[profile my-vault-profile]
region = us-west-2
credential_process = /usr/local/bin/my-vault-cli get-aws-creds --profile my-vault-profile

当与 HashiCorp Vault 等秘密管理工具集成时,此方法至关重要。

最佳实践总结与清单

为了最大程度地提高 AWS CLI 操作的安全性,请遵循以下核心原则:

  • 最小权限原则: 确保所有 IAM 用户和角色仅具有执行其工作所严格必需的权限。
  • 优先使用角色而非密钥: 在 AWS 基础设施内部操作时,始终使用 IAM 角色(实例配置文件)。
  • 使用 SSO: 对于人工交互使用,利用 AWS SSO 管理对多个账户的访问。
  • 切勿硬编码密钥: 避免将访问密钥直接放入脚本、源代码或命令历史记录中。
  • 保护凭证文件: 限制 ~/.aws/credentials 上的文件系统权限 (chmod 600)。
  • 定期轮换密钥: 如果必须使用静态密钥,请强制执行严格的轮换计划。

通过优先考虑 IAM 角色和 SSO 等动态凭证获取方法,而不是存储在磁盘上的静态访问密钥,您可以显著减少与 AWS CLI 使用相关的攻击面。