Amazon CodePipeline 基于身份的策略示例 - Amazon CodePipeline
客户管理型策略示例
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

Amazon CodePipeline 基于身份的策略示例

默认情况下，IAM用户和角色无权创建或修改 CodePipeline 资源。他们也无法使用 Amazon Web Services Management Console Amazon CLI、或执行任务 Amazon API。IAM管理员必须创建IAM策略，授予用户和角色对其所需的指定资源执行特定API操作的权限。然后，管理员必须将这些策略附加到需要这些权限的IAM用户或群组。

要了解如何使用这些示例JSON策略文档创建IAM基于身份的策略，请参阅《IAM用户指南》JSON中的 “在选项卡上创建策略”。

要了解如何创建使用其他账户资源的管道以及相关的示例策略，请参阅在中 CodePipeline 创建使用其他 Amazon 账户资源的管道。

主题

客户管理型策略示例

在本节中，您可以找到授予各种 CodePipeline 操作权限的用户策略示例。这些策略在您使用 CodePipeline API Amazon SDKs、或时起作用 Amazon CLI。当您使用控制台时，您必须授予特定于控制台的其他权限。有关更多信息，请参阅 使用 CodePipeline 控制台所需的权限。

注意

所有示例都使用美国西部（俄勒冈）区域 (us-west-2)，并包含虚构账户。IDs

示例

示例 1：授予获取管道状态的权限

以下示例将授予获取名为 MyFirstPipeline 的管道状态的权限：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codepipeline:GetPipelineState"
            ],
            "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"
        }
    ]
}

示例 2：授予启用和禁用阶段之间的过渡的权限

以下示例授予禁用和启用名为 MyFirstPipeline 的管道中所有阶段之间的过渡的权限：

{
    "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 区域中的管道的所有操作类型列表的权限：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codepipeline:ListActionTypes"
            ],
            "Resource": "arn:aws:codepipeline:us-west-2:111222333444:actiontype:*"
        }
    ]
}

示例 4：授予批准或拒绝手动审批操作的权限

以下示例授予批准或拒绝名为 MyFirstPipeline 的管道中 Staging 阶段的手动审批操作的权限：

{
    "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角色才能运行。

{
    "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策略。 CodePipeline此策略与 AWSCodePipelineCustomActionAccess 托管策略相同。以下示例显示了一项 Jenkins 集成策略：

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codepipeline:AcknowledgeJob",
                "codepipeline:GetJobDetails",
                "codepipeline:PollForJobs",
                "codepipeline:PutJobFailureResult",
                "codepipeline:PutJobSuccessResult"
            ],
            "Resource": "*"
        }
    ],
    "Version": "2012-10-17"
}

示例 7：配置对管道的跨账户访问

您可以为另一个 Amazon 账户中的用户和组配置对管道的访问。建议的方法是在创建管道的账户中创建角色。该角色应允许其他 Amazon 账户的用户担任该角色并访问管道。有关更多信息，请参阅演练：使用角色进行跨账户访问。

以下示例显示了 80398 EXAMPLE 账户中的一项策略，该策略允许用户查看但不能更改控制台MyFirstPipeline中命名的管道。 CodePipeline 该策略基于 AWSCodePipeline_ReadOnlyAccess 托管策略，但由于它特定于 MyFirstPipeline 管道，因此无法直接使用托管策略。如果您不想将策略限制在特定的管道中，请考虑使用由创建和维护的托管策略之一 CodePipeline。有关更多信息，请参阅使用管理的策略。您必须将此策略附加到您为访问而创建的IAM角色，例如，一个名为CrossAccountPipelineViewers：的角色

{
    "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:80398EXAMPLE:MyFirstPipeline"
        }
    ],
    "Version": "2012-10-17"
}

创建此策略后，在 80398 EXAMPLE 账户中创建该IAM角色并将该策略附加到该角色。在角色的信任关系中，您必须添加担任此角色的 Amazon 账户。以下示例显示了一个策略，该策略允许用户来自 111111111111 Amazon 用于代替 80398 EXAMPLE 账户中定义的角色的帐户：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

