本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 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) + [ # 使用 CodePipeline 控制台所需的权限 ](security-iam-permissions-console.md) + [ # 在 CodePipeline 控制台中查看计算日志所需的权限 ](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)。 # 在控制台中查看资源 CodePipeline 控制台需要`ListRepositories`权限才能在您登录的 AWS 地区显示您的 AWS 账户的存储库列表。该控制台还包括一个**转到资源**功能，可对资源快速执行不区分大小写的搜索。此搜索是在您 AWS 登录所在 AWS 地区的账户中执行的。将显示以下服务中的以下资源： + AWS CodeBuild：构建项目 + AWS CodeCommit：存储库 + AWS CodeDeploy：应用程序 + AWS CodePipeline：管道 要在所有服务中跨资源执行此搜索，您必须具有如下权限： + 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 身份附加策略。例如，您可以执行以下操作： + 将@@ **权限策略附加到您账户中的用户或群组**-要授予用户在 CodePipeline 控制台中查看管道的权限，您可以将权限策略附加到该用户所属的用户或群组。 + **向角色附加权限策略（授予跨账户权限）**：您可以向 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 账户中的策略，该策略允许用户在 CodePipeline 控制台中查看但不能更改名为 `MyFirstPipeline` 的管道。该策略基于 `AWSCodePipeline_ReadOnlyAccess` 托管策略，但由于它特定于 `MyFirstPipeline` 管道，因此无法直接使用托管策略。如果您不想将策略限制于某特定管道，则应该考虑使用 CodePipeline 创建和维护的托管策略之一。有关更多信息，请参阅[使用管理的策略](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 策略声明示例 CodePipeline，请参阅[客户管理型策略示例](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"] } } } ] } ``` # 使用 CodePipeline 控制台所需的权限 要 CodePipeline 在 CodePipeline 控制台中使用，您必须拥有来自以下服务的最低权限集： + AWS Identity and Access Management + Amazon Simple Storage Service 这些权限允许您描述 AWS 账户的其他 AWS 资源。 根据您纳入管道的其他服务，您可能需要来自以下一项或多项的权限： + AWS CodeCommit + CodeBuild + CloudFormation + AWS CodeDeploy + AWS Elastic Beanstalk + AWS Lambda + AWS OpsWorks 如果创建比必需的最低权限更为严格的 IAM 策略，对于附加了该 IAM 策略的用户， 控制台将无法按预期正常运行。为确保这些用户仍然可以使用 CodePipeline 控制台，还要将`AWSCodePipeline_ReadOnlyAccess`托管策略附加到该用户，如中所述[AWS 的托管策略 AWS CodePipeline](managed-policies.md)。 您无需为调用 AWS CLI 或 CodePipeline API 的用户设置最低控制台权限。 # 在 CodePipeline 控制台中查看计算日志所需的权限 要在 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 托管策略可能不会为您的特定用例授予最低权限权限，因为它们可供所有 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` `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` `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` `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` `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 日 | ## 客户管理型策略示例 在本节中，您可以找到授予各种 CodePipeline 操作权限的用户策略示例。这些政策在您使用 CodePipeline API AWS SDKs、或时起作用 AWS CLI。当您使用控制台时，您必须授予特定于控制台的其他权限。有关更多信息，请参阅 [使用 CodePipeline 控制台所需的权限](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 策略。 CodePipeline此策略与 `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`中命名的管道。 CodePipeline 该策略基于 `AWSCodePipeline_ReadOnlyAccess` 托管策略，但由于它特定于 `MyFirstPipeline` 管道，因此无法直接使用托管策略。如果您不想将策略限制于某特定管道，则应该考虑使用 CodePipeline 创建和维护的托管策略之一。有关更多信息，请参阅[使用管理的策略](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" } ] } ``` ------