AWS Data Pipeline 不再向新客户提供。的现有客户 AWS Data Pipeline 可以继续照常使用该服务。[了解详情](https://aws.amazon.com/blogs/big-data/migrate-workloads-from-aws-data-pipeline/)

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 适用的 IAM 政策 AWS Data Pipeline
<a name="dp-iam-resourcebased-access"></a>

默认情况下，IAM 实体没有创建或修改 AWS 资源的权限。要允许 IAM 实体创建或修改资源和执行任务，您必须创建 IAM policy 以允许 IAM 实体使用他们所需的特定资源和 API 操作，然后将这些策略与需要这些权限的 IAM 实体关联起来。

在将策略附加到一个用户或一组用户时，它会授权或拒绝用户使用指定资源执行指定任务。有关 IAM policy 的一般信息，请参阅 *IAM 用户指南*中的[权限与策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/PermissionsAndPolicies.html)。有关管理和创建自定义 IAM policy 的更多信息，请参阅[管理 IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html)。

**Topics**
+ [策略语法](#dp-policy-syntax)
+ [使用标签控制对管道的访问权限](#dp-control-access-tags)
+ [使用工作线程组控制对管道的访问权限](#dp-control-access-workergroup)

## 策略语法
<a name="dp-policy-syntax"></a>

IAM 策略是包含一个或多个语句的 JSON 文档。每个语句的结构如下：

```
{
  "Statement":[{
    "Effect":"effect",
    "Action":"action",
    "Resource":"*",
    "Condition":{
      "condition":{
        "key":"value"
        }
      }
    }
  ]
}
```

策略声明包含以下元素：
+ **Effect：**此 *effect* 可以是 `Allow` 或 `Deny`。在默认情况下，IAM 实体没有使用资源和 API 操作的许可，因此，所有请求均会被拒绝。显式允许将覆盖默认规则。显式拒绝将覆盖任何允许。
+ **Action**：*action* 是对其授予或拒绝权限的特定 API 操作。有关操作的列表 AWS Data Pipeline，请参阅 *AWS Data Pipeline API 参考*中的[操作](https://docs.aws.amazon.com/datapipeline/latest/APIReference/API_Operations.html)。
+ **Resource**：受操作影响的资源。此处唯一有效值为 `"*"`。
+ **条件**：条件是可选的。它们可以用于控制策略生效的时间。

  AWS Data Pipeline 实现 AWS 范围的上下文密钥（参见[条件的可用密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#AvailableKeys)），以及以下特定于服务的密钥。
  + `datapipeline:PipelineCreator` - 向创建管道的用户授予访问权限。有关示例，请参阅[授予管道所有者完全访问权限](dp-example-tag-policies.md#ex3)。
  + `datapipeline:Tag` - 基于管道标记授予访问权限。有关更多信息，请参阅 [使用标签控制对管道的访问权限](#dp-control-access-tags)。
  + `datapipeline:workerGroup` - 基于工作线程组的名称授予访问权限。有关更多信息，请参阅 [使用工作线程组控制对管道的访问权限](#dp-control-access-workergroup)。

## 使用标签控制对管道的访问权限
<a name="dp-control-access-tags"></a>

您可以创建引用管道标签的 IAM 策略。这使您能够使用管道标签来执行以下操作：
+ 授予对管道的只读访问权限
+ 授予对管道的 read/write 访问权限
+ 阻止对管道的访问

例如，假设一个管理员有生产和开发两个管道环境，每个环境有一个 IAM 组。对于生产环境中的管道，经理向生产 IAM 组中的用户授予 read/write 访问权限，但向开发人员 IAM 组中的用户授予只读访问权限。对于开发环境中的管道，经理授予对生产和开发者 IAM 组的 read/write 访问权限。

要实现这一场景，管理员使用“environment = production”标签来标记生产管道，并将以下策略附加到开发人员 IAM 组。第一条语句授予对所有管道的只读访问权限。第二条语句授予对没有 “环境=生产” 标签的管道的 read/write 访问权限。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "datapipeline:Describe*",
        "datapipeline:ListPipelines",
        "datapipeline:GetPipelineDefinition",
        "datapipeline:QueryObjects"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "datapipeline:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {"datapipeline:Tag/environment": "production"}
      }
    }
  ]
}
```

------

此外，管理员将以下策略附加到生产 IAM 组。此语句授予对所有管道的完全访问权限。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "datapipeline:*",
      "Resource": "*"
    }
  ]
}
```

------

有关更多示例，请参阅[基于标签向用户授予只读访问权限](dp-example-tag-policies.md#ex1)和[基于标签向用户授予完全访问权限](dp-example-tag-policies.md#ex2)。

## 使用工作线程组控制对管道的访问权限
<a name="dp-control-access-workergroup"></a>

您可以创建引用工作线程组名称的 IAM 策略。

例如，假设一个管理员有生产和开发两个管道环境，每个环境有一个 IAM 组。管理员有三个数据库服务器，分别为生产、生产前和开发人员环境配置了任务运行程序。管理员想要确保用户在生产 IAM 组中的用户可以创建推送任务到生产资源的管道，而开发 IAM 组中的用户可以创建推送任务到生产前和开发人员资源的管道。

要实现这种场景，管理员使用生产凭证在生产资源上安装任务运行程序，并将 `workerGroup` 设置为“prodresource”。此外，管理员使用开发凭证在开发资源上安装任务运行程序，并将 `workerGroup` 设置为“pre-production”和“development”。管理员将以下策略附加到开发人员 IAM 组来阻止对“prodresource”资源的访问。第一条语句授予对所有管道的只读访问权限。当工作人员组的名称前缀为 “dev” 或 “pre-prod” 时，第二条语句授予对管道的 read/write 访问权限。

此外，管理员将以下策略附加到生产 IAM 组来授予对“prodresource”资源的访问权限。第一条语句授予对所有管道的只读访问权限。当工作人员组的名称前缀为 “prod” 时，第二条语句授予 read/write 访问权限。