以下示例显示了在中创建的策略 111111111111 Amazon 允许用户扮演 80398 EXAMPLE 账户CrossAccountPipelineViewers中指定的角色的帐户：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::80398EXAMPLE:role/CrossAccountPipelineViewers"
        }
    ]
}

示例 8：在管道中使用与另一个账户相关联的 Amazon 资源

您可以配置策略，允许用户创建使用其他 Amazon 账户资源的管道。这需要在创建管道的账户（AccountA）和已创建要在管道中使用的资源的账户（AccountB）中同时配置策略和角色。您还必须在中创建客户托管密钥 Amazon Key Management Service 以用于跨账户访问。有关更多信息和 step-by-step示例，请参阅在中 CodePipeline 创建使用其他 Amazon 账户资源的管道和为存储在 Amazon S3 中的项目配置服务器端加密 CodePipeline。

以下示例显示了 AccountA 为用于存储管道构件的 S3 存储桶配置的策略。该策略授予对 AccountB 的访问权限。在以下示例中，帐户 B ARN 的为。012ID_ACCOUNT_BS3 存储桶的为codepipeline-us-east-2-1234567890。ARN将它们ARNs替换ARNs为 S3 存储桶和您想要允许访问的账户：

{
    "Version": "2012-10-17",
    "Id": "SSEAndSSLPolicy",
    "Statement": [
        {
            "Sid": "DenyUnEncryptedObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "aws:kms"
                }
            }
        },
        {
            "Sid": "DenyInsecureConnections",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": false
                }
            }
        },
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::012ID_ACCOUNT_B:root"
            },
            "Action": [
                "s3:Get*",
                "s3:Put*"
            ],
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*"
        },
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::012ID_ACCOUNT_B:root"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890"
        }
    ]
}

以下示例显示了 AccountA 配置的策略，该策略允许 AccountB 担任某个角色。必须将此策略应用于 CodePipeline (CodePipeline_Service_Role) 的服务角色。有关如何将策略应用于中的角色的更多信息IAM，请参阅修改角色。在以下示例中，012ID_ACCOUNT_B是ARN针对账户 B 的：

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": [
            "arn:aws:iam::012ID_ACCOUNT_B:role/*"
        ]
    }
}

以下示例显示了由 AccountB 配置并应用于的EC2实例角色的策略。 CodeDeploy此策略授予对 AccountA 用来存储管道工件的 S3 存储桶的访问权限 (codepipeline-us-east-2-1234567890):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*"
            ],
            "Resource": [
                "arn:aws:s3:::codepipeline-us-east-2-1234567890/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::codepipeline-us-east-2-1234567890"
            ]
        }
    ]
}

以下示例显示了在 AccountA 中创建并配置为允许 AccountB 使用该密钥的客户托管密钥的 Amazon KMS 位置arn:aws:kms:us-east-1:012ID_ACCOUNT_A:key/2222222-3333333-4444-556677EXAMPLE的策略：ARN

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:DescribeKey",
                "kms:GenerateDataKey*",
                "kms:Encrypt",
                "kms:ReEncrypt*",
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:aws:kms:us-east-1:012ID_ACCOUNT_A:key/2222222-3333333-4444-556677EXAMPLE"
            ]
        }
    ]
}

以下示例显示了由 AccountB 创建的IAM角色 (CrossAccount_Role) 的内联策略，该策略允许访问 AccountA 中管道所需的 CodeDeploy 操作。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codedeploy:CreateDeployment",
                "codedeploy:GetDeployment",
                "codedeploy:GetDeploymentConfig",
                "codedeploy:GetApplicationRevision",
                "codedeploy:RegisterApplicationRevision"
            ],
            "Resource": "*"
        }
    ]
}

以下示例显示了由 AccountB 创建的IAM角色 (CrossAccount_Role) 的内联策略，该策略允许访问 S3 存储桶来下载输入项目和上传输出项目：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject*",
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "arn:aws:s3:::codepipeline-us-east-2-1234567890/*"
            ]
        }
    ]
}

有关如何编辑管道以跨账户访问资源的更多信息，请参阅步骤 2：编辑管道 。