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, IAM los usuarios y los roles no tienen permiso para crear o modificar CodePipeline recursos. Tampoco pueden realizar tareas con AWS Management Console AWS CLI, o AWS API. IAMEl administrador debe crear IAM políticas que concedan a los usuarios y roles permisos para realizar API operaciones específicas en los recursos específicos que necesitan. A continuación, el administrador debe adjuntar esas políticas a los IAM usuarios o grupos que requieran esos permisos.

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

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. Crea una canalización CodePipeline que utilice recursos de otra AWS cuenta

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 CodePipeline API, AWS SDKs, o 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

El trabajador de una acción personalizada puede estar configurado en una AWS cuenta diferente o requerir un IAM rol específico para funcionar.

{
    "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 configuras una canalización para usar Jenkins para compilar o probar, crea una identidad independiente para esa integración y adjunta una IAM política 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 EXAMPLE cuenta 80398 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 quiere restringir la política a una canalización específica, considere la posibilidad de utilizar una de las políticas gestionadas que ha creado y mantenido. CodePipeline Para obtener más información, consulte Uso de políticas administradas. Debe adjuntar esta política a un IAM rol que cree para acceder, por ejemplo, un rol llamadoCrossAccountPipelineViewers:

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

Tras crear esta política, cree el IAM rol en la EXAMPLE cuenta 80398 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 del 111111111111 AWS cuenta para asumir las funciones definidas en la EXAMPLE cuenta 80398:

{
    "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 el 111111111111 AWS cuenta que permite a los usuarios asumir la función nombrada CrossAccountPipelineViewers en la EXAMPLE cuenta 80398:

{
    "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 Crea una canalización CodePipeline que utilice recursos de otra AWS cuenta 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, ARN para AccountB es. 012ID_ACCOUNT_B El ARN para el bucket de S3 escodepipeline-us-east-2-1234567890. Sustitúyalos ARNs ARNs por los del depósito 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 debe aplicarse a la función de servicio de CodePipeline (CodePipeline_Service_Role). Para obtener más información sobre cómo aplicar políticas a los roles enIAM, consulte Modificación de un rol. En el siguiente ejemplo, 012ID_ACCOUNT_B es el ARN de 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 otorga acceso al depósito de S3 utilizado por AccountA para almacenar los artefactos de la canalización (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á ARN 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 IAM rol (CrossAccount_Role) creado por AccountB que permite el acceso CodeDeploy a 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": "*"
        }
    ]
}

El siguiente ejemplo muestra una política en línea para un IAM rol (CrossAccount_Role) creado por AccountB que permite el acceso al bucket de S3 para descargar artefactos de entrada y cargar artefactos 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 .