AWS CodePipeline ejemplos de políticas basadas en identidad de - AWS CodePipeline
Ejemplos de políticas administradas por el cliente

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

AWS CodePipeline ejemplos de políticas basadas en identidad de

De forma predeterminada, los usuarios y los roles de IAM no tienen permiso para crear, ver ni modificar recursos de CodePipeline . Tampoco pueden realizar tareas mediante la AWS API AWS Management Console AWS CLI, o. Un administrador de IAM debe crear políticas de IAM que concedan permisos a los usuarios y a los roles para realizar operaciones de la API concretas en los recursos especificados que necesiten. El administrador debe adjuntar esas políticas a los usuarios o grupos de IAM que necesiten esos permisos.

Para obtener información acerca de cómo crear una política basada en identidades de IAM con estos documentos de políticas JSON de ejemplo, consulte Creación de políticas en la pestaña JSON en la Guía del usuario de IAM.

Para obtener información sobre cómo crear una canalización que utilice recursos de otra cuenta y ver los ejemplos de políticas relacionadas, consulte Crear una canalización en CodePipeline que use recursos de otra cuenta de AWS.

Temas

Ejemplos de políticas administradas por el cliente

En esta sección, encontrará ejemplos de políticas de usuario que otorgan permisos para diversas CodePipeline acciones. Estas políticas funcionan cuando se utiliza la CodePipeline API AWS SDKs, o la AWS CLI. Cuando se utiliza la consola, debe conceder permisos adicionales específicos a la consola. Para obtener más información, consulte Permisos necesarios para usar la consola de CodePipeline .

nota

Todos los ejemplos utilizan la región EE.UU. Oeste (Oregón) (us-west-2) y contienen una cuenta IDs ficticia.

Ejemplos

Ejemplo 1: Conceder permisos para obtener el estado de una canalización

En el siguiente ejemplo, se conceden permisos para obtener el estado de la canalización llamada MyFirstPipeline:

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

Ejemplo 2: Conceder permisos para activar y desactivar las transiciones entre etapas

En el siguiente ejemplo, se conceden permisos para deshabilitar y habilitar las transiciones entre todas las etapas de la canalización llamada MyFirstPipeline:

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

Para que el usuario pueda deshabilitar o habilitar transiciones en una sola etapa de la canalización, debe indicar la etapa. Por ejemplo, para que el usuario puede habilitar o deshabilitar transiciones en una etapa llamada Staging de una canalización denominada MyFirstPipeline:

"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging"

Ejemplo 3: Conceder permisos para obtener una lista de todos los tipos de acciones disponibles

En el siguiente ejemplo, se conceden permisos para obtener una lista de todos los tipos de acción disponibles para las canalizaciones de la región us-west-2:

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

Ejemplo 4: Conceder permisos para autorizar o rechazar acciones de aprobación manual

En el siguiente ejemplo, se conceden permisos para autorizar o rechazar acciones de aprobación manual en una etapa llamada Staging de una canalización denominada MyFirstPipeline: 

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

Ejemplo 5: Conceder permisos para sondear trabajos en una acción personalizada

En el siguiente ejemplo, se conceden permisos para sondear trabajos en la acción personalizada llamada TestProvider, que es un tipo de acción Test en su primera versión, en todas las canalizaciones:

nota

Puede que el proceso de trabajo de una acción personalizada se haya configurado con otra cuenta de AWS o que necesite un rol de IAM específico para que funcione.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codepipeline:PollForJobs"
            ],
            "Resource": [
                "arn:aws:codepipeline:us-west-2:111222333444:actionType:Custom/Test/TestProvider/1"
            ]
        }
    ]
}

Ejemplo 6: Adjunte o edite una política para la integración de Jenkins con AWS CodePipeline

Si configura una canalización para usar Jenkins para compilar o probar, cree una identidad independiente para esa integración y adjunte una política de IAM que tenga los permisos mínimos necesarios para la integración entre Jenkins y. CodePipeline Esta política es la misma que la política administrada AWSCodePipelineCustomActionAccess. En el siguiente ejemplo, se muestra una política para la integración de Jenkins:

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

Ejemplo 7: Configurar el acceso entre cuentas en una canalización

