本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 安全性 AWS CodePipeline 云安全 AWS 是重中之重。作为 AWS 客户，您可以受益于专为满足大多数安全敏感型组织的要求而构建的数据中心和网络架构。 安全是双方共同承担 AWS 的责任。[责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)将其描述为云*的*安全性和云*中*的安全性： + **云安全** — AWS 负责保护在云中运行 AWS 服务的基础架构 AWS 云。 AWS 还为您提供可以安全使用的服务。作为[AWS 合规计划合规计划合规计划合](https://aws.amazon.com/compliance/programs/)的一部分，第三方审计师定期测试和验证我们安全的有效性。要了解适用的合规计划 AWS CodePipeline，请参阅按合规计划划分的[范围内的AWSAWS 服务按合规计划](https://aws.amazon.com/compliance/services-in-scope/)。 + **云端安全**-您的责任由您使用的 AWS 服务决定。您还需要对其它因素负责，包括您的数据的敏感性、您公司的要求以及适用的法律法规。 本文档可帮助您了解在使用时如何应用分担责任模型 CodePipeline。以下主题向您介绍如何进行配置 CodePipeline 以满足您的安全和合规性目标。您还将学习如何使用其他 AWS 服务来帮助您监控和保护您的 CodePipeline 资源。 **Topics** + [中的数据保护 AWS CodePipeline](data-protection.md) + [的身份和访问管理 AWS CodePipeline](security-iam.md) + [登录和监控 CodePipeline](incident-response.md) + [合规性验证 AWS CodePipeline](compliance-validation.md) + [韧性在 AWS CodePipeline](disaster-recovery-resiliency.md) + [中的基础设施安全 AWS CodePipeline](infrastructure-security.md) + [安全最佳实践](security-best-practices.md) # 中的数据保护 AWS CodePipeline 分 AWS [担责任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)适用于中的数据保护。如本模型所述 AWS ，负责保护运行所有内容的全球基础架构 AWS 云。您负责维护对托管在此基础结构上的内容的控制。您还负责您所使用的 AWS 服务 的安全配置和管理任务。有关数据隐私的更多信息，请参阅[数据隐私常见问题](https://aws.amazon.com/compliance/data-privacy-faq/)。有关欧洲数据保护的信息，请参阅 *AWS Security Blog* 上的 [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 博客文章。 出于数据保护目的，我们建议您保护 AWS 账户 凭证并使用 AWS IAM Identity Center 或 AWS Identity and Access Management (IAM) 设置个人用户。这样，每个用户只获得履行其工作职责所需的权限。还建议您通过以下方式保护数据： + 对每个账户使用多重身份验证（MFA）。 + 用于 SSL/TLS 与 AWS 资源通信。我们要求使用 TLS 1.2，建议使用 TLS 1.3。 + 使用设置 API 和用户活动日志 AWS CloudTrail。有关使用 CloudTrail 跟踪捕获 AWS 活动的信息，请参阅《*AWS CloudTrail 用户指南》*中的[使用跟 CloudTrail 踪](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)。 + 使用 AWS 加密解决方案以及其中的所有默认安全控件 AWS 服务。 + 使用高级托管安全服务（例如 Amazon Macie），它有助于发现和保护存储在 Amazon S3 中的敏感数据。 + 如果您在 AWS 通过命令行界面或 API 进行访问时需要经过 FIPS 140-3 验证的加密模块，请使用 FIPS 端点。有关可用的 FIPS 端点的更多信息，请参阅《美国联邦信息处理标准（FIPS）第 140-3 版》[https://aws.amazon.com/compliance/fips/](https://aws.amazon.com/compliance/fips/)。 强烈建议您切勿将机密信息或敏感信息（如您客户的电子邮件地址）放入标签或自由格式文本字段（如**名称**字段）。这包括您使用控制台、API 或以其他 AWS 服务 方式使用控制台 AWS CLI、API 或时 AWS SDKs。在用于名称的标签或自由格式文本字段中输入的任何数据都可能会用于计费或诊断日志。如果您向外部服务器提供 URL，强烈建议您不要在网址中包含凭证信息来验证对该服务器的请求。 下面的安全最佳实践也探讨 CodePipeline 中的数据保护： + [为存储在 Amazon S3 中的项目配置服务器端加密 CodePipeline](S3-artifact-encryption.md) + [AWS Secrets Manager 用于跟踪数据库密码或第三方 API 密钥](parameter-store-encryption.md) ## 互联网络流量隐私 Amazon VPC 可用于在您定义的虚拟网络（*虚拟私有云*）中启动 AWS 资源。 AWS 服务 CodePipeline支持由 AWS PrivateLink提供支持的 Amazon VPC 终端节点，该 AWS 技术可促进 AWS 服务 使用弹性网络接口与私有 IP 地址之间的私密通信。这意味着您可以 CodePipeline 通过 VPC 中的私有终端节点直接连接，从而将所有流量保留在您的 VPC 和 AWS 网络内。以前，在 VPC 内运行的应用程序需要 Internet 访问权限才能连接到 CodePipeline。利用 VPC，您可以控制网络设置，例如： + IP 地址范围 + 子网 + 路由表 + 网络网关。 要将您的 VPC 连接到 CodePipeline，您需要为定义接口 VPC 终端节点 CodePipeline。这类端点使您能够将自己的 VPC 连接到 AWS 服务。该端点 CodePipeline 无需互联网网关、网络地址转换 (NAT) 实例或 VPN 连接即可提供可靠、可扩展的连接。有关设置 VPC 的信息，请参阅 [VPC 用户指南](https://docs.aws.amazon.com/vpc/latest/userguide/)。 ## 静态加密 中的 CodePipeline 数据使用进行静态加密 AWS KMS keys。代码项目存储在客户拥有的 S3 存储桶中，并使用 AWS 托管式密钥 或客户托管密钥进行加密。有关更多信息，请参阅 [为存储在 Amazon S3 中的项目配置服务器端加密 CodePipeline](S3-artifact-encryption.md)。 ## 传输中加密 所有 service-to-service通信在传输过程中均使用 SSL/TLS 进行加密。 ## 加密密钥管理 如果您选择加密代码工件的默认选项，则 CodePipeline 使用。 AWS 托管式密钥您无法更改或删除此内容 AWS 托管式密钥。如果您使用客户托管密钥 AWS KMS 来加密或解密 S3 存储桶中的项目，则可以根据需要更改或轮换此客户托管密钥。 **重要** CodePipeline 仅支持对称 KMS 密钥。请勿使用非对称 KMS 密钥对 S3 桶中的数据进行加密。 **Topics** # 为存储在 Amazon S3 中的项目配置服务器端加密 CodePipeline 可以使用两种方法为 Amazon S3 构件配置服务器端加密： + CodePipeline 创建 S3 工件存储桶， AWS 托管式密钥 当您使用创建管道向导创建管道时会创建默认存储桶。与对象数据一起加密，并由管理 AWS。 AWS 托管式密钥 + 您可以创建和管理自己的客户管理的密钥。 **重要** CodePipeline 仅支持对称 KMS 密钥。请勿使用非对称 KMS 密钥对 S3 桶中的数据进行加密。 如果使用默认的 S3 密钥，则无法更改或删除此 AWS 托管式密钥。如果您使用客户托管密钥 AWS KMS 来加密或解密 S3 存储桶中的项目，则可以根据需要更改或轮换此客户托管密钥。 Amazon S3 支持存储桶策略，如果您要对所有存储在存储桶中的对象执行服务器端加密，则可以使用这些策略。例如，如果请求不包含用于请求服务器端加密（SSE-KMS）的 `s3:PutObject` 标头，则下面的存储桶策略将拒绝所有人的上传对象（`x-amz-server-side-encryption`）权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "SSEAndSSLPolicy", "Statement": [ { "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } }, { "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*", "Condition": { "Bool": { "aws:SecureTransport": "false" } } } ] } ``` ------ 有关服务器端加密的更多信息 AWS KMS，请参阅使用服务器端加密[保护数据和使用存储在 AWS Key Management Service (SSE-](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) [KMS) 中的 KMS 密钥使用服务器端加密保护数据](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)。 有关的更多信息 AWS KMS，请参阅《[AWS Key Management Service 开发人员指南》](https://docs.aws.amazon.com/kms/latest/developerguide/)。 **Topics** + [查看你的 AWS 托管式密钥](#S3-view-default-keys) + [使用 CloudFormation 或，为 S3 存储桶配置服务器端加密 AWS CLI](#S3-rotate-customer-key) ## 查看你的 AWS 托管式密钥 当您使用**创建管道**向导创建第一个管道时，系统将在您创建管道的同一区域为您创建一个 S3 存储桶。存储桶用于存储管道项目。当管道运行时，构件会放入 S3 存储桶并从中检索。默认情况下， CodePipeline 使用服务器端加密，并 AWS KMS 使用 AWS 托管式密钥 适用于 Amazon S3 的（`aws/s3`密钥）。 AWS 托管式密钥 这已创建并存储在您的 AWS 账户中。从 S3 存储桶检索项目时， CodePipeline 使用相同的 SSE-KMS 进程解密该项目。 **查看有关您的信息 AWS 托管式密钥** 1. 登录 AWS 管理控制台 并打开 AWS KMS 控制台。 1. 如果出现欢迎页面，请选择**立即开始使用**。 1. 在服务导航窗格中，选择**AWS 托管式密钥**。 1. 选择您的管道所在的区域。例如，如果管道是在 `us-east-2` 中创建的，则确保将筛选条件设为美国东部（俄亥俄州）。 有关可用区域和终端节点的更多信息 CodePipeline，请参阅终[AWS CodePipeline 端节点和配额](https://docs.aws.amazon.com/general/latest/gr/codepipeline.html)。 1. 在列表中，选择包含管道所用别名的密钥（默认情况下为 **aws/s3**）。有关该密钥的基本信息将会显示。 ## 使用 CloudFormation 或，为 S3 存储桶配置服务器端加密 AWS CLI 使用 CloudFormation 或创建管道时，必须手动配置服务器端加密。 AWS CLI 使用上面的示例存储桶策略，然后创建您自己的客户自主管理型密钥。您也可以使用自己的密钥，而不是 AWS 托管式密钥。选择自己的密钥的一些理由包括： + 您希望按时间表轮换密钥以满足贵组织的业务或安全要求。 + 您要创建一个使用与另一个 AWS 账户关联的资源的管道。这需要使用客户管理的密钥。有关更多信息，请参阅 [在中 CodePipeline 创建使用其他 AWS 账户资源的管道](pipelines-create-cross-account.md)。 加密最佳实践建议不要广泛重复使用加密密钥。作为最佳实践，请定期轮换您的密钥。要为您的 AWS KMS 密钥创建新的加密材料，您可以创建客户托管密钥，然后更改应用程序或别名以使用新的客户托管密钥。或者，您可以为现有客户管理的密钥启用自动密钥轮换。 要轮换客户管理的密钥，请参阅[轮换密钥](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)。 **重要** CodePipeline 仅支持对称 KMS 密钥。请勿使用非对称 KMS 密钥对 S3 桶中的数据进行加密。 # AWS Secrets Manager 用于跟踪数据库密码或第三方 API 密钥 我们建议您使用 AWS Secrets Manager 在数据库凭证、API 密钥和其他**密**钥的整个生命周期中轮换、管理和检索它们。Secrets Manager 使您可以将代码中的硬编码凭证（包括密码）替换为对 Secrets Manager 的 API 调用，以便以编程方式检索密钥。有关更多信息，请参阅[什么是 S AWS ecrets Manager？](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 在 S *AWS ecrets Manager 用户指南*中。 对于在模板中传递作为机密的参数（例如 OAuth 证书）的管道，您应在 CloudFormation 模板中包含用于访问存储在 Secrets Manager 中的密钥的动态引用。有关引用 ID 模式和示例，请参阅 *AWS CloudFormation 用户指南* 中的 [Secrets Manager 密钥](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-secretsmanager)。有关在管道中 web GitHub hook 的模板片段中使用动态引用的示例，请参阅 [Webhook 资源配置](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-webhook.html#aws-resource-codepipeline-webhook--examples)。 ## 另请参阅 下列相关资源可以帮助您管理密钥。 + Secrets Manager 可以自动轮换数据库凭证，例如用于轮换 Amazon RDS 密钥。有关更多信息，请参阅 S [AWS ecrets Manager 用户指南中的轮换](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) *S AWS ecrets Manager 密钥*。 + 要查看有关向 CloudFormation 模板添加 Secrets Manager 动态引用的说明，请参阅 [https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/](https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/)。 # 的身份和访问管理 AWS CodePipeline AWS Identity and Access Management (IAM) AWS 服务 可帮助管理员安全地控制对 AWS 资源的访问权限。IAM 管理员控制谁可以*进行身份验证*（登录）和*授权*（拥有权限）使用 CodePipeline 资源。您可以使用 IAM AWS 服务 ，无需支付额外费用。 **Topics** + [受众](#security_iam_audience) + [使用身份进行身份验证](#security_iam_authentication) + [使用策略管理访问](#security_iam_access-manage) + [如何 AWS CodePipeline 与 IAM 配合使用](security_iam_service-with-iam.md) + [AWS CodePipeline 基于身份的策略示例](security_iam_id-based-policy-examples.md) + [AWS CodePipeline 基于资源的策略示例](security_iam_resource-based-policy-examples.md) + [对 AWS CodePipeline 身份和访问进行故障排除](security_iam_troubleshoot.md) + [权限参考](permissions-reference.md) + [管理 CodePipeline 服务角色](how-to-custom-role.md) ## 受众 您的使用方式 AWS Identity and Access Management (IAM) 因您的角色而异： + **服务用户**：如果您无法访问功能，请从管理员处请求权限（请参阅[对 AWS CodePipeline 身份和访问进行故障排除](security_iam_troubleshoot.md)） + **服务管理员**：确定用户访问权限并提交权限请求（请参阅[如何 AWS CodePipeline 与 IAM 配合使用](security_iam_service-with-iam.md)） + **IAM 管理员**：编写用于管理访问权限的策略（请参阅[AWS CodePipeline 基于身份的策略示例](security_iam_id-based-policy-examples.md)） ## 使用身份进行身份验证 身份验证是您 AWS 使用身份凭证登录的方式。您必须以 IAM 用户身份进行身份验证 AWS 账户根用户，或者通过担任 IAM 角色进行身份验证。 您可以使用来自身份源的证书 AWS IAM Identity Center （例如（IAM Identity Center）、单点登录身份验证或 Google/Facebook 证书，以联合身份登录。有关登录的更多信息，请参阅《AWS 登录 用户指南》**中的[如何登录您的 AWS 账户](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。 对于编程访问， AWS 提供 SDK 和 CLI 来对请求进行加密签名。有关更多信息，请参阅*《IAM 用户指南》*中的[适用于 API 请求的AWS 签名版本 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)。 ### AWS 账户根用户 创建时 AWS 账户，首先会有一个名为 AWS 账户 *root 用户的*登录身份，该身份可以完全访问所有资源 AWS 服务 和资源。我们强烈建议不要使用根用户进行日常任务。有关要求根用户凭证的任务，请参阅*《IAM 用户指南》*中的[需要根用户凭证的任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 ### IAM 用户和群组 *[IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*是对某个人员或应用程序具有特定权限的一个身份。建议使用临时凭证，而非具有长期凭证的 IAM 用户。有关更多信息，请参阅 *IAM 用户指南*[中的要求人类用户使用身份提供商的联合身份验证才能 AWS 使用临时证书进行访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)。 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)指定一组 IAM 用户，便于更轻松地对大量用户进行权限管理。有关更多信息，请参阅*《IAM 用户指南》*中的 [IAM 用户使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)。 ### IAM 角色 *[IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*是具有特定权限的身份，可提供临时凭证。您可以通过[从用户切换到 IAM 角色（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)或调用 AWS CLI 或 AWS API 操作来代入角色。有关更多信息，请参阅《IAM 用户指南》**中的[担任角色的方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)。 IAM 角色对于联合用户访问、临时 IAM 用户权限、跨账户访问、跨服务访问以及在 Amazon EC2 上运行的应用程序非常有用。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 ## 使用策略管理访问 您可以 AWS 通过创建策略并将其附加到 AWS 身份或资源来控制中的访问权限。策略定义了与身份或资源关联时的权限。 AWS 在委托人提出请求时评估这些政策。大多数策略都以 JSON 文档的 AWS 形式存储在中。有关 JSON 策略文档的更多信息，请参阅*《IAM 用户指南》*中的 [JSON 策略概述](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)。 管理员使用策略，通过定义哪个**主体**可以在什么**条件**下对哪些**资源**执行哪些**操作**来指定谁有权访问什么。 默认情况下，用户和角色没有权限。IAM 管理员创建 IAM 策略并将其添加到角色中，然后用户可以担任这些角色。IAM 策略定义权限，与执行操作所用的方法无关。 ### 基于身份的策略 基于身份的策略是您附加到身份（用户、组或角色）的 JSON 权限策略文档。这些策略控制身份可以执行什么操作、对哪些资源执行以及在什么条件下执行。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。 基于身份的策略可以是*内联策略*（直接嵌入到单个身份中）或*托管策略*（附加到多个身份的独立策略）。要了解如何在托管策略和内联策略之间进行选择，请参阅*《IAM 用户指南》*中的[在托管策略与内联策略之间进行选择](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)。 ### 基于资源的策略 基于资源的策略是附加到资源的 JSON 策略文档。示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。 基于资源的策略是位于该服务中的内联策略。您不能在基于资源的策略中使用 IAM 中的 AWS 托管策略。 ### 其他策略类型 AWS 支持其他策略类型，这些策略类型可以设置更常见的策略类型授予的最大权限： + **权限边界** – 设置基于身份的策略可以授予 IAM 实体的最大权限。有关更多信息，请参阅《 IAM 用户指南》**中的 [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。 + **服务控制策略 (SCPs)**-在中指定组织或组织单位的最大权限 AWS Organizations。有关更多信息，请参阅《AWS Organizations 用户指南》**中的[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。 + **资源控制策略 (RCPs)**-设置账户中资源的最大可用权限。有关更多信息，请参阅《*AWS Organizations 用户指南》*中的[资源控制策略 (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。 + **会话策略** – 在为角色或联合用户创建临时会话时，作为参数传递的高级策略。有关更多信息，请参阅《IAM 用户指南》**中的[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。 # 如何 AWS CodePipeline 与 IAM 配合使用 在使用 IAM 管理访问权限之前 CodePipeline，您应该了解哪些可用的 IAM 功能 CodePipeline。要全面了解如何使用 IAM CodePipeline 以及其他方法 AWS 服务 ，请参阅AWS 服务 IAM *用户指南中的如何[与 I](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) AM* 配合使用。 **Topics** + [CodePipeline 基于身份的策略](#security_iam_service-with-iam-id-based-policies) + [CodePipeline 基于资源的政策](#security_iam_service-with-iam-resource-based-policies) + [基于 CodePipeline 标签的授权](#security_iam_service-with-iam-tags) + [CodePipeline IAM 角色](#security_iam_service-with-iam-roles) ## CodePipeline 基于身份的策略 使用 IAM 基于身份的策略，您可以指定允许或拒绝的操作和资源，以及指定在什么条件下允许或拒绝操作。 CodePipeline 支持特定操作、资源和条件键。要了解在 JSON 策略中使用的所有元素，请参阅《IAM 用户指南》** 中的 [IAM JSON 策略元素参考](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)。 ### 操作 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。在策略中包含操作以授予执行关联操作的权限。 正在执行的策略操作在操作前 CodePipeline 使用以下前缀:`codepipeline:`. 例如，要授予某人查看账户中现有管道的权限，您可以在其策略中包括 `codepipeline:GetPipeline` 操作。策略声明必须包含`Action`或`NotAction`元素。 CodePipeline 定义了它自己的一组操作，这些操作描述了您可以使用此服务执行的任务。 要在单个语句中指定多项操作，请使用逗号将它们隔开，如下所示： ``` "Action": [ "codepipeline:action1", "codepipeline:action2" ``` 您也可以使用通配符 （\$1) 指定多个操作。例如，要指定以单词 `Get` 开头的所有操作，包括以下操作： ``` "Action": "codepipeline:Get*" ``` 有关 CodePipeline 操作列表，请参阅 *IAM 用户指南 AWS CodePipeline*中的[由定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions)。 ### 资源 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 `Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于不支持资源级权限的操作，请使用通配符 (\$1) 指示语句应用于所有资源。 ``` "Resource": "*" ``` #### 资源和运营 在 中，主要资源为管道。在策略中，您可以使用 Amazon 资源名称 (ARN) 标识策略应用到的资源。 支持可以与主要资源一起使用的其他资源，例如阶段、操作和自定义操作。这些资源称作子资源。这些资源和子资源具有与之关联的唯一 Amazon 资源名称 (ARNs)。有关更多信息 ARNs，请参阅中的 [Amazon 资源名称 (ARN) 和 AWS 服务 命名空间](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)。*Amazon Web Services 一般参考*要获取与您的管道关联的管道 ARN，您可以在控制台的**设置**下找到管道 ARN。有关更多信息，请参阅 [查看管道 ARN 和服务角色 ARN（控制台）](pipelines-settings-console.md)。 | 资源类型 | ARN 格式 | | --- | --- | | 管道 | arn: aws: codepiline::: *region* *account* *pipeline-name* | | 暂存区 | arn: aws: codepipeline:::/*region**account**pipeline-name**stage-name* | | Action | arn: aws: codepipeline:::/*region**account**pipeline-name**stage-name**action-name* | | 自定义操作 | arn: aws: codepipeline::: actiontype:///regionaccountownercategoryproviderversion | | 所有资源 | arn:aws:codepipeline:\$1 | | 指定账户在指定区域拥有的所有 资源 | arn: aws: codepiline::: \$1 *region* *account* | **注意** 中的大多数服务都 AWS 将冒号 (:) 或正斜杠 (/) 视为中的 ARNs相同字符。不过， 在事件模式和规则中使用精确匹配。请在创建事件模式时务必使用正确的 ARN 字符，以使其匹配需要匹配的管道中的 ARN 语法。 在 中，有支持资源级权限的 API 调用。资源级权限指示 API 调用是否可以指定资源 ARN，或者 API 调用是否只能使用通配符指定所有资源。[权限参考](permissions-reference.md)有关资源级权限的详细说明以及支持资源级权限的 CodePipeline API 调用的列表，请参阅。 例如，您可以在语句中使用其 ARN 来表示特定的管道 (*myPipeline*)，如下所示： ``` "Resource": "arn:aws:codepipeline:us-east-2:111222333444:myPipeline" ``` 还可以使用通配符（\$1）指定属于特定账户的所有管道，如下所示： ``` "Resource": "arn:aws:codepipeline:us-east-2:111222333444:*" ``` 要指定所有资源，或者如果特定 API 操作不支持 ARNs，请在`Resource`元素中使用 (\$1) 通配符，如下所示： ``` "Resource": "*" ``` **注意** 在您创建 IAM 策略时，请遵循授予最低权限这一标准安全建议，即仅授予执行任务所需的权限。如果 API 调用支持 ARNs，则它支持资源级权限，您无需使用 (\$1) 通配符。 某些 API 调用接受多个资源（例如`GetPipeline`）。要在单个语句中指定多个资源，请 ARNs 用逗号分隔它们，如下所示： ``` "Resource": ["arn1", "arn2"] ``` 提供了一组使用资源的操作。有关可用操作的列表，请参阅 [权限参考](permissions-reference.md)。 ### 条件键 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 `Condition` 元素根据定义的条件指定语句何时执行。您可以创建使用[条件运算符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)（例如，等于或小于）的条件表达式，以使策略中的条件与请求中的值相匹配。要查看所有 AWS 全局条件键，请参阅 *IAM 用户指南*中的[AWS 全局条件上下文密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。 CodePipeline 定义自己的条件键集，还支持使用一些全局条件键。要查看所有 AWS 全局条件键，请参阅 *IAM 用户指南*中的[AWS 全局条件上下文密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。 所有 Amazon EC2 操作都支持 `aws:RequestedRegion` 和 `ec2:Region` 条件键。有关更多信息，请参阅[示例：限制对特定区域的访问](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)。 要查看 CodePipeline 条件键列表，请参阅 *IAM 用户指南 AWS CodePipeline*中的[条件密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys)。要了解您可以使用条件键的操作和资源，请参阅[操作定义者 AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions)。 ### 示例 要查看 CodePipeline 基于身份的策略的示例，请参阅。[AWS CodePipeline 基于身份的策略示例](security_iam_id-based-policy-examples.md) ## CodePipeline 基于资源的政策 CodePipeline 不支持基于资源的策略。但是，提供了与之相关的 S3 服务的基于资源的策略示例。 CodePipeline ### 示例 要查看 CodePipeline 基于资源的策略的示例，请参阅 [AWS CodePipeline 基于资源的策略示例](security_iam_resource-based-policy-examples.md) ## 基于 CodePipeline 标签的授权 您可以为 CodePipeline 资源附加标签或在请求中传递标签 CodePipeline。要基于标签控制访问，您需要使用 `codepipeline:ResourceTag/key-name``aws:RequestTag/key-name` 或 `aws:TagKeys` 条件键在策略的[条件元素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)中提供标签信息。有关标记 CodePipeline 资源的更多信息，请参阅 [为资源添加标签](tag-resources.md) 要查看基于身份的策略（用于根据资源上的标签来限制对该资源的访问）的示例，请参阅 [使用标签控制对 CodePipeline 资源的访问权限](tag-based-access-control.md)。 ## CodePipeline IAM 角色 I [AM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)是您的 AWS 账户中具有特定权限的实体。 ### 将临时凭证与配合使用 CodePipeline 可以使用临时凭证进行联合身份验证登录，分派 IAM 角色或分派跨账户角色。您可以通过调用[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)或之类的 AWS STS API 操作来获取临时安全证书[GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)。 CodePipeline 支持使用临时证书。 ### 服务角色 CodePipeline 允许服务代表您担任[服务角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role)。此角色允许服务访问其他服务中的资源以代表您完成操作。服务角色显示在 IAM 账户中，并归该账户所有。这意味着，IAM 管理员可以更改该角色的权限。但是，这样做可能会中断服务的功能。 CodePipeline 支持服务角色。 # AWS CodePipeline 基于身份的策略示例 默认情况下，IAM 用户和角色没有创建或修改 CodePipeline 资源的权限。他们也无法使用 AWS 管理控制台 AWS CLI、或 AWS API 执行任务。IAM 管理员必须创建 IAM 策略，以便为用户和角色授予权限以对所需的指定资源执行特定的 API 操作。然后，管理员必须将这些策略附加到需要这些权限的 IAM 用户或组。 要了解如何使用这些示例 JSON 策略文档创建 IAM 基于身份的策略，请参阅*《IAM 用户指南》*中的 [在 JSON 选项卡上创建策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)。 要了解如何创建使用其它账户资源的管道以及相关的示例策略，请参阅[在中 CodePipeline 创建使用其他 AWS 账户资源的管道](pipelines-create-cross-account.md)。 **Topics** + [策略最佳实践](security_iam_service-with-iam-policy-best-practices.md) + [在控制台中查看资源](security-iam-resources-console.md) + [允许用户查看他们自己的权限](security_iam_id-based-policy-examples-view-own-permissions.md) + [基于身份的策略 (IAM) 示例](security-iam-id-policies-examples.md) + [使用标签控制对 CodePipeline 资源的访问权限](tag-based-access-control.md) + [使用控制台所需的权限](security-iam-permissions-console.md) + [在控制台中查看计算日志所需的权限](security-iam-permissions-console-logs.md) + [AWS 的托管策略 AWS CodePipeline](managed-policies.md) + [客户管理型策略示例](#customer-managed-policies) # 策略最佳实践 基于身份的策略决定了某人是否可以在您的账户中创建、访问或删除 CodePipeline 资源。这些操作可能会使 AWS 账户产生成本。创建或编辑基于身份的策略时，请遵循以下指南和建议： + **开始使用 AWS 托管策略并转向最低权限权限** — 要开始向用户和工作负载授予权限，请使用为许多常见用例授予权限的*AWS 托管策略*。它们在你的版本中可用 AWS 账户。我们建议您通过定义针对您的用例的 AWS 客户托管策略来进一步减少权限。有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)或[工作职能的AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。 + **应用最低权限**：在使用 IAM 策略设置权限时，请仅授予执行任务所需的权限。为此，您可以定义在特定条件下可以对特定资源执行的操作，也称为*最低权限许可*。有关使用 IAM 应用权限的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。 + **使用 IAM 策略中的条件进一步限制访问权限**：您可以向策略添加条件来限制对操作和资源的访问。例如，您可以编写策略条件来指定必须使用 SSL 发送所有请求。如果服务操作是通过特定的方式使用的，则也可以使用条件来授予对服务操作的访问权限 AWS 服务，例如 CloudFormation。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。 + **使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性**：IAM Access Analyzer 会验证新策略和现有策略，以确保策略符合 IAM 策略语言（JSON）和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。有关更多信息，请参阅《IAM 用户指南》**中的[使用 IAM Access Analyzer 验证策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。 + **需要多重身份验证 (MFA**)-如果 AWS 账户您的场景需要 IAM 用户或根用户，请启用 MFA 以提高安全性。若要在调用 API 操作时需要 MFA，请将 MFA 条件添加到您的策略中。有关更多信息，请参阅《IAM 用户指南》**中的[使用 MFA 保护 API 访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。 有关 IAM 中的最佳实操的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。 # 在控制台中查看资源 控制台需要`ListRepositories`权限才能在您登录的 AWS 地区显示您的 AWS 账户的存储库列表。该控制台还包括一个**转到资源**功能，可对资源快速执行不区分大小写的搜索。此搜索是在您 AWS 登录所在 AWS 地区的账户中执行的。将显示以下服务中的以下资源： + AWS CodeBuild：构建项目 + AWS CodeCommit：存储库 + AWS CodeDeploy：应用程序 + AWS CodePipeline：管道 要在所有服务中跨资源执行此搜索，您必须具有如下权限： + AWS CodeBuild: `ListProjects` + CodeCommit: `ListRepositories` + CodeDeploy: `ListApplications` + CodePipeline: `ListPipelines` 如果您没有针对某个服务的权限，搜索将不会针对该服务的资源返回结果。即使您有权查看资源，但如果特定资源明确 `Deny` 查看，也不会返回这些资源。 # 允许用户查看他们自己的权限 该示例说明了您如何创建策略，以允许 IAM 用户查看附加到其用户身份的内联和托管式策略。此策略包括在控制台上或使用 AWS CLI 或 AWS API 以编程方式完成此操作的权限。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` # 基于身份的策略 (IAM) 示例 您可以向 IAM 身份附加策略。例如，您可以执行以下操作： + 将@@ **权限策略附加到您账户中的用户或群组**-要授予用户在控制台中查看管道的权限，您可以将权限策略附加到该用户所属的用户或群组。 + **向角色附加权限策略（授予跨账户权限）**：您可以向 IAM 角色附加基于身份的权限策略，以授予跨账户的权限。例如，账户 A 中的管理员可以创建一个角色来向另一个 AWS 账户（例如账户 B）或授予跨账户权限， AWS 服务 如下所示： 1. 账户 A 管理员可以创建一个 IAM 角色，然后向该角色附加授予其访问账户 A 中资源的权限策略。 1. 账户 A 管理员可以把信任策略附加至用来标识账户 B 的角色，账户 B 由此可以作为主体代入该角色。 1. 然后，账户 B 管理员可以将代入该角色的权限委托给账户 B 中的任何用户。这样，账户 B 中的用户就可以创建或访问账户 A 中的资源。如果您想授予担任该角色的 AWS 服务 权限，则信任策略中的 AWS 服务 委托人也可以是委托人。 有关使用 IAM 委托权限的更多信息，请参阅《IAM 用户指南》**中的[访问权限管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)。 下面显示了一个权限策略的示例，该策略可以授权启用和禁用 `us-west-2 region` 区域名为 `MyFirstPipeline` 的管道中所有阶段之间的转换： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : [ "codepipeline:EnableStageTransition", "codepipeline:DisableStageTransition" ], "Resource" : [ "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*" ] } ] } ``` ------ 以下示例显示了 111222333444 账户中的一项策略，该策略允许用户查看但不能更改控制台中命名的管道。`MyFirstPipeline`该策略基于 `AWSCodePipeline_ReadOnlyAccess` 托管策略，但由于它特定于 `MyFirstPipeline` 管道，因此无法直接使用托管策略。如果您不想将策略限制于某特定管道，则应该考虑使用 创建和维护的托管策略之一。有关更多信息，请参阅[使用管理的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html)。您必须将该策略附加到您为进行访问而创建的 IAM 角色，例如名为 `CrossAccountPipelineViewers` 的角色： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "codepipeline:GetPipeline", "codepipeline:GetPipelineState", "codepipeline:GetPipelineExecution", "codepipeline:ListPipelineExecutions", "codepipeline:ListActionExecutions", "codepipeline:ListActionTypes", "codepipeline:ListPipelines", "codepipeline:ListTagsForResource", "iam:ListRoles", "s3:ListAllMyBuckets", "codecommit:ListRepositories", "codedeploy:ListApplications", "lambda:ListFunctions", "codestar-notifications:ListNotificationRules", "codestar-notifications:ListEventTypes", "codestar-notifications:ListTargets" ], "Effect": "Allow", "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline" }, { "Action": [ "codepipeline:GetPipeline", "codepipeline:GetPipelineState", "codepipeline:GetPipelineExecution", "codepipeline:ListPipelineExecutions", "codepipeline:ListActionExecutions", "codepipeline:ListActionTypes", "codepipeline:ListPipelines", "codepipeline:ListTagsForResource", "iam:ListRoles", "s3:GetBucketPolicy", "s3:GetObject", "s3:ListBucket", "codecommit:ListBranches", "codedeploy:GetApplication", "codedeploy:GetDeploymentGroup", "codedeploy:ListDeploymentGroups", "elasticbeanstalk:DescribeApplications", "elasticbeanstalk:DescribeEnvironments", "lambda:GetFunctionConfiguration", "opsworks:DescribeApps", "opsworks:DescribeLayers", "opsworks:DescribeStacks" ], "Effect": "Allow", "Resource": "*" }, { "Sid": "CodeStarNotificationsReadOnlyAccess", "Effect": "Allow", "Action": [ "codestar-notifications:DescribeNotificationRule" ], "Resource": "*", "Condition": { "ArnLike": { "codestar-notifications:NotificationsForResource": "arn:aws:iam::*:role/Service*" } } } ] } ``` ------ 创建此策略后，在 111222333444 账户中创建 IAM 角色，并将策略附加到该角色。在角色的信任关系中，您必须添加将担任此角色的 AWS 账户。以下示例显示了一项策略，该策略允许该*111111111111* AWS 账户中的用户担任在 111222333444 账户中定义的角色： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole" } ] } ``` ------ 以下示例显示了在该*111111111111* AWS 账户中创建的策略，该策略允许用户代入 111222333444 账户*CrossAccountPipelineViewers*中名为的角色： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111222333444:role/CrossAccountPipelineViewers" } ] } ``` ------ 您可以创建 IAM 策略来限制您账户中的用户有权访问的调用和资源，然后将这些策略与管理用户相关联。有关如何创建 IAM 角色以及浏览的 IAM 策略声明示例，请参阅[客户管理型策略示例](security_iam_id-based-policy-examples.md#customer-managed-policies)。 # 使用标签控制对 CodePipeline 资源的访问权限 IAM 策略声明中的条件是您用来指定 CodePipeline 操作所需资源权限的语法的一部分。使用条件中的标签是控制对资源和请求的访问的一种方法。有关为 CodePipeline 资源添加标签的信息，请参阅[为资源添加标签](tag-resources.md)。本主题讨论了基于标签的访问控制。 在设计 IAM 策略时，您可以通过授予对特定资源的访问权限来设置精细权限。但随着您管理的资源数量的增加，此任务会变得日益复杂。标记资源并在策略声明条件中使用标签可以简化这一任务。您可以向具有特定标签的任何资源批量授予访问权限。然后，在创建期间或之后，您可以将此标签反复应用到相关资源。 标签可以附加到资源，也可以从请求传入支持标签的服务。在中 CodePipeline，资源可以有标签，有些操作可以包含标签。在创建 IAM 策略时，您可以使用标签条件键来控制： + 基于资源已有的标签，哪些用户可以对管道资源执行操作。 + 哪些标签可以在操作的请求中传递。 + 特定的标签键是否能在请求中使用。 利用字符串条件运算符，您可以构建基于键与字符串值的对比来限制访问的 `Condition` 元素。除 Null 条件，您可在任何条件运算符名称的末尾添加 `IfExists`。如果您是指“如果请求的内容中存在策略键，则依照策略所述来处理键。如果该键不存在，则条件元素的计算结果将为 true。” 例如，您可以使用 `StringEqualsIfExists` 按条件键进行限制，这些条件键可能不存在于其他类型的资源上。 有关标签条件键的完整请求和语义，请参阅[使用标签控制访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)。有关条件键的更多信息，请参阅以下资源。本节中的 CodePipeline策略示例与以下有关条件键的信息保持一致，并通过 CodePipeline 诸如资源嵌套之类的细微差别示例对其进行扩展。 + [字符串条件运算符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String) + [AWS 服务 可以与 IAM 配合使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) + [SCP 语法](https://docs.aws.amazon.com/IAM/latest/UserGuide/orgs_manage_policies_scps_syntax.html) + [IAM JSON 策略元素：Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) + [aws: RequestTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) + [的条件密钥 CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys) 以下示例演示了如何为 CodePipeline 用户指定策略中的标签条件。 **Example 1：基于请求中的标签限制操作** `AWSCodePipeline_FullAccess`托管用户策略为用户提供了对任何资源执行任何 CodePipeline 操作的无限权限。 以下策略将限制此权力，不允许未经授权的用户在请求中列出特定标签的情况下创建管道。为此，如果请求指定一个名为 `Project` 的带有值为 `ProjectA` 或 `ProjectB` 的标签，则它会拒绝 `CreatePipeline` 操作。（`aws:RequestTag` 条件键用于控制可以通过 IAM 请求传递哪些标签。） 在下面的示例中，该策略的目的是不允许未经授权的用户使用指定的标签值创建管道。但是，创建管道需要访问管道本身之外的资源（例如，管道操作和阶段）。由于策略中指定的 `'Resource'` 是 `'*'`，因此将针对每个具有 ARN 并且在创建管道时创建的资源，评估该策略。这些其他资源没有标签条件键，因此 `StringEquals` 检查会失败，并且不会向用户授予创建任何管道的能力。要解决此问题，请改用 `StringEqualsIfExists` 条件运算符。这样，仅当条件键存在时才会进行测试。 您可能会读到以下内容：“如果所检查的资源具有标签 `"RequestTag/Project"` 条件键，则仅当键值以 `projectA` 开头时允许操作。如果所检查的资源没有改条件键，则无需担心。” 此外，该策略使用 `aws:TagKeys` 条件键，不允许标签修改操作中包含这些相同的标签值，从而防止这些未经授权的用户篡改资源。除托管用户策略外，客户的管理员还必须将此 IAM 策略附加到未经授权的管理用户。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codepipeline:CreatePipeline", "codepipeline:TagResource" ], "Resource": "*", "Condition": { "StringEqualsIfExists": { "aws:RequestTag/Project": ["ProjectA", "ProjectB"] } } }, { "Effect": "Deny", "Action": [ "codepipeline:UntagResource" ], "Resource": "*", "Condition": { "ForAllValues:StringEquals": { "aws:TagKeys": ["Project"] } } } ] } ``` **Example 2：基于资源标签限制标记操作** `AWSCodePipeline_FullAccess`托管用户策略为用户提供了对任何资源执行任何 CodePipeline 操作的无限权限。 以下策略限制此权力并拒绝未经授权的用户具有对指定项目管道执行操作的权限。为此，如果资源具有名为 `Project` 的带有值 `ProjectA` 或 `ProjectB` 之一的标签，那么它会拒绝某些操作。（使用 `aws:ResourceTag` 条件键，基于资源上的标签控制对这些资源的访问。） 除托管用户策略外，客户的管理员还必须将此 IAM 策略附加到未经授权的 IAM 用户。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codepipeline:TagResource" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": ["ProjectA", "ProjectB"] } } } ] } ``` **Example 3：基于请求中的标签允许操作** 以下策略授予用户在 CodePipeline 中创建开发管道的权限。 为此，如果请求指定一个名为 `Project` 的带有值 `ProjectA` 的标签，则它允许 `CreatePipeline` 和 `TagResource` 操作。换句话说，唯一可以指定的标签键是 `Project`，它的值必须是 `ProjectA`。 `aws:RequestTag` 条件键用于控制可以通过 IAM 请求传递哪些标签。`aws:TagKeys` 条件确保标签键区分大小写。对于未附加 `AWSCodePipeline_FullAccess` 托管用户策略的用户或角色，此策略非常有用。托管策略为用户提供了对任何资源执行任何 CodePipeline 操作的无限权限。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:CreatePipeline", "codepipeline:TagResource" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/Project": "ProjectA" }, "ForAllValues:StringEquals": { "aws:TagKeys": ["Project"] } } } ] } ``` **Example 4：基于资源标签限制取消标记操作** `AWSCodePipeline_FullAccess`托管用户策略为用户提供了对任何资源执行任何 CodePipeline 操作的无限权限。 以下策略限制此权力并拒绝未经授权的用户具有对指定项目管道执行操作的权限。为此，如果资源具有名为 `Project` 的带有值 `ProjectA` 或 `ProjectB` 之一的标签，那么它会拒绝某些操作。 此外，该策略使用 `aws:TagKeys` 条件键，不允许标签修改操作完全删除 `Project` 标签，从而防止这些未经授权的用户篡改资源。除托管用户策略外，客户的管理员还必须将此 IAM 策略附加到未经授权的用户或角色。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codepipeline:UntagResource" ], "Resource": "*", "Condition": { "ForAllValues:StringEquals": { "aws:TagKeys": ["Project"] } } } ] } ``` # 使用控制台所需的权限 要在 控制台中使用 ，您必须具有来自以下服务的最小权限集： + AWS Identity and Access Management + Amazon Simple Storage Service 这些权限允许您描述 AWS 账户的其他 AWS 资源。 根据您纳入管道的其他服务，您可能需要来自以下一项或多项的权限： + AWS CodeCommit + AWS CodeBuild + CloudFormation + AWS CodeDeploy + AWS Elastic Beanstalk + AWS Lambda + AWS OpsWorks 如果创建比必需的最低权限更为严格的 IAM 策略，对于附加了该 IAM 策略的用户， 控制台将无法按预期正常运行。要确保这些用户仍可使用控制台，也可向用户附加 `AWSCodePipeline_ReadOnlyAccess` 托管策略，如[AWS 的托管策略 AWS CodePipeline](managed-policies.md)中所述。 您无需为调用 AWS CLI 或 API 的用户设置最低控制台权限。 # 在控制台中查看计算日志所需的权限 要在 CodePipeline 控制台的 “命令” 操作中查看日志，控制台角色必须具有权限。要在控制台中查看日志，请将 `logs:GetLogEvents` 权限添加到控制台角色。 在控制台角色策略声明中，将权限范围缩小到管道级别，如下例所示。 ``` { "Effect": "Allow", "Action": [ "Action": "logs:GetLogEvents" ], "Resource": "arn:aws:logs:*:YOUR_AWS_ACCOUNT_ID:log-group:/aws/codepipeline/YOUR_PIPELINE_NAME:*" } ``` # AWS 的托管策略 AWS CodePipeline AWS 托管策略是由创建和管理的独立策略 AWS。 AWS 托管策略旨在为许多常见用例提供权限，以便您可以开始为用户、组和角色分配权限。 请记住， AWS 托管策略可能不会为您的特定用例授予最低权限权限，因为它们可供所有 AWS 客户使用。我们建议通过定义特定于使用案例的[客户管理型策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)来进一步减少权限。 您无法更改 AWS 托管策略中定义的权限。如果 AWS 更新 AWS 托管策略中定义的权限，则更新会影响该策略所关联的所有委托人身份（用户、组和角色）。 AWS 最有可能在启动新的 API 或现有服务可以使用新 AWS 服务 的 API 操作时更新 AWS 托管策略。 有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。 **重要** 亚马逊云科技托管式策略 `AWSCodePipelineFullAccess` 和 `AWSCodePipelineReadOnlyAccess` 已被替换。使用 `AWSCodePipeline_FullAccess` 和 `AWSCodePipeline_ReadOnlyAccess` 策略。 ## AWS 托管策略：`AWSCodePipeline_FullAccess` 这是一项授予完全访问权限的政策 CodePipeline。要在 IAM 控制台中查看 JSON 策略文档，请参阅[AWSCodePipeline\$1FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_FullAccess)。 **权限详细信息** 该策略包含以下权限。 + `codepipeline`— 向授予权限 CodePipeline。 + `chatbot`：授予权限以允许主体管理聊天应用程序中的 Amazon Q 开发者版中的资源。 + `cloudformation`— 授予权限以允许委托人管理中的资源堆栈。 CloudFormation + `cloudtrail`— 授予权限以允许委托人管理中的日志资源。 CloudTrail + `codebuild`— 授予权限以允许委托人访问中的生成资源。 CodeBuild + `codecommit`— 授予权限以允许委托人访问中的源资源。 CodeCommit + `codedeploy`— 授予权限以允许委托人访问中的部署资源。 CodeDeploy + `codestar-notifications`— 授予权限以允许委托人访问 AWS CodeStar 通知中的资源。 + `ec2`— 授予权限以允许在中进行部署 CodeCatalyst 以管理 Amazon EC2 中的弹性负载平衡。 + `ecr`：授予权限以允许访问 Amazon ECR 中的资源。 + `elasticbeanstalk`：授予权限以允许主体访问 Elastic Beanstalk 中的资源。 + `iam`：授予权限以允许主体管理 IAM 中的角色和策略。 + `lambda`：授予权限以允许主体管理 Lambda 中的资源。 + `events`— 授予权限以允许委托人管理 Ev CloudWatch ents 中的资源。 + `opsworks`— 授予权限以允许委托人管理中的资源。 AWS OpsWorks + `s3`：授予权限以允许主体管理 Amazon S3 中的资源。 + `sns`：授予权限以允许主体管理 Amazon SNS 中的通知资源。 + `states`— 授予权限以允许委托人查看中的状态机。 AWS Step Functions状态机由一组状态组成，这些状态用于管理任务和状态之间的转换。 有关该政策，请参阅[AWSCodePipeline\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_FullAccess.html)。 ## AWS 托管策略：`AWSCodePipeline_ReadOnlyAccess` 这是一项授予只读访问权限的策略 CodePipeline。要在 IAM 控制台中查看 JSON 策略文档，请参阅[AWSCodePipeline\$1ReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_ReadOnlyAccess)。 **权限详细信息** 该策略包含以下权限。 + `codepipeline`— 授予中操作的权限 CodePipeline。 + `codestar-notifications`— 授予权限以允许委托人访问 AWS CodeStar 通知中的资源。 + `s3`：授予权限以允许主体管理 Amazon S3 中的资源。 + `sns`：授予权限以允许主体管理 Amazon SNS 中的通知资源。 有关该政策，请参阅[AWSCodePipeline\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_ReadOnlyAccess.html)。 ## AWS 托管策略：`AWSCodePipelineApproverAccess` 这是一项授予批准或拒绝手动审批操作的权限的策略。要在 IAM 控制台中查看 JSON 策略文档，请参阅[AWSCodePipelineApproverAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineApproverAccess)。 **权限详细信息** 该策略包含以下权限。 + `codepipeline`— 授予中操作的权限 CodePipeline。 有关该政策，请参阅[AWSCodePipelineApproverAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineApproverAccess.html)。 ## AWS 托管策略：`AWSCodePipelineCustomActionAccess` 此政策允许用户在生成或测试操作中创建自定义操作 CodePipeline或集成 Jenkins 资源。要在 IAM 控制台中查看 JSON 策略文档，请参阅[AWSCodePipelineCustomActionAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineCustomActionAccess)。 **权限详细信息** 该策略包含以下权限。 + `codepipeline`— 授予中操作的权限 CodePipeline。 有关该政策，请参阅[AWSCodePipelineCustomActionAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineCustomActionAccess.html)。 ## CodePipeline 托管策略和通知 CodePipeline 支持通知，可以将管道的重要更改通知用户。的托管策略 CodePipeline 包括通知功能的策略声明。有关更多信息，请参阅[什么是通知？](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/welcome.html)。 ### 完全访问托管策略中的通知的相关权限 此托管策略授予相关服务 CodeCommit、 CodeBuild CodeDeploy、和 AWS CodeStar 通知的权限。 CodePipeline 该策略还授予您使用与您的管道集成的其他服务所需的权限，例如 Amazon S3、Elastic B CloudTrail eanstalk、Amazon EC2 和。 CloudFormation应用此托管策略的用户还可以创建和管理用于通知的 Amazon SNS 主题、为用户订阅和取消订阅主题、列出要选择作为通知规则目标的主题，以及列出在聊天应用程序客户端中为 Slack 配置的 Amazon Q 开发者版。 `AWSCodePipeline_FullAccess` 托管策略包含以下语句，以允许对通知进行完全访问。 ``` { "Sid": "CodeStarNotificationsReadWriteAccess", "Effect": "Allow", "Action": [ "codestar-notifications:CreateNotificationRule", "codestar-notifications:DescribeNotificationRule", "codestar-notifications:UpdateNotificationRule", "codestar-notifications:DeleteNotificationRule", "codestar-notifications:Subscribe", "codestar-notifications:Unsubscribe" ], "Resource": "*", "Condition" : { "StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"} } }, { "Sid": "CodeStarNotificationsListAccess", "Effect": "Allow", "Action": [ "codestar-notifications:ListNotificationRules", "codestar-notifications:ListTargets", "codestar-notifications:ListTagsforResource", "codestar-notifications:ListEventTypes" ], "Resource": "*" }, { "Sid": "CodeStarNotificationsSNSTopicCreateAccess", "Effect": "Allow", "Action": [ "sns:CreateTopic", "sns:SetTopicAttributes" ], "Resource": "arn:aws:sns:*:*:codestar-notifications*" }, { "Sid": "SNSTopicListAccess", "Effect": "Allow", "Action": [ "sns:ListTopics" ], "Resource": "*" }, { "Sid": "CodeStarNotificationsChatbotAccess", "Effect": "Allow", "Action": [ "chatbot:DescribeSlackChannelConfigurations", "chatbot:ListMicrosoftTeamsChannelConfigurations" ], "Resource": "*" } ``` ### 只读托管策略中的通知的相关权限 `AWSCodePipeline_ReadOnlyAccess` 托管策略包含以下语句，以允许对通知进行只读访问。应用此策略的用户可以查看资源的通知，但无法创建、管理或订阅这些通知。 ``` { "Sid": "CodeStarNotificationsPowerUserAccess", "Effect": "Allow", "Action": [ "codestar-notifications:DescribeNotificationRule" ], "Resource": "*", "Condition" : { "StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"} } }, { "Sid": "CodeStarNotificationsListAccess", "Effect": "Allow", "Action": [ "codestar-notifications:ListNotificationRules", "codestar-notifications:ListEventTypes", "codestar-notifications:ListTargets" ], "Resource": "*" } ``` 有关 IAM 和通知的更多信息，请参阅 [AWS CodeStar 通知的身份和访问管理](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security-iam.html)。 ## AWS CodePipeline AWS 托管策略的更新 查看 CodePipeline 自该服务开始跟踪这些更改以来 AWS 托管策略更新的详细信息。有关此页面更改的自动提示，请订阅 CodePipeline [ 文档历史记录页面](https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html)上的 RSS 信息源。 | 更改 | 描述 | 日期 | | --- | --- | --- | | [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)— 对现有政策的更新 | CodePipeline 已向该策略添加了支持ListStacks权限 CloudFormation。 | 2024 年 3 月 15 日 | | [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)— 对现有政策的更新 | 本策略已更新，增加了聊天应用程序中的 Amazon Q 开发者版的权限。有关更多信息，请参阅 [CodePipeline 托管策略和通知](#notifications-permissions)。 | 2023 年 6 月 21 日 | | [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)和[AWSCodePipeline\$1ReadOnlyAccess](#security-iam-awsmanpol-AWSCodePipeline_ReadOnlyAccess)托管策略-对现有策略的更新 | CodePipeline 在这些政策中添加了支持在聊天应用程序中使用 Amazon Q Developer 的额外通知类型的权限`chatbot:ListMicrosoftTeamsChannelConfigurations`。 | 2023 年 5 月 16 日 | | **AWSCodePipelineFullAccess**：已弃用 | 此策略已被 `AWSCodePipeline_FullAccess` 取代。 2022 年 11 月 17 日之后，该策略不能附加到任何新的用户、组或角色。有关更多信息，请参阅 [AWS 的托管策略 AWS CodePipeline](#managed-policies)。 | 2022 年 11 月 17 日 | | **AWSCodePipelineReadOnlyAccess**：已弃用 | 此策略已被 `AWSCodePipeline_ReadOnlyAccess` 取代。 2022 年 11 月 17 日之后，该策略不能附加到任何新的用户、组或角色。有关更多信息，请参阅 [AWS 的托管策略 AWS CodePipeline](#managed-policies)。 | 2022 年 11 月 17 日 | | CodePipeline 开始跟踪更改 | CodePipeline 开始跟踪其 AWS 托管策略的更改。 | 2021 年 3 月 12 日 | ## 客户管理型策略示例 本节的用户策略示例介绍如何授予各 操作的权限。这些政策在您使用 API AWS SDKs、或时起作用 AWS CLI。当您使用控制台时，您必须授予特定于控制台的其他权限。有关更多信息，请参阅 [使用控制台所需的权限](security-iam-permissions-console.md)。 **注意** 所有示例都使用美国西部（俄勒冈）区域 (`us-west-2`)，并包含虚构账户。 IDs **示例** + [示例 1：授予获取管道状态的权限](#identity-based-policies-example-1) + [示例 2：授予启用和禁用阶段之间的过渡的权限](#identity-based-policies-example-2) + [示例 3：授予获取所有可用操作类型列表的权限](#identity-based-policies-example-3) + [示例 4：授予批准或拒绝手动审批操作的权限](#identity-based-policies-example-4) + [示例 5：授予轮询作业以查找自定义操作的权限](#identity-based-policies-example-5) + [示例 6：附加或编辑 Jenkins 与集成的策略 AWS CodePipeline](#identity-based-policies-example-6) + [示例 7：配置对管道的跨账户访问](#identity-based-policies-example-7) ### 示例 1：授予获取管道状态的权限 以下示例将授予获取名为 `MyFirstPipeline` 的管道状态的权限： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:GetPipelineState" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline" } ] } ``` ------ ### 示例 2：授予启用和禁用阶段之间的过渡的权限 以下示例授予禁用和启用名为 `MyFirstPipeline` 的管道中所有阶段之间的过渡的权限： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:DisableStageTransition", "codepipeline:EnableStageTransition" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*" } ] } ``` ------ 要允许用户禁用和启用管道中单个阶段的过渡，您必须指定该阶段。例如，为了允许用户启用和禁用名为 `MyFirstPipeline` 的管道中 `Staging` 阶段的过渡： ``` "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging" ``` ### 示例 3：授予获取所有可用操作类型列表的权限 以下示例授予获取可用于 `us-west-2` 区域中的管道的所有操作类型列表的权限： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:ListActionTypes" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:actiontype:*" } ] } ``` ------ ### 示例 4：授予批准或拒绝手动审批操作的权限 以下示例授予批准或拒绝名为 `MyFirstPipeline` 的管道中 `Staging` 阶段的手动审批操作的权限： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PutApprovalResult" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging/*" } ] } ``` ------ ### 示例 5：授予轮询作业以查找自定义操作的权限 以下示例授予轮询所有管道中的作业以查找名为 `TestProvider` 的自定义操作的权限，该操作是第一个版本中的 `Test` 操作类型： **注意** 自定义操作的作业辅助角色可以在不同的 AWS 账户下配置，或者需要特定的 IAM 角色才能运行。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PollForJobs" ], "Resource": [ "arn:aws:codepipeline:us-west-2:111222333444:actionType:Custom/Test/TestProvider/1" ] } ] } ``` ------ ### 示例 6：附加或编辑 Jenkins 与集成的策略 AWS CodePipeline 如果您将管道配置为使用 Jenkins 进行构建或测试，请为该集成创建单独的身份，并附上具有 Jenkins 和之间集成所需的最低权限的 IAM 策略。此策略与 `AWSCodePipelineCustomActionAccess` 托管策略相同。以下示例显示了一项 Jenkins 集成策略： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:AcknowledgeJob", "codepipeline:GetJobDetails", "codepipeline:PollForJobs", "codepipeline:PutJobFailureResult", "codepipeline:PutJobSuccessResult" ], "Resource": "*" } ] } ``` ------ ### 示例 7：配置对管道的跨账户访问 您可以为另一个 AWS 账户中的用户和组配置对管道的访问。建议的方法是在创建管道的账户中创建角色。该角色应允许其他 AWS 账户的用户担任该角色并访问管道。有关更多信息，请参阅[演练：使用角色进行跨账户访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/walkthru_cross-account-with-roles.html)。 以下示例显示了 80398EXAMPLE 账户中的一项策略，该策略允许用户查看但不能更改控制台`MyFirstPipeline`中命名的管道。该策略基于 `AWSCodePipeline_ReadOnlyAccess` 托管策略，但由于它特定于 `MyFirstPipeline` 管道，因此无法直接使用托管策略。如果您不想将策略限制于某特定管道，则应该考虑使用 创建和维护的托管策略之一。有关更多信息，请参阅[使用管理的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html)。您必须将该策略附加到您为进行访问而创建的 IAM 角色，例如名为 `CrossAccountPipelineViewers` 的角色： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:GetPipeline", "codepipeline:GetPipelineState", "codepipeline:ListActionTypes", "codepipeline:ListPipelines", "iam:ListRoles", "s3:GetBucketPolicy", "s3:GetObject", "s3:ListAllMyBuckets", "s3:ListBucket", "codedeploy:GetApplication", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "elasticbeanstalk:DescribeApplications", "elasticbeanstalk:DescribeEnvironments", "lambda:GetFunctionConfiguration", "lambda:ListFunctions" ], "Resource": "arn:aws:codepipeline:us-east-2:111122223333:MyFirstPipeline" } ] } ``` ------ 创建该策略后，在 80398EXAMPLE 账户中创建 IAM 角色并将该策略附加到该角色。在角色的信任关系中，您必须添加担任此角色的 AWS 账户。 以下示例显示了在该*111111111111* AWS 账户中创建的策略，该策略允许用户代入 80398EXAMPLE 账户`CrossAccountPipelineViewers`中指定的角色： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/CrossAccountPipelineViewers" } ] } ``` ------ # AWS CodePipeline 基于资源的策略示例 **Topics** 其他服务（如 Amazon S3）还支持基于资源的权限策略。例如，您可以将策略附加到 S3 存储桶以管理对该存储桶的访问权限。尽管它 CodePipeline 不支持基于资源的策略，但它确实将要在管道中使用的工件存储在版本控制的 S3 存储桶中。 **Example 为 S3 存储桶创建策略以用作项目存储 CodePipeline** 您可以使用任何版本控制的 S3 存储桶作为对象存储。 CodePipeline如果您使用**创建管道**向导创建第一个管道，则系统将会为您创建此 S3 存储桶，以确保上传到构件存储的所有对象都已加密，并且与存储桶的连接是安全的。如果您创建自己的 S3 存储桶，则作为最佳实践，请考虑向存储桶添加以下策略或其元素。在此策略中，S3 存储桶的 ARN 是 `codepipeline-us-east-2-1234567890`。将此 ARN 替换为您的 S3 存储桶的 ARN： **** ``` { "Version":"2012-10-17", "Id": "SSEAndSSLPolicy", "Statement": [ { "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } }, { "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "Bool": { "aws:SecureTransport": false } } } ] } ``` # 对 AWS CodePipeline 身份和访问进行故障排除 使用以下信息来帮助您诊断和修复在使用 CodePipeline 和 IAM 时可能遇到的常见问题。 **Topics** + [我无权在以下位置执行操作 CodePipeline](#security_iam_troubleshoot-no-permissions) + [我无权执行 iam：PassRole](#security_iam_troubleshoot-passrole) + [我是一名管理员，想允许其他人访问 CodePipeline](#security_iam_troubleshoot-admin-delegate) + [我想允许 AWS 账户之外的人访问我的 CodePipeline 资源](#security_iam_troubleshoot-cross-account-access) ## 我无权在以下位置执行操作 CodePipeline 如果 AWS 管理控制台 告诉您您无权执行某项操作，则必须联系管理员寻求帮助。您的管理员是指为您提供用户名和密码的那个人。 当 `mateojackson` IAM 用户尝试使用控制台查看有关管道的详细信息但不具有 `codepipeline:GetPipeline` 权限时，会发生以下示例错误。 ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: codepipeline:GetPipeline on resource: my-pipeline ``` 在这种情况下，Mateo 请求他的管理员更新其策略，以允许他使用 `codepipeline:GetPipeline` 操作访问 `my-pipeline` 资源。 ## 我无权执行 iam：PassRole 如果您收到错误消息，提示您无权执行 `iam:PassRole` 操作，则必须联系您的管理员寻求帮助。您的管理员是指为您提供用户名和密码的那个人。请求该人员更新您的策略，以便允许您将角色传递给 CodePipeline。 有些 AWS 服务 允许您将现有角色传递给该服务，而不是创建新的服务角色或与服务相关的角色。为此，您必须具有将角色传递到服务的权限。 当名为 `marymajor` 的 IAM 用户尝试使用控制台在 CodePipeline 中执行操作时，会发生以下示例错误。但是，该操作要求服务拥有服务角色授予的权限。Mary 不具有将角色传递到服务的权限。 ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` 在这种情况下，Mary 请求她的管理员来更新其策略，以允许她执行 `iam:PassRole` 操作。 ## 我是一名管理员，想允许其他人访问 CodePipeline 要允许其他人访问 CodePipeline，您必须向需要访问的人员或应用程序授予权限。如果使用 AWS IAM Identity Center 管理人员和应用程序，则可以向用户或组分配权限集来定义其访问权限级别。权限集会自动创建 IAM 策略并将其分配给与人员或应用程序关联的 IAM 角色。有关更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[权限集](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)。 如果未使用 IAM Identity Center，则必须为需要访问的人员或应用程序创建 IAM 实体（用户或角色）。然后，您必须将策略附加到实体，以便在 CodePipeline 中向其授予正确的权限。授予权限后，向用户或应用程序开发人员提供凭证。他们将使用这些凭证访问 AWS。要了解有关创建 IAM 用户、组、策略和权限的更多信息，请参阅《IAM 用户指南》**中的 [IAM 身份](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)和 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。 ## 我想允许 AWS 账户之外的人访问我的 CodePipeline 资源 您可以创建一个角色，以便其他账户中的用户或您组织外的人员可以使用该角色来访问您的资源。您可以指定谁值得信赖，可以代入角色。对于支持基于资源的策略或访问控制列表 (ACLs) 的服务，您可以使用这些策略向人们授予访问您的资源的权限。 要了解更多信息，请参阅以下内容： + 要了解是否 CodePipeline 支持这些功能，请参阅[如何 AWS CodePipeline 与 IAM 配合使用](security_iam_service-with-iam.md)。 + 要了解如何提供对您拥有的资源的访问权限 AWS 账户 ，请参阅 [IAM 用户*指南中的向您拥有 AWS 账户 的另一个 IAM 用户*提供访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)权限。 + 要了解如何向第三方提供对您的资源的访问[权限 AWS 账户，请参阅 *IAM 用户指南*中的向第三方提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)访问权限。 AWS 账户 + 要了解如何通过身份联合验证提供访问权限，请参阅《IAM 用户指南》**中的[为经过外部身份验证的用户（身份联合验证）提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)。 + 要了解使用角色和基于资源的策略进行跨账户访问之间的差别，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 # 权限参考 在设置访问控制以及编写可附加到 IAM 身份的权限策略（基于身份的策略）时，请将下表作为参考。此表列出每个 API 操作及您可授予执行该操作的权限的对应操作。对于支持*资源级权限*的操作，该表列出了您可以为其授予权限的 AWS 资源。请在策略的 `Action` 字段中指定这些操作。 *资源级权限*是允许您指定允许用户对哪些资源执行操作的权限。 AWS CodePipeline 为资源级权限提供部分支持。这意味着，对于某些 AWS CodePipeline API 调用，您可以根据必须满足的条件或允许用户使用的资源来控制何时允许用户使用这些操作。例如，您可以授予用户列出管道执行信息的权限，但只针对一个或一些特定管道。 **注意** **资源**列中列出了支持资源级权限的 API 调用所需的资源。对于不支持资源级权限的 API 调用，您可以向用户授予使用调用的权限，但是必须为策略语句的“Resource”元素指定通配符（\$1）。 **API 操作和操作所需的权限** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/codepipeline/latest/userguide/permissions-reference.html) # 管理 CodePipeline 服务角色 服务角色配置了一个或多个策略，用于控制对管道所用 AWS 资源的访问权限。您可能需要为该角色附加更多策略，编辑附加到该角色的策略，或者在中为其他服务角色配置策略 AWS。在配置对管道的跨账户访问时，您可能还需要将策略附加到角色。 **重要** 修改策略语句或向角色附加其他策略可能会导致您的管道无法运行。在您以任何方式修改 的服务角色之前，请务必了解其影响。对服务角色进行任何更改后，确保测试管道。 **注意** 在控制台中，使用名称 `oneClick_AWS-CodePipeline-Service_ID-Number` 创建 2018 年 9 月之前创建的服务角色。 2018 年 9 月之后创建的服务角色使用服务角色名称格式 `AWSCodePipelineServiceRole-Region-Pipeline_Name`。例如，对于 `eu-west-2` 区域中名为 `MyFirstPipeline` 的管道，控制台会将角色和策略命名为 `AWSCodePipelineServiceRole-eu-west-2-MyFirstPipeline`。 ## CodePipeline 服务角色策略 CodePipeline 服务角色策略声明包含管理管道的最低权限。您可以编辑服务角色语句以删除或添加对不使用的资源的访问权限。有关每个操作所需的最低权限 CodePipeline 使用情况，请参阅相应的操作参考。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3BucketAccess", "Effect": "Allow", "Action": [ "s3:GetBucketVersioning", "s3:GetBucketAcl", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::[[pipeArtifactBucketNames]]" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "{{accountId}}" } } }, { "Sid": "AllowS3ObjectAccess", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:GetObject", "s3:GetObjectVersion", "s3:PutObjectTagging", "s3:GetObjectTagging", "s3:GetObjectVersionTagging" ], "Resource": [ "arn:aws:s3:::[[pipeArtifactBucketNames]]/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "{{accountId}}" } } } ] } ``` ------ **注意** 在该策略中，当您的源存储桶中的 S3 对象中包含标签时，需要以下权限： ``` s3:PutObjectTagging s3:GetObjectTagging s3:GetObjectVersionTagging ``` ## 移除 CodePipeline 服务角色的权限 您可以编辑服务角色语句以删除对不使用的资源的访问权限。例如，如果您的所有管道均不包括 Elastic Beanstalk，您可以编辑策略语句以移除授权访问 Elastic Beanstalk 资源的部分。 同样，如果您的所有管道都不包含 CodeDeploy，则可以编辑策略声明以删除授予 CodeDeploy 资源访问权限的部分： ``` { "Action": [ "codedeploy:CreateDeployment", "codedeploy:GetApplicationRevision", "codedeploy:GetDeployment", "codedeploy:GetDeploymentConfig", "codedeploy:RegisterApplicationRevision" ], "Resource": "*", "Effect": "Allow" }, ``` ## 为 CodePipeline 服务角色添加权限 您必须使用尚未包含在默认服务角色策略语句中的 AWS 服务 的权限更新服务角色策略语句，然后才能在管道中使用它。 如果您用于管道的服务角色是在向添加支持之前创建的，则这一点尤其重要 AWS 服务。 下表显示了添加对其他 AWS 服务的支持的时间。 **** | AWS 服务 | CodePipeline 支持日期 | | --- | --- | | CodePipeline 添加了调用操作支持。请参阅[CodePipeline 调用操作的服务角色策略权限](action-reference-PipelineInvoke.md#action-reference-PipelineInvoke-permissions-action)。 | 2025 年 3 月 14 日 | | 添加了 EC2 操作支持。请参阅[EC2 部署操作的服务角色策略权限](action-reference-EC2Deploy.md#action-reference-EC2Deploy-permissions-action)。 | 2025 年 2 月 21 日 | | 添加了 EKS 操作支持。请参阅[服务角色策略权限](action-reference-EKS.md#action-reference-EKS-service-role)。 | 2025 年 2 月 20 日 | | 添加了 Amazon Elastic Container Registry ECRBuildAndPublish 操作支持。请参阅[服务角色权限：`ECRBuildAndPublish` 操作](action-reference-ECRBuildAndPublish.md#edit-role-ECRBuildAndPublish)。 | 2024 年 11 月 22 日 | | 添加了 Amazon Inspector InspectorScan 操作支持。请参阅[服务角色权限：`InspectorScan` 操作](action-reference-InspectorScan.md#edit-role-InspectorScan)。 | 2024 年 11 月 22 日 | | 添加了 Commands 操作支持。请参阅[服务角色权限：Commands 操作](action-reference-Commands.md#edit-role-Commands)。 | 2024 年 10 月 3 日 | | CloudFormation 添加了动作支持。请参阅[服务角色权限：`CloudFormationStackSet` 操作](action-reference-StackSets.md#edit-role-cfn-stackset)和[服务角色权限：`CloudFormationStackInstances` 操作](action-reference-StackSets.md#edit-role-cfn-stackinstances)。 | 2020 年 12 月 30 日 | | CodeCommit 添加了对完整克隆输出构件格式操作的支持。请参阅[服务角色权限： CodeCommit 操作](action-reference-CodeCommit.md#edit-role-codecommit)。 | 2020 年 11 月 11 日 | | AWS CodeBuild 添加了批量生成操作支持。请参阅[服务角色权限： CodeCommit 操作](action-reference-CodeCommit.md#edit-role-codecommit)。 | 2020 年 7 月 30 日 | | AWS AppConfig 添加了动作支持。请参阅[服务角色权限：`AppConfig` 操作](action-reference-AppConfig.md#edit-role-appconfig)。 | 2020 年 6 月 22 日 | | AWS Step Functions 添加了动作支持。请参阅[服务角色权限：`StepFunctions` 操作](action-reference-StepFunctions.md#edit-role-stepfunctions)。 | 2020 年 5 月 27 日 | | AWS CodeStar 添加了连接操作支持。请参阅[服务角色权限： CodeConnections 操作](action-reference-CodestarConnectionSource.md#edit-role-connections)。 | 2019 年 12 月 18 日 | | 添加了 S3 部署操作支持。请参阅[服务角色权限：S3 部署操作](action-reference-S3Deploy.md#edit-role-s3deploy)。 | 2019 年 1 月 16 日 | | 添加了 CodeDeployToECS 操作支持。请参阅[服务角色权限：`CodeDeployToECS` 操作](action-reference-ECSbluegreen.md#edit-role-codedeploy-ecs)。 | 2018 年 11 月 27 日 | | 添加了 Amazon ECR 操作支持。请参阅[服务角色权限：Amazon ECR 操作](action-reference-ECR.md#edit-role-ecr)。 | 2018 年 11 月 27 日 | | 添加了 Service Catalog 操作支持。请参阅[服务角色权限：Service Catalog 操作](action-reference-ServiceCatalog.md#edit-role-servicecatalog)。 | 2018 年 10 月 16 日 | | AWS Device Farm 添加了动作支持。请参阅[服务角色权限： AWS Device Farm 操作](action-reference-DeviceFarm.md#edit-role-devicefarm)。 | 2018 年 7 月 19 日 | | 添加了 Amazon ECS 操作支持。请参阅[服务角色权限：Amazon ECS 标准操作](action-reference-ECS.md#edit-role-ecs)。 | 2017 年 12 月 12 日/2017 年 7 月 21 日更新了选择加入标记授权的选项 | | CodeCommit 添加了动作支持。请参阅[服务角色权限： CodeCommit 操作](action-reference-CodeCommit.md#edit-role-codecommit)。 | 2016 年 4 月 18 日 | | AWS OpsWorks 添加了动作支持。请参阅[服务角色权限： AWS OpsWorks 操作](action-reference-OpsWorks.md#edit-role-opsworks)。 | 2016 年 6 月 2 日 | | CloudFormation 添加了动作支持。请参阅[服务角色权限： CloudFormation 操作](action-reference-CloudFormation.md#edit-role-cloudformation)。 | 2016 年 11 月 3 日 | | AWS CodeBuild 添加了动作支持。请参阅[服务角色权限： CodeBuild 操作](action-reference-CodeBuild.md#edit-role-codebuild)。 | 2016 年 12 月 1 日 | | 添加了 Elastic Beanstalk 操作支持。请参阅[服务角色权限：`ElasticBeanstalk` 部署操作](action-reference-Beanstalk.md#edit-role-beanstalk)。 | 首次服务发布 | | CodeDeploy 添加了动作支持。请参阅[服务角色权限： AWS CodeDeploy 操作](action-reference-CodeDeploy.md#edit-role-codedeploy)。 | 首次服务发布 | | 添加了 S3 源操作支持。请参阅[服务角色权限：S3 源操作](action-reference-S3.md#edit-role-s3source)。 | 首次服务发布 | 请按照以下步骤添加受支持服务的权限： 1. 登录 AWS 管理控制台 并打开 IAM 控制台，网址为[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。 1. 在 IAM 角色控制台的导航窗格中，选择**角色**，然后从角色列表中选择您的 `AWS-CodePipeline-Service` 角色。 1. 在**权限**选项卡上的**内联策略**中，选择您的服务角色策略所在行中的**编辑策略**。 1. 在**策略文档**框中添加所需权限。 **注意** 在您创建 IAM 策略时，请遵循授予最低权限这一标准安全建议，即仅授予执行任务所需的权限。某些 API 调用支持基于资源的权限并允许限制访问。例如，在这种情况下，要在调用 `DescribeTasks` 和 `ListTasks` 时限制权限，您可以将通配符（\$1）替换为资源 ARN 或包含通配符（\$1）的资源 ARN。有关创建策略以授予最低权限访问权限的更多信息，请参阅 [https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)。 1. 选择**查看策略**以确保策略不包含错误。当策略正确无误时，选择**应用策略**。 # 登录和监控 CodePipeline 您可以使用登录功能 AWS 来确定用户在您的账户中执行的操作以及使用的资源。日志文件显示： + 操作的时间和日期。 + 操作的源 IP 地址。 + 由于权限不足而失败的操作。 日志记录功能在以下 AWS 服务中可用： + AWS CloudTrail 可用于记录由或代表发起 AWS 的 API 调用和相关事件 AWS 账户。有关更多信息，请参阅 [使用记录 CodePipeline API 调用 AWS CloudTrail](monitoring-cloudtrail-logs.md)。 + Amazon CloudWatch Events 可用于监控您的 AWS 云 资源和您运行的应用程序 AWS。您可以根据自己定义的指标在 Amazon Ev CloudWatch ents 中创建提醒。有关更多信息，请参阅 [监控 CodePipeline 事件](detect-state-changes-cloudwatch-events.md)。 # 合规性验证 AWS CodePipeline 要了解是否属于特定合规计划的范围，请参阅AWS 服务 “[按合规计划划分的范围](https://aws.amazon.com/compliance/services-in-scope/)” ”，然后选择您感兴趣的合规计划。 AWS 服务 有关一般信息，请参阅[AWS 合规计划AWS](https://aws.amazon.com/compliance/programs/)。 您可以使用构件下载第三方审计报告。有关更多信息，请参阅中的 “[下载报告” 中的 “ AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)。 您在使用 AWS 服务 时的合规责任取决于您的数据的敏感性、贵公司的合规目标以及适用的法律和法规。有关您在使用时的合规责任的更多信息 AWS 服务，请参阅[AWS 安全文档](https://docs.aws.amazon.com/security/)。 # 韧性在 AWS CodePipeline AWS 全球基础设施是围绕 AWS 区域和可用区构建的。 AWS 区域提供多个物理隔离和隔离的可用区，这些可用区通过低延迟、高吞吐量和高度冗余的网络相连。利用可用区，您可以设计和操作在可用区之间无中断地自动实现失效转移的应用程序和数据库。与传统的单个或多个数据中心基础设施相比，可用区具有更高的可用性、容错能力和可扩展性。 有关 AWS 区域和可用区的更多信息，请参阅[AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure/)。 # 中的基础设施安全 AWS CodePipeline 作为一项托管服务 AWS CodePipeline ，受 AWS 全球网络安全的保护。有关 AWS 安全服务以及如何 AWS 保护基础设施的信息，请参阅[AWS 云安全](https://aws.amazon.com/security/)。要使用基础设施安全的最佳实践来设计您的 AWS 环境，请参阅 S * AWS ecurity Pillar Well-Architected Fram* ework 中的[基础设施保护](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)。 您可以使用 AWS 已发布的 API 调用 CodePipeline 通过网络进行访问。客户端必须支持以下内容： + 传输层安全性协议（TLS）。我们要求使用 TLS 1.2，建议使用 TLS 1.3。 + 具有完全向前保密（PFS）的密码套件，例如 DHE（临时 Diffie-Hellman）或 ECDHE（临时椭圆曲线 Diffie-Hellman）。大多数现代系统（如 Java 7 及更高版本）都支持这些模式。 # 安全最佳实践 **Topics** CodePipeline 提供了许多安全功能，供您在制定和实施自己的安全策略时考虑。以下最佳实践是一般指导原则，并不代表完整安全解决方案。这些最佳实践可能不适合环境或不满足环境要求，请将其视为有用的考虑因素而不是惯例。 您可以对连接到管道的源存储库使用加密和身份验证。以下是安全 CodePipeline 的最佳实践： + 如果要创建需要包含密钥（如令牌或密码）的管道或操作配置，请不要直接在操作配置中输入密钥，也不要输入管道级别或 CloudFormation 配置中定义的变量的默认值，因为这些信息将显示在日志中。请使用 Secrets Manager 设置和存储密钥，然后在管道和操作配置中使用引用的密钥，如[AWS Secrets Manager 用于跟踪数据库密码或第三方 API 密钥](parameter-store-encryption.md)中所述。 + 如果您创建使用 S3 源存储桶的管道，请 CodePipeline 通过管理为存储在 Amazon S3 中的项目配置服务器端加密 AWS KMS keys，如中所[为存储在 Amazon S3 中的项目配置服务器端加密 CodePipeline](S3-artifact-encryption.md)述。 + 如果您使用 Jenkins 操作提供程序，则当您将 Jenkins 构建提供程序用于管道的构建或测试操作时，应在 EC2 实例上安装 Jenkins 并配置单独的 EC2 实例配置文件。确保实例配置文件仅授予 Jenkins 执行项目任务所需的 AWS 权限，例如从 Amazon S3 检索文件。要了解如何为您的 Jenkins 实例配置文件创建角色，请参阅[创建 IAM 角色以用于 Jenkins 集成](tutorials-four-stage-pipeline.md#tutorials-four-stage-pipeline-prerequisites-jenkins-iam-role)中的步骤。