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 la identidad
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 con la API Consola de administración de AWS AWS CLI, o AWS . 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) 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 [Crea una canalización CodePipeline que utilice recursos de otra AWS cuenta](pipelines-create-cross-account.md).
**Topics**
+ [Prácticas recomendadas sobre las políticas](security_iam_service-with-iam-policy-best-practices.md)
+ [Visualización de recursos en la consola](security-iam-resources-console.md)
+ [Cómo permitir a los usuarios consultar sus propios permisos](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Ejemplos de políticas basadas en identidad (IAM)](security-iam-id-policies-examples.md)
+ [Uso de etiquetas para controlar el acceso a los recursos CodePipeline](tag-based-access-control.md)
+ [Permisos necesarios para usar la consola](security-iam-permissions-console.md)
+ [Permisos necesarios para ver los registros de procesamiento en la consola](security-iam-permissions-console-logs.md)
+ [AWS políticas gestionadas para AWS CodePipeline](managed-policies.md)
+ [Ejemplos de políticas administradas por el cliente](#customer-managed-policies)
## Ejemplos de políticas administradas por el cliente
En esta sección, encontrará ejemplos de políticas de usuario que conceden permisos para diversas acciones de . Estas políticas funcionan cuando se utiliza la API o la AWS CLI. AWS SDKs 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](security-iam-permissions-console.md).
**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](#identity-based-policies-example-1)
+ [Ejemplo 2: Conceder permisos para activar y desactivar las transiciones entre etapas](#identity-based-policies-example-2)
+ [Ejemplo 3: Conceder permisos para obtener una lista de todos los tipos de acciones disponibles](#identity-based-policies-example-3)
+ [Ejemplo 4: Conceder permisos para autorizar o rechazar acciones de aprobación manual](#identity-based-policies-example-4)
+ [Ejemplo 5: Conceder permisos para sondear trabajos en una acción personalizada](#identity-based-policies-example-5)
+ [Ejemplo 6: Adjunte o edite una política para la integración de Jenkins con AWS CodePipeline](#identity-based-policies-example-6)
+ [Ejemplo 7: Configurar el acceso entre cuentas en una canalización](#identity-based-policies-example-7)
### 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`:
------
#### [ JSON ]
****
```
{
"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`:
------
#### [ JSON ]
****
```
{
"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`:
------
#### [ JSON ]
****
```
{
"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`:
------
#### [ JSON ]
****
```
{
"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.
------
#### [ JSON ]
****
```
{
"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. 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:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:AcknowledgeJob",
"codepipeline:GetJobDetails",
"codepipeline:PollForJobs",
"codepipeline:PutJobFailureResult",
"codepipeline:PutJobSuccessResult"
],
"Resource": "*"
}
]
}
```
------
### 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/walkthru_cross-account-with-roles.html).
En el siguiente ejemplo, se muestra una política en la cuenta 80398EXAMPLE que permite a los usuarios ver, pero no cambiar, la canalización nombrada `MyFirstPipeline` en la 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 crea y mantiene. Para obtener más información, consulte [Uso de políticas administradas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html). Debe asociar esta política a un rol de IAM que cree para obtener acceso (por ejemplo, a un rol denominado `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"
}
]
}
```
------
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 creada en la {{111111111111}} AWS cuenta que permite a los usuarios asumir el rol nombrado `CrossAccountPipelineViewers` en la cuenta 80398EXAMPLE:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::{{111122223333}}:role/{{CrossAccountPipelineViewers}}"
}
]
}
```
------