Puede configurar el acceso a canalizaciones para los usuarios y los grupos de otra cuenta de AWS . La forma recomendada es crear un rol en la cuenta donde se creó la canalización. El rol debería permitir a los usuarios de la otra AWS cuenta asumir ese rol y acceder a la canalización. Para obtener más información, consulte Walkthrough: Cross-Account Access Using Roles.

El siguiente ejemplo muestra una política en la cuenta 80398EXAMPLE que permite a los usuarios ver, pero no cambiar, la canalización nombrada MyFirstPipeline en la CodePipeline consola. Esta política se basa en la política administrada AWSCodePipeline_ReadOnlyAccess, pero como es específica de la canalización MyFirstPipeline, no puede usar la política administrada directamente. Si no desea restringir la política a una canalización específica, considere la posibilidad de usar una de las políticas administradas que CodePipeline crea y mantiene. Para obtener más información, consulte Uso de políticas administradas. Debe asociar esta política a un rol de IAM que cree para obtener acceso (por ejemplo, a un rol denominado 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"
}

Después de crear esta política, cree el rol de IAM en la cuenta 80398EXAMPLE y asocie la política a ese rol. En las relaciones de confianza del rol, debe agregar la AWS cuenta que asume este rol. El siguiente ejemplo muestra una política que permite a los usuarios de la 111111111111 AWS cuenta asumir las funciones definidas en la cuenta 80398EXAMPLE:

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

El siguiente ejemplo muestra una política creada en la 111111111111 AWS cuenta que permite a los usuarios asumir el rol nombrado CrossAccountPipelineViewers en la cuenta 80398EXAMPLE:

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

Ejemplo 8: Usar recursos de AWS asociados a otra cuenta en una canalización

Puede configurar políticas que permitan a un usuario crear una canalización que utilice los recursos de otra AWS cuenta. Para ello, es necesario configurar políticas y roles en la cuenta que crea la canalización (Cuenta A) y en la cuenta que creó los recursos que se van a usar en la canalización (Cuenta B). También debes crear una clave gestionada por el cliente AWS Key Management Service para utilizarla en el acceso entre cuentas. Para obtener más información y step-by-step ejemplos, consulte Crear una canalización en CodePipeline que use recursos de otra cuenta de AWS yConfigurar el cifrado del lado del servidor para los artefactos almacenados en Amazon S3 para CodePipeline.

En el ejemplo siguiente se muestra una política configurada por la AccountA para un bucket de S3 utilizado para almacenar artefactos de canalización. La política concede acceso a la AccountB. En el siguiente ejemplo, el ARN de la AccountB es 012ID_ACCOUNT_B. El ARN del bucket de S3 es codepipeline-us-east-2-1234567890. Sustitúyalos ARNs ARNs por los del bucket de S3 y la cuenta a la que quieres permitir el acceso:

{
    "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"
        }
    ]
}

En el siguiente ejemplo, se muestra una política configurada por la Cuenta A que permite a la AccountB asumir un rol. Esta política se debe aplicar al rol de servicio de CodePipeline (CodePipeline_Service_Role). Para obtener más información sobre cómo aplicar políticas a roles en IAM, consulte Modificación de un rol. En el siguiente ejemplo, 012ID_ACCOUNT_B es el ARN de la AccountB:

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

En el siguiente ejemplo, se muestra una política configurada por AccountB y aplicada al rol de EC2 instancia para. CodeDeploy Esta política concede acceso al bucket de S3 que usa la Cuenta A para almacenar artefactos de canalizaciones (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"
            ]
        }
    ]
}

El siguiente ejemplo muestra una política en la que se indica AWS KMS dónde arn:aws:kms:us-east-1:012ID_ACCOUNT_A:key/2222222-3333333-4444-556677EXAMPLE está el ARN de la clave gestionada por el cliente creada en AccountA y configurada para permitir que AccountB la utilice:

{
    "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"
            ]
        }
    ]
}

El siguiente ejemplo muestra una política en línea para un rol de IAM (CrossAccount_Role) creado por AccountB que permite el acceso a CodeDeploy las acciones requeridas por la canalización en AccountA.

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

En el siguiente ejemplo, se muestra una política insertada para un rol de IAM (CrossAccount_Role) creado por la Cuenta B que permite el acceso al bucket de S3 para poder descargar los artefactos de entrada y subir los de salida:

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

Para obtener más información acerca de cómo editar una canalización para el acceso entre cuentas a los recursos, consulte Paso 2: Editar la canalización .