本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Amazon CodePipeline 基于身份的策略示例
默认情况下，IAM 用户和角色没有创建或修改 CodePipeline 资源的权限。他们也无法使用 Amazon Web Services 管理控制台 Amazon CLI、或 Amazon API 执行任务。IAM 管理员必须创建 IAM 策略，以便为用户和角色授予权限以对所需的指定资源执行特定的 API 操作。然后，管理员必须将这些策略附加到需要这些权限的 IAM 用户或组。
要了解如何使用这些示例 JSON 策略文档创建 IAM 基于身份的策略，请参阅*《IAM 用户指南》*中的 [在 JSON 选项卡上创建策略](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)。
要了解如何创建使用其它账户资源的管道以及相关的示例策略，请参阅[在中 CodePipeline 创建使用其他 Amazon 账户资源的管道](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)
+ [Amazon 的托管策略 Amazon CodePipeline](managed-policies.md)
+ [客户管理型策略示例](#customer-managed-policies)
## 客户管理型策略示例
本节的用户策略示例介绍如何授予各 操作的权限。这些政策在您使用 API Amazon SDKs、或时起作用 Amazon 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 与集成的策略 Amazon 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` 操作类型：
**注意**
自定义操作的作业辅助角色可以在不同的 Amazon 账户下配置，或者需要特定的 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 与集成的策略 Amazon 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：配置对管道的跨账户访问
您可以为另一个 Amazon 账户中的用户和组配置对管道的访问。建议的方法是在创建管道的账户中创建角色。该角色应允许其他 Amazon 账户的用户担任该角色并访问管道。有关更多信息，请参阅[演练：使用角色进行跨账户访问](https://docs.amazonaws.cn/IAM/latest/UserGuide/walkthru_cross-account-with-roles.html)。
以下示例显示了 80398EXAMPLE 账户中的一项策略，该策略允许用户查看但不能更改控制台`MyFirstPipeline`中命名的管道。该策略基于 `AWSCodePipeline_ReadOnlyAccess` 托管策略，但由于它特定于 `MyFirstPipeline` 管道，因此无法直接使用托管策略。如果您不想将策略限制于某特定管道，则应该考虑使用 创建和维护的托管策略之一。有关更多信息，请参阅[使用管理的策略](https://docs.amazonaws.cn/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 角色并将该策略附加到该角色。在角色的信任关系中，您必须添加担任此角色的 Amazon 账户。
以下示例显示了在该*111111111111* Amazon 账户中创建的策略，该策略允许用户代入 80398EXAMPLE 账户`CrossAccountPipelineViewers`中指定的角色：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/CrossAccountPipelineViewers"
}
]
}
```
------