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.
# Seguridad en AWS CodePipeline
La seguridad en la nube AWS es la máxima prioridad. Como AWS cliente, usted se beneficia de los centros de datos y las arquitecturas de red diseñados para cumplir con los requisitos de las organizaciones más sensibles a la seguridad.
La seguridad es una responsabilidad compartida entre AWS usted y usted. El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) la describe como seguridad *de* la nube y seguridad *en* la nube:
+ **Seguridad de la nube**: AWS es responsable de proteger la infraestructura que ejecuta AWS los servicios en la Nube de AWS. AWS también le proporciona servicios que puede utilizar de forma segura. Los auditores externos prueban y verifican periódicamente la eficacia de nuestra seguridad como parte de los [AWS programas](https://aws.amazon.com/compliance/programs/) de de . Para obtener más información sobre los programas de cumplimiento aplicables AWS CodePipeline, consulte [AWS Servicios incluidos en el ámbito de aplicación por programa de conformidad y AWS servicios incluidos](https://aws.amazon.com/compliance/services-in-scope/) .
+ **Seguridad en la nube**: su responsabilidad viene determinada por el AWS servicio que utilice. También es responsable de otros factores, incluida la confidencialidad de los datos, los requisitos de la empresa y la legislación y los reglamentos vigentes.
Esta documentación le ayuda a comprender cómo aplicar el modelo de responsabilidad compartida cuando se utiliza CodePipeline. Los siguientes temas muestran cómo configurarlo CodePipeline para cumplir sus objetivos de seguridad y conformidad. También aprenderá a utilizar otros AWS servicios que le ayudan a supervisar y proteger sus CodePipeline recursos.
**Topics**
+ [Protección de datos en AWS CodePipeline](data-protection.md)
+ [Gestión de identidad y acceso para AWS CodePipeline](security-iam.md)
+ [Inicio de sesión y supervisión CodePipeline](incident-response.md)
+ [Validación de conformidad para AWS CodePipeline](compliance-validation.md)
+ [Resiliencia en AWS CodePipeline](disaster-recovery-resiliency.md)
+ [Seguridad de la infraestructura en AWS CodePipeline](infrastructure-security.md)
+ [Prácticas recomendadas de seguridad](security-best-practices.md)
# Protección de datos en AWS CodePipeline
El modelo de [responsabilidad AWS compartida modelo](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica a la protección de datos en. Como se describe en este modelo, AWS es responsable de proteger la infraestructura global que ejecuta todos los Nube de AWS. Eres responsable de mantener el control sobre el contenido alojado en esta infraestructura. También eres responsable de las tareas de administración y configuración de seguridad para los Servicios de AWS que utiliza. Para obtener más información sobre la privacidad de los datos, consulte las [Preguntas frecuentes sobre la privacidad de datos](https://aws.amazon.com/compliance/data-privacy-faq/). Para obtener información sobre la protección de datos en Europa, consulte la publicación de blog sobre el [Modelo de responsabilidad compartida de AWS y GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) en el * Blog de seguridad de AWS *.
Con fines de protección de datos, le recomendamos que proteja Cuenta de AWS las credenciales y configure los usuarios individuales con AWS IAM Identity Center o AWS Identity and Access Management (IAM). De esta manera, solo se otorgan a cada usuario los permisos necesarios para cumplir sus obligaciones laborales. También recomendamos proteger sus datos de la siguiente manera:
+ Utiliza la autenticación multifactor (MFA) en cada cuenta.
+ Se utiliza SSL/TLS para comunicarse con AWS los recursos. Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Configure la API y el registro de actividad de los usuarios con AWS CloudTrail. Para obtener información sobre el uso de CloudTrail senderos para capturar AWS actividades, consulte [Cómo trabajar con CloudTrail senderos](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) en la *Guía del AWS CloudTrail usuario*.
+ Utilice soluciones de AWS cifrado, junto con todos los controles de seguridad predeterminados Servicios de AWS.
+ Utiliza servicios de seguridad administrados avanzados, como Amazon Macie, que lo ayuden a detectar y proteger la información confidencial almacenada en Amazon S3.
+ Si necesita módulos criptográficos validados por FIPS 140-3 para acceder a AWS través de una interfaz de línea de comandos o una API, utilice un punto final FIPS. Para obtener más información sobre los puntos de conexión de FIPS disponibles, consulte [Estándar de procesamiento de la información federal (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Se recomienda encarecidamente no introducir nunca información confidencial o sensible, como por ejemplo, direcciones de correo electrónico de clientes, en etiquetas o campos de formato libre, tales como el campo **Nombre**. Esto incluye cuando trabaja con o Servicios de AWS utiliza la consola, la API o AWS CLI AWS SDKs Cualquier dato que introduzca en etiquetas o campos de formato libre utilizados para los nombres se pueden emplear para los registros de facturación o diagnóstico. Si proporciona una URL a un servidor externo, recomendamos encarecidamente que no incluya información de credenciales en la URL a fin de validar la solicitud para ese servidor.
Las siguientes prácticas recomendadas sobre seguridad también evalúan la protección de datos en CodePipeline:
+ [Configurar el cifrado del lado del servidor para los artefactos almacenados en Amazon S3 para CodePipeline](S3-artifact-encryption.md)
+ [Se utiliza AWS Secrets Manager para rastrear las contraseñas de bases de datos o las claves de API de terceros](parameter-store-encryption.md)
## Privacidad del tráfico entre redes
Amazon VPC es una Servicio de AWS que puede utilizar para lanzar AWS recursos en una red virtual (*nube privada virtual*) que usted defina. CodePipelinees compatible con los puntos de enlace de Amazon VPC con tecnología AWS PrivateLink, una AWS tecnología que facilita la comunicación privada entre el Servicios de AWS uso de una interfaz de red elástica con direcciones IP privadas. Esto significa que puede conectarse directamente a CodePipeline través de un punto final privado en su VPC, manteniendo todo el tráfico dentro de su VPC y de la red. AWS Anteriormente, las aplicaciones que se ejecutaban dentro de una VPC necesitaban acceso a Internet para conectarse a CodePipeline. Con una VPC, tiene control sobre los ajustes de red, como por ejemplo:
+ Rango de direcciones IP,
+ Subredes,
+ Tablas de enrutamiento y
+ Gateways de red
Para conectar su VPC CodePipeline, debe definir un punto final de VPC de interfaz para. CodePipeline Este tipo de punto de conexión le permite conectar su VPC a servicios de Servicios de AWS. El punto final proporciona una conectividad fiable y escalable CodePipeline sin necesidad de una puerta de enlace a Internet, una instancia de traducción de direcciones de red (NAT) ni una conexión VPN. Para obtener más información acerca de cómo configurar una VPC, consulte la [Guía del usuario de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
## Cifrado en reposo
Los datos entrantes CodePipeline se cifran en reposo mediante AWS KMS keys. Los artefactos de código se almacenan en un depósito de S3 propiedad del cliente y se cifran con la clave gestionada por el cliente Clave administrada de AWS o con una clave gestionada por el cliente. Para obtener más información, consulte [Configurar el cifrado del lado del servidor para los artefactos almacenados en Amazon S3 para CodePipeline](S3-artifact-encryption.md).
## Cifrado en tránsito
Todas las service-to-service comunicaciones en tránsito se cifran mediante SSL/TLS.
## Administración de claves de cifrado
Si elige la opción predeterminada para cifrar los artefactos de código, utiliza la. CodePipeline Clave administrada de AWS No puede cambiarlo ni eliminarlo Clave administrada de AWS. Si utiliza una clave gestionada por el cliente AWS KMS para cifrar o descifrar los artefactos del depósito de S3, puede cambiar o rotar esta clave gestionada por el cliente según sea necesario.
**importante**
CodePipeline solo admite claves KMS simétricas. No utilice una clave de KMS asimétrica para cifrar los datos en el bucket de S3.
**Topics**
# Configurar el cifrado del lado del servidor para los artefactos almacenados en Amazon S3 para CodePipeline
Hay dos formas de configurar el cifrado del lado servidor para los artefactos de Amazon S3:
+ CodePipeline crea un depósito de artefactos de S3 y lo establece de forma predeterminada Clave administrada de AWS al crear una canalización mediante el asistente Crear canalización. Clave administrada de AWS Se cifra junto con los datos del objeto y se gestiona mediante AWS.
+ Puede crear y administrar su propia clave administrada por el cliente.
**importante**
CodePipeline solo admite claves KMS simétricas. No utilice una clave de KMS asimétrica para cifrar los datos en el bucket de S3.
Si utiliza la clave de S3 predeterminada, no podrá cambiar ni eliminar esta Clave administrada de AWS. Si utiliza una clave administrada por el cliente AWS KMS para cifrar o descifrar los artefactos del bucket de S3, puede cambiar o rotar esta clave administrada por el cliente según sea necesario.
Amazon S3 admite políticas de bucket que podrá usar si requiere cifrado del lado del servidor para todos los objetos almacenados en un bucket. Por ejemplo, la siguiente política de bucket deniega el permiso de carga de objeto (`s3:PutObject`) para todos, si la solicitud no incluye el encabezado `x-amz-server-side-encryption`, que solicita el cifrado del lado del servidor con SSE-KMS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "SSEAndSSLPolicy",
"Statement": [
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyInsecureConnections",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
------
Para obtener más información sobre el cifrado del lado del servidor AWS KMS, consulte [Protección de datos mediante el cifrado del lado del servidor y Protección de los datos mediante el cifrado del lado del](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) servidor [con claves de KMS almacenadas en (SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)). AWS Key Management Service
[Para obtener más información al respecto, consulte la Guía para desarrolladores. AWS KMSAWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/)
**Topics**
+ [Vea su Clave administrada de AWS](#S3-view-default-keys)
+ [Configure el cifrado del lado del servidor para los buckets de S3 mediante o CloudFormation AWS CLI](#S3-rotate-customer-key)
## Vea su Clave administrada de AWS
Cuando se usa el asistente **Create Pipeline (Crear canalización)** para crear la primera canalización, se crea un bucket de S3 automáticamente en la misma región en la que se creó la canalización. El bucket se utiliza para almacenar artefactos de canalización. Cuando se ejecuta una canalización, los artefactos se colocan y se recuperan en el bucket de S3. De forma predeterminada, CodePipeline utiliza el cifrado del lado del servidor con el AWS KMS uso Clave administrada de AWS de Amazon S3 (la `aws/s3` clave). Clave administrada de AWS Se crea y almacena en su cuenta. AWS Cuando se recuperan los artefactos del depósito de S3, CodePipeline utiliza el mismo proceso SSE-KMS para descifrar el artefacto.
**Para ver información sobre su Clave administrada de AWS**
1. Inicie sesión en la AWS KMS consola Consola de administración de AWS y ábrala.
1. Si aparece una página de bienvenida, elija **Empezar ahora**.
1. En el panel de navegación, elija **Claves administradas de AWS **.
1. En Filtrar, elija la región de la canalización. Por ejemplo, si la canalización se creó en `us-east-2`, asegúrese de que el filtro esté establecido en Este de EE. UU. (Ohio).
Para obtener más información sobre las regiones y los puntos de conexión disponibles CodePipeline, consulta los puntos de conexión [y las AWS CodePipeline cuotas](https://docs.aws.amazon.com/general/latest/gr/codepipeline.html).
1. En la lista de claves de cifrado, elija la clave con el alias usado para su canalización (de forma predeterminada, **aws/s3**). Se mostrará información básica acerca de la clave.
## Configure el cifrado del lado del servidor para los buckets de S3 mediante o CloudFormation AWS CLI
Al utilizar CloudFormation o AWS CLI para crear una canalización, debe configurar el cifrado del lado del servidor manualmente. Utilice la política de bucket de ejemplo anterior y, a continuación, cree su propia clave administrada por el cliente. También puede usar sus propias claves en lugar de la clave predeterminada de Clave administrada de AWS. Algunas de las razones para elegir su propia clave son las siguientes:
+ Desea rotar la clave según una programación para satisfacer los requisitos de negocio o de seguridad de la organización.
+ Desea crear una canalización que use los recursos asociados a otra cuenta de AWS . Esto requiere el uso de una clave administrada por el cliente. Para obtener más información, consulte [Crea una canalización CodePipeline que utilice recursos de otra AWS cuenta](pipelines-create-cross-account.md).
Las prácticas criptográficas recomendadas desaconsejan la reutilización generalizada de claves de cifrado. Es recomendable que rote la clave con regularidad. Para crear nuevo material criptográfico para sus AWS KMS claves, puede crear una clave gestionada por el cliente y, a continuación, cambiar las aplicaciones o los alias para utilizar la nueva clave gestionada por el cliente. También puede habilitar la rotación automática de claves para una clave administrada por el cliente existente.
Para rotar la clave gestionada por el cliente, consulte [Rotación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html).
**importante**
CodePipeline solo admite claves KMS simétricas. No utilice una clave de KMS asimétrica para cifrar los datos en el bucket de S3.
# Se utiliza AWS Secrets Manager para rastrear las contraseñas de bases de datos o las claves de API de terceros
Le recomendamos que lo utilice AWS Secrets Manager para rotar, administrar y recuperar las credenciales de la base de datos, las claves de API y otros **secretos** a lo largo de su ciclo de vida. Secrets Manager le permite reemplazar las credenciales codificadas en el código (incluidas contraseñas), con una llamada a la API de Secrets Manager para recuperar el secreto mediante programación. Para obtener más información, consulte [¿Qué es AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) en la *Guía del usuario de AWS Secrets Manager*.
En el caso de las canalizaciones en las que se pasan parámetros secretos (como OAuth las credenciales) a una CloudFormation plantilla, se deben incluir referencias dinámicas en la plantilla que accedan a los secretos que se han almacenado en Secrets Manager. Para ver patrones y ejemplos del ID de referencia, consulte [Secrets Manager Secrets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-secretsmanager) en la *Guía del usuario de AWS CloudFormation *. [Para ver un ejemplo en el que se utilizan referencias dinámicas en un fragmento de plantilla para un GitHub webhook en una canalización, consulte Configuración de recursos de Webhook.](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-webhook.html#aws-resource-codepipeline-webhook--examples)
## Véase también
Los siguientes recursos relacionados pueden ayudarle mientras trabaja con la administración de secretos.
+ Secrets Manager puede rotar automáticamente las credenciales de la base de datos, por ejemplo, para la rotación de secretos de Amazon RDS. Para obtener más información, [consulte Rotación de AWS los secretos de Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) en la *Guía del usuario de AWS Secrets Manager*.
+ Para consultar las instrucciones para agregar referencias dinámicas de Secrets Manager a las plantillas de CloudFormation , consulte [https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/](https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/).
# Gestión de identidad y acceso para AWS CodePipeline
AWS Identity and Access Management (IAM) es una herramienta Servicio de AWS que ayuda al administrador a controlar de forma segura el acceso a AWS los recursos. Los administradores de IAM controlan quién puede *autenticarse (iniciar* sesión) y quién puede *autorizarse* (tener permisos) para usar los recursos. CodePipeline La IAM es una Servicio de AWS opción que puede utilizar sin coste adicional.
**Topics**
+ [Público](#security_iam_audience)
+ [Autenticación con identidades](#security_iam_authentication)
+ [Administración del acceso con políticas](#security_iam_access-manage)
+ [¿Cómo AWS CodePipeline funciona con IAM](security_iam_service-with-iam.md)
+ [AWS CodePipeline ejemplos de políticas basadas en la identidad](security_iam_id-based-policy-examples.md)
+ [AWS CodePipeline ejemplos de políticas basadas en recursos](security_iam_resource-based-policy-examples.md)
+ [Solución de problemas de AWS CodePipeline identidad y acceso](security_iam_troubleshoot.md)
+ [referencia de permisos](permissions-reference.md)
+ [Administre la función CodePipeline de servicio](how-to-custom-role.md)
## Público
La forma de usar AWS Identity and Access Management (IAM) varía según la función que desempeñes:
+ **Usuario del servicio:** solicite permisos al administrador si no puede acceder a las características (consulte [Solución de problemas de AWS CodePipeline identidad y acceso](security_iam_troubleshoot.md)).
+ **Administrador del servicio:** determine el acceso de los usuarios y envíe las solicitudes de permiso (consulte [¿Cómo AWS CodePipeline funciona con IAM](security_iam_service-with-iam.md)).
+ **Administrador de IAM**: escribe las políticas para administrar el acceso (consulte [AWS CodePipeline ejemplos de políticas basadas en la identidad](security_iam_id-based-policy-examples.md)).
## Autenticación con identidades
La autenticación es la forma en que inicias sesión AWS con tus credenciales de identidad. Debe autenticarse como usuario de Usuario raíz de la cuenta de AWS IAM o asumir una función de IAM.
Puede iniciar sesión como una identidad federada con las credenciales de una fuente de identidad, como AWS IAM Identity Center (IAM Identity Center), la autenticación de inicio de sesión único o las credenciales. Google/Facebook Para obtener más información sobre el inicio de sesión, consulte [Cómo iniciar sesión en la Cuenta de AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) en la *Guía del usuario de AWS Sign-In *.
Para el acceso programático, AWS proporciona un SDK y una CLI para firmar criptográficamente las solicitudes. Para obtener más información, consulte [AWS Signature Version 4 para solicitudes de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) en la *Guía del usuario de IAM*.
### Usuario raíz de la cuenta de AWS
Al crear una Cuenta de AWS, se comienza con una identidad de inicio de sesión denominada *usuario Cuenta de AWS raíz*, que tiene acceso completo a todos los Servicios de AWS recursos. Se recomiendaencarecidamente que no utilice el usuario raíz para las tareas diarias. Para ver la lista completa de las tareas que requieren credenciales de usuario raíz, consulte [Tareas que requieren credenciales de usuario raíz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) en la *Guía del usuario de IAM*.
### Usuarios y grupos de IAM
Un *[usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* es una identidad con permisos específicos para una sola persona o aplicación. Recomendamos el uso de credenciales temporales en lugar de usuarios de IAM con credenciales de larga duración. Para obtener más información, consulte [Exigir a los usuarios humanos que utilicen la federación con un proveedor de identidad para acceder AWS mediante credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la Guía del *usuario de IAM*.
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica un conjunto de usuarios de IAM y facilita la administración de los permisos para grupos grandes de usuarios. Para obtener más información, consulte [Casos de uso para usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) en la *Guía del usuario de IAM*.
### Roles de IAM
Un *[Rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* es una identidad con permisos específicos que proporciona credenciales temporales. Puede asumir un rol [cambiando de un rol de usuario a uno de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) o llamando a una AWS CLI operación de AWS API. Para obtener más información, consulte [Métodos para asumir un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) en la *Guía del usuario de IAM*.
Los roles de IAM son útiles para el acceso de usuario federado, los permisos de usuario de IAM temporales, el acceso entre cuentas, el acceso entre servicios y las aplicaciones que se ejecutan en Amazon EC2. Para obtener más información, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
## Administración del acceso con políticas
AWS Para controlar el acceso, puede crear políticas y adjuntarlas a AWS identidades o recursos. Una política define los permisos cuando están asociados a una identidad o un recurso. AWS evalúa estas políticas cuando un director hace una solicitud. La mayoría de las políticas se almacenan AWS como documentos JSON. Para obtener más información sobre los documentos de políticas de JSON, consulte [Información general de políticas de JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) en la *Guía del usuario de IAM*.
Mediante las políticas, los administradores especifican quién tiene acceso a qué, definiendo qué **entidad principal** puede realizar **acciones** sobre qué **recursos** y en qué **condiciones**.
De forma predeterminada, los usuarios y los roles no tienen permisos. Un administrador de IAM crea políticas de IAM y las agrega a roles, que los usuarios pueden asumir posteriormente. Las políticas de IAM definen permisos independientemente del método que se utilice para realizar la operación.
### Políticas basadas en identidades
Las políticas basadas en identidad son documentos de política de permisos JSON que asocia a una identidad (usuario, grupo o rol). Estas políticas controlan qué acciones pueden realizar las identidades, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
Las políticas basadas en identidad pueden ser *políticas insertadas* (incrustadas directamente en una sola identidad) o *políticas administradas* (políticas independientes asociadas a varias identidades). Para obtener información sobre cómo elegir entre políticas administradas e insertadas, consulte [Selección entre políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) en la *Guía del usuario de IAM*.
### Políticas basadas en recursos
Las políticas basadas en recursos son documentos de políticas JSON que se asocian a un recurso. Los ejemplos incluyen las *Políticas de confianza de roles* de IAM y las *Políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos.
Las políticas basadas en recursos son políticas insertadas que se encuentran en ese servicio. No puedes usar políticas AWS gestionadas de IAM en una política basada en recursos.
### Otros tipos de políticas
AWS admite tipos de políticas adicionales que pueden establecer los permisos máximos que conceden los tipos de políticas más comunes:
+ **Límites de permisos:** establecen los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM. Para obtener más información, consulte [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) en la *Guía del usuario de IAM*.
+ **Políticas de control de servicios (SCPs)**: especifican los permisos máximos para una organización o unidad organizativa en AWS Organizations. Para obtener más información, consulte [Políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la *Guía del usuario de AWS Organizations *.
+ **Políticas de control de recursos (RCPs)**: establece los permisos máximos disponibles para los recursos de tus cuentas. Para obtener más información, consulte [Políticas de control de recursos (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) en la *Guía del AWS Organizations usuario*.
+ **Políticas de sesión:** políticas avanzadas que se pasan como parámetro cuando se crea una sesión temporal para un rol o un usuario federado. Para obtener más información, consulte [Políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) en la *Guía del usuario de IAM*.
# ¿Cómo AWS CodePipeline funciona con IAM
Antes de utilizar IAM para gestionar el acceso CodePipeline, debe comprender las funciones de IAM disponibles para su uso. CodePipeline *Para obtener una visión general de cómo CodePipeline y otras Servicios de AWS formas de trabajar con IAM, consulte Servicios de AWS Cómo funcionan con IAM en la [Guía del usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*
**Topics**
+ [CodePipeline políticas basadas en la identidad](#security_iam_service-with-iam-id-based-policies)
+ [CodePipeline políticas basadas en recursos](#security_iam_service-with-iam-resource-based-policies)
+ [Autorización basada en etiquetas CodePipeline](#security_iam_service-with-iam-tags)
+ [CodePipeline Funciones de IAM](#security_iam_service-with-iam-roles)
## CodePipeline políticas basadas en la identidad
Con las políticas basadas en identidad de IAM, puede especificar las acciones permitidas o denegadas y los recursos, además de las condiciones en las que se permiten o deniegan las acciones. CodePipeline admite acciones, recursos y claves de condiciones específicos. Para obtener información sobre todos los elementos que utiliza en una política JSON, consulte [Referencia de los elementos de las políticas JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) en la *Guía del usuario de IAM*.
### Acciones
Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Action` de una política JSON describe las acciones que puede utilizar para conceder o denegar el acceso en una política. Incluya acciones en una política para conceder permisos y así llevar a cabo la operación asociada.
Las acciones políticas CodePipeline utilizan el siguiente prefijo antes de la acción:`codepipeline:`.
Por ejemplo, para conceder a alguien permiso para ver las canalizaciones existentes en la cuenta, debe incluir la acción `codepipeline:GetPipeline` en su política. Las declaraciones de política deben incluir un `NotAction` elemento `Action` o. CodePipeline define su propio conjunto de acciones que describen las tareas que puede realizar con este servicio.
Para especificar varias acciones en una única instrucción, sepárelas con comas del siguiente modo:
```
"Action": [
"codepipeline:action1",
"codepipeline:action2"
```
Puede utilizar caracteres comodín para especificar varias acciones (\$1). Por ejemplo, para especificar todas las acciones que comiencen con la palabra `Get`, incluya la siguiente acción:
```
"Action": "codepipeline:Get*"
```
Para obtener una lista de CodePipeline acciones, consulte [las acciones definidas por AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions) en la *Guía del usuario de IAM*.
### Recursos
Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Resource` de la política JSON especifica el objeto u objetos a los que se aplica la acción. Como práctica recomendada, especifique un recurso utilizando el [Nombre de recurso de Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). En el caso de las acciones que no admiten permisos por recurso, utilice un carácter comodín (\$1) para indicar que la instrucción se aplica a todos los recursos.
```
"Resource": "*"
```
#### recursos y operaciones
En , el recurso principal es una canalización. En una política, se usa un nombre de recurso de Amazon (ARN) para identificar el recurso al que se aplica la política. es compatible con otros recursos que se pueden usar con el recurso principal, como etapas, acciones y acciones personalizadas. Estos elementos se denominan subrecursos. Estos recursos y subrecursos tienen nombres de recursos de Amazon (ARNs) exclusivos asociados a ellos. Para obtener más información al respecto ARNs, consulte [Nombres de recursos de Amazon (ARN) y espacios de Servicio de AWS nombres](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) en. *Referencia general de Amazon Web Services* Para obtener el ARN de canalización asociado a tu canalización, puedes encontrar el ARN de la canalización en **Configuración** de la consola. Para obtener más información, consulte [Ver el ARN de la canalización y el ARN del rol de servicio (consola)](pipelines-settings-console.md).
| Tipo de recurso | Formato de ARN |
| --- | --- |
| Canalización | arn:aws:codepipeline::: *region* *account* *pipeline-name* |
| Etapa | arn:aws:codepipeline:::/*region**account**pipeline-name**stage-name* |
| Action | arn:aws:codepipeline:::/*region**account**pipeline-name**stage-name**action-name* |
| Acción personalizada | arn:aws:codepipeline: ::tipo de acción:///regionaccountownercategoryproviderversion |
| Todos los recursos | arn:aws:codepipeline:\$1 |
| Todos los recursos de que pertenecen a la cuenta especificada en la región indicada | arn:aws:codepipeline*region*::*account*: \$1 |
**nota**
La mayoría de los servicios de AWS utilizan dos puntos (:)) o una barra diagonal (/) como el mismo carácter en. ARNs Sin embargo, utiliza una coincidencia exacta en los patrones de eventos y reglas. Se deben usar los caracteres de ARN correctos al crear patrones de eventos para que coincidan con la sintaxis de ARN de la canalización que desee usar.
En , existen las llamadas a la API que admiten permisos de nivel de recursos. Los permisos de nivel de recursos indican si una llamada a la API puede especificar un ARN de recurso, o si solo puede especificar todos los recursos mediante el carácter comodín. Consulte [referencia de permisos](permissions-reference.md) para obtener una descripción detallada de los permisos a nivel de recursos y una lista de las llamadas a la CodePipeline API que admiten los permisos a nivel de recursos.
Por ejemplo, puede indicar una canalización específica (*myPipeline*) en su declaración utilizando su ARN de la siguiente manera:
```
"Resource": "arn:aws:codepipeline:us-east-2:111222333444:myPipeline"
```
También puede especificar todas las canalizaciones que pertenezcan a una cuenta específica mediante el carácter comodín (\$1) del modo siguiente:
```
"Resource": "arn:aws:codepipeline:us-east-2:111222333444:*"
```
Para especificar todos los recursos, o si una acción específica de la API no es compatible ARNs, utiliza el carácter comodín (\$1) del `Resource` elemento de la siguiente manera:
```
"Resource": "*"
```
**nota**
Al crear políticas de IAM, siga los consejos de seguridad estándar de concesión de privilegios mínimos, es decir, conceder solo los permisos necesarios para realizar una tarea. Si una llamada a la API es compatible ARNs, entonces admite permisos a nivel de recurso y no es necesario utilizar el carácter comodín (\$1).
Algunas llamadas a la API aceptan varios recursos (por ejemplo,). `GetPipeline` Para especificar varios recursos en una sola sentencia, sepárelos ARNs con comas, de la siguiente manera:
```
"Resource": ["arn1", "arn2"]
```
proporciona un conjunto de operaciones para trabajar con los recursos. Para ver la lista de las operaciones disponibles, consulte [referencia de permisos](permissions-reference.md).
### Claves de condición
Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Condition` especifica cuándo se ejecutan las instrucciones en función de criterios definidos. Puede crear expresiones condicionales que utilizan [operadores de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tales como igual o menor que, para que la condición de la política coincida con los valores de la solicitud. Para ver todas las claves de condición AWS globales, consulte las claves de [contexto de condición AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) en la *Guía del usuario de IAM*.
CodePipeline define su propio conjunto de claves de condición y también admite el uso de algunas claves de condición globales. Para ver todas las claves de condición AWS globales, consulte las claves de [contexto de condición AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) en la *Guía del usuario de IAM*.
Todas las acciones de Amazon EC2 admiten las claves de condición `aws:RequestedRegion` y `ec2:Region`. Para obtener más información, consulte [Ejemplo: restricción del acceso a una región específica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
Para ver una lista de claves de CodePipeline condición, consulte las claves de [condición AWS CodePipeline en la](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys) Guía del *usuario de IAM*. Para saber con qué acciones y recursos puede utilizar una clave de condición, consulte [Acciones definidas por AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions).
### Ejemplos
Para ver ejemplos de políticas CodePipeline basadas en la identidad, consulte. [AWS CodePipeline ejemplos de políticas basadas en la identidad](security_iam_id-based-policy-examples.md)
## CodePipeline políticas basadas en recursos
CodePipeline no admite políticas basadas en recursos. Sin embargo, se proporciona un ejemplo de política basada en recursos para el servicio S3 relacionado con. CodePipeline
### Ejemplos
Para ver ejemplos de políticas CodePipeline basadas en recursos, consulte, [AWS CodePipeline ejemplos de políticas basadas en recursos](security_iam_resource-based-policy-examples.md)
## Autorización basada en etiquetas CodePipeline
Puede adjuntar etiquetas a CodePipeline los recursos o pasarles etiquetas en una solicitud CodePipeline. Para controlar el acceso en función de etiquetas, debe proporcionar información de las etiquetas en el [elemento de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de una política utilizando las claves de condición `codepipeline:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`. Para obtener más información acerca del etiquetado de recursos de CodePipeline , consulte [Etiquetado de recursos](tag-resources.md).
Para consultar un ejemplo de política basada en la identidad para limitar el acceso a un recurso en función de las etiquetas de ese recurso, consulte [Uso de etiquetas para controlar el acceso a los recursos CodePipeline](tag-based-access-control.md).
## CodePipeline Funciones de IAM
Un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) es una entidad de tu AWS cuenta que tiene permisos específicos.
### Usar credenciales temporales con CodePipeline
Puede utilizar credenciales temporales para iniciar sesión con federación, asumir un rol de IAM o asumir un rol de acceso entre cuentas. Las credenciales de seguridad temporales se obtienen llamando a operaciones de AWS STS API como [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)o [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
CodePipeline admite el uso de credenciales temporales.
### Roles de servicio
CodePipeline permite que un servicio asuma una [función de servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role) en su nombre. Este rol permite que el servicio obtenga acceso a los recursos de otros servicios para completar una acción en su nombre. Los roles de servicio aparecen en su cuenta de IAM y son propiedad de la cuenta. Esto significa que un administrador de IAM puede cambiar los permisos de este rol. Sin embargo, hacerlo podría deteriorar la funcionalidad del servicio.
CodePipeline apoya las funciones de servicio.
# 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)
# Prácticas recomendadas sobre las políticas
Las políticas basadas en la identidad determinan si alguien puede crear CodePipeline recursos de tu cuenta, acceder a ellos o eliminarlos. Estas acciones pueden generar costos adicionales para su Cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades:
+ **Comience con las políticas AWS administradas y avance hacia los permisos con privilegios mínimos: para empezar a conceder permisos** a sus usuarios y cargas de trabajo, utilice las *políticas AWS administradas* que otorgan permisos para muchos casos de uso comunes. Están disponibles en su. Cuenta de AWS Le recomendamos que reduzca aún más los permisos definiendo políticas administradas por el AWS cliente que sean específicas para sus casos de uso. Con el fin de obtener más información, consulte las [políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o las [políticas administradas por AWS para funciones de tarea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) en la *Guía de usuario de IAM*.
+ **Aplique permisos de privilegio mínimo**: cuando establezca permisos con políticas de IAM, conceda solo los permisos necesarios para realizar una tarea. Para ello, debe definir las acciones que se pueden llevar a cabo en determinados recursos en condiciones específicas, también conocidos como *permisos de privilegios mínimos*. Con el fin de obtener más información sobre el uso de IAM para aplicar permisos, consulte [Políticas y permisos en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*.
+ **Utilice condiciones en las políticas de IAM para restringir aún más el acceso**: puede agregar una condición a sus políticas para limitar el acceso a las acciones y los recursos. Por ejemplo, puede escribir una condición de políticas para especificar que todas las solicitudes deben enviarse utilizando SSL. También puedes usar condiciones para conceder el acceso a las acciones del servicio si se utilizan a través de una acción específica Servicio de AWS, por ejemplo CloudFormation. Para obtener más información, consulte [Elementos de la política de JSON de IAM: Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*.
+ **Utiliza el analizador de acceso de IAM para validar las políticas de IAM con el fin de garantizar la seguridad y funcionalidad de los permisos**: el analizador de acceso de IAM valida políticas nuevas y existentes para que respeten el lenguaje (JSON) de las políticas de IAM y las prácticas recomendadas de IAM. El analizador de acceso de IAM proporciona más de 100 verificaciones de políticas y recomendaciones procesables para ayudar a crear políticas seguras y funcionales. Para más información, consulte [Validación de políticas con el Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) en la *Guía del usuario de IAM*.
+ **Requerir autenticación multifactor (MFA**): si tiene un escenario que requiere usuarios de IAM o un usuario raíz en Cuenta de AWS su cuenta, active la MFA para mayor seguridad. Para exigir la MFA cuando se invoquen las operaciones de la API, añada condiciones de MFA a sus políticas. Para más información, consulte [Acceso seguro a la API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) en la *Guía del usuario de IAM*.
Para obtener más información sobre las prácticas recomendadas de IAM, consulte [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*.
# Visualización de recursos en la consola
La consola requiere el `ListRepositories` permiso para mostrar una lista de los repositorios de tu AWS cuenta en la AWS región en la que has iniciado sesión. La consola también incluye una función **Go to resource (Ir al recurso)** para realizar una búsqueda rápida de recursos sin distinción entre mayúsculas y minúsculas. Esta búsqueda se realiza en tu AWS cuenta de la AWS región en la que has iniciado sesión. Los siguientes recursos se muestran en los siguientes servicios:
+ AWS CodeBuild: proyectos de compilación
+ AWS CodeCommit: repositorios
+ AWS CodeDeploy: aplicaciones
+ AWS CodePipeline: canalizaciones
Para realizar esta búsqueda en los recursos de todos los servicios, debe contar con los siguientes permisos:
+ AWS CodeBuild: `ListProjects`
+ CodeCommit: `ListRepositories`
+ CodeDeploy: `ListApplications`
+ CodePipeline: `ListPipelines`
Los resultados de los recursos de un servicio no se devuelven si no tiene permisos para ese servicio. Aunque tenga permisos para ver los recursos, algunos recursos no se devolverán si hay un permiso `Deny` explícito para ver esos recursos.
# Cómo permitir a los usuarios consultar sus propios permisos
En este ejemplo, se muestra cómo podría crear una política que permita a los usuarios de IAM ver las políticas administradas e insertadas que se asocian a la identidad de sus usuarios. Esta política incluye permisos para completar esta acción en la consola o mediante programación mediante la API AWS CLI o AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Ejemplos de políticas basadas en identidad (IAM)
Puede asociar políticas a identidades de IAM. Por ejemplo, puede hacer lo siguiente:
+ **Adjunta una política de permisos a un usuario o grupo de tu cuenta**: para conceder a un usuario permisos para ver las canalizaciones en la consola, puedes adjuntar una política de permisos a un usuario o grupo al que pertenezca el usuario.
+ **Adjuntar una política de permisos a un rol (conceder permisos para cuentas cruzadas)**: puede adjuntar una política de permisos basada en identidades a un rol de IAM para conceder permisos para cuentas cruzadas. Por ejemplo, el administrador de la cuenta A puede crear un rol para conceder permisos multicuenta a otra cuenta (por ejemplo, la AWS cuenta B) o a una de las Servicio de AWS siguientes maneras:
1. El administrador de la CuentaA crea un rol de IAM y asocia una política de permisos a dicho rol, que concede permisos sobre los recursos de la CuentaA.
1. El administrador de la CuentaA asocia una política de confianza al rol que identifica la Cuenta B como la entidad principal que puede asumir el rol.
1. De este modo, el administrador de la cuenta B puede delegar los permisos para que asuman el rol en cualquier usuario de la cuenta B. De este modo, los usuarios de la cuenta B pueden crear recursos de la cuenta A. El director de la política de confianza también puede ser el Servicio de AWS principal si desea conceder Servicio de AWS permisos para asumir el rol.
Para obtener más información sobre el uso de IAM para delegar permisos, consulte [Administración de accesos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) en la *Guía del usuario de IAM*.
A continuación, se muestra un ejemplo de una política de permisos que permite a un usuario habilitar y deshabilitar todas las transiciones entre las etapas de la canalización llamada `MyFirstPipeline` en la `us-west-2 region`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"codepipeline:EnableStageTransition",
"codepipeline:DisableStageTransition"
],
"Resource" : [
"arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*"
]
}
]
}
```
------
En el siguiente ejemplo, se muestra una política en la cuenta 111222333444 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": [
{
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:GetPipelineExecution",
"codepipeline:ListPipelineExecutions",
"codepipeline:ListActionExecutions",
"codepipeline:ListActionTypes",
"codepipeline:ListPipelines",
"codepipeline:ListTagsForResource",
"iam:ListRoles",
"s3:ListAllMyBuckets",
"codecommit:ListRepositories",
"codedeploy:ListApplications",
"lambda:ListFunctions",
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListEventTypes",
"codestar-notifications:ListTargets"
],
"Effect": "Allow",
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"
},
{
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:GetPipelineExecution",
"codepipeline:ListPipelineExecutions",
"codepipeline:ListActionExecutions",
"codepipeline:ListActionTypes",
"codepipeline:ListPipelines",
"codepipeline:ListTagsForResource",
"iam:ListRoles",
"s3:GetBucketPolicy",
"s3:GetObject",
"s3:ListBucket",
"codecommit:ListBranches",
"codedeploy:GetApplication",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListDeploymentGroups",
"elasticbeanstalk:DescribeApplications",
"elasticbeanstalk:DescribeEnvironments",
"lambda:GetFunctionConfiguration",
"opsworks:DescribeApps",
"opsworks:DescribeLayers",
"opsworks:DescribeStacks"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsReadOnlyAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:DescribeNotificationRule"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"codestar-notifications:NotificationsForResource": "arn:aws:iam::*:role/Service*"
}
}
}
]
}
```
------
Después de crear esta política, cree el rol de IAM en la cuenta 111222333444 y asocie la política a ese rol. En las relaciones de confianza del rol, debe agregar la AWS cuenta que asumirá 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 111222333444:
------
#### [ JSON ]
****
```
{
"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 111222333444:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111222333444:role/CrossAccountPipelineViewers"
}
]
}
```
------
Puede crear políticas de IAM específicas para restringir las llamadas y los recursos a los que los usuarios de su cuenta tienen acceso y, a continuación, asociar esas políticas al usuario administrativo. Para obtener más información sobre cómo crear funciones de IAM y explorar ejemplos de declaraciones de política de IAM, consulte. [Ejemplos de políticas administradas por el cliente](security_iam_id-based-policy-examples.md#customer-managed-policies)
# Uso de etiquetas para controlar el acceso a los recursos CodePipeline
Las condiciones de las declaraciones de política de IAM forman parte de la sintaxis que se utiliza para especificar los permisos a los recursos que requieren las CodePipeline acciones. El uso de etiquetas en las condiciones es una manera de controlar el acceso a los recursos y las solicitudes. Para obtener información sobre el etiquetado de CodePipeline recursos, consulte. [Etiquetado de recursos](tag-resources.md) En este tema, se explica el control de acceso basado en etiquetas.
Al diseñar políticas de IAM, es posible que se establezcan permisos detallados mediante la concesión de acceso a recursos específicos. A medida que crezca la cantidad de recursos que administra, esta tarea será más complicada. El etiquetado de recursos y el uso de etiquetas en las condiciones de instrucción de política pueden facilitar esta tarea. Puede conceder acceso de forma masiva a cualquier recurso con una determinada etiqueta. A continuación, aplique repetidamente esta etiqueta a los recursos pertinentes durante la creación o después.
Las etiquetas se pueden asociar al recurso o pasarse dentro de la solicitud a los servicios que admiten etiquetado. En CodePipeline, los recursos pueden tener etiquetas y algunas acciones pueden incluirlas. Al crear una política de IAM, puede utilizar las claves de condición de etiqueta para controlar:
+ Qué usuarios pueden realizar acciones en un recurso de canalización, basándose en las etiquetas que ya tiene.
+ Qué etiquetas se pueden pasar en la solicitud de una acción.
+ Si se pueden utilizar claves de etiqueta específicas en una solicitud.
Los operadores de condición de cadena le permiten desarrollar elementos `Condition` que restringen el acceso comparando una clave con el valor de una cadena. Puede agregar `IfExists` al final de cualquier nombre de operador de condición, salvo la condición Null. El objetivo es decir lo siguiente: “Si la clave de la política está presente en el contexto de la solicitud, se debe procesar la clave según se indica en la política. Si la clave no está presente, el elemento de condición se evalúa en verdadero". Por ejemplo, puede utilizar `StringEqualsIfExists` para restringir por condiciones las claves que podrían no estar presentes en otros tipos de recursos.
Para la sintaxis y semántica completas de claves de condición de etiquetas, consulte [Control de acceso mediante etiquetas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html). Para obtener información adicional acerca de las claves de condición, consulte los siguientes recursos. Los ejemplos CodePipeline de políticas de esta sección se ajustan a la siguiente información sobre las claves de condición y la amplían con ejemplos de matices CodePipeline , como la anidación de recursos.
+ [Operadores de condición de cadena](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String)
+ [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)
+ [Sintaxis de SCP](https://docs.aws.amazon.com/IAM/latest/UserGuide/orgs_manage_policies_scps_syntax.html)
+ [Elementos de la política de JSON de IAM: condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)
+ [aws: /tag-key RequestTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag)
+ [Claves de condición para CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys)
Los siguientes ejemplos muestran cómo especificar las condiciones de etiqueta en las políticas para los usuarios de CodePipeline .
**Example 1: Limitar acciones en función de etiquetas en la solicitud**
La política de usuarios `AWSCodePipeline_FullAccess` gestionados otorga a los usuarios permisos ilimitados para realizar cualquier CodePipeline acción en cualquier recurso.
La política siguiente limita esta capacidad y deniega los usuarios no autorizados el permiso para crear canalizaciones donde las etiquetas especificas se incluyen en la solicitud. Para ello, deniega la acción `CreatePipeline` si la solicitud especifica una etiqueta denominada `Project` con uno de los valores `ProjectA` o `ProjectB`. (La clave de condición `aws:RequestTag` se utiliza para controlar qué etiquetas se pueden pasar en una solicitud de IAM).
En el siguiente ejemplo, la intención de la política es denegar a los usuarios no autorizados el permiso para crear una canalización con los valores de etiqueta especificados. Sin embargo, la creación de una canalización requiere acceder a los recursos además de a la propia canalización (por ejemplo, a las acciones y etapas de la canalización). Como lo `'Resource'` especificado en la política es `'*'`, la política se evalúa en función de cada recurso que tenga un ARN y se crea cuando se crea la canalización. Estos recursos adicionales no tienen la clave de condición de etiqueta, por lo que la comprobación `StringEquals` da un error y no se concede al usuario la capacidad para lanzar cualquier tipo de instancia. Para solucionar este problema, utilice en su lugar el operador de condición `StringEqualsIfExists`. De esta forma, la prueba solo se realiza si la clave de condición existe.
Podría leer lo siguiente como: “Si el recurso que se está comprobando tiene una clave de condición `"RequestTag/Project"`, deberá permitirse la acción solo si el valor de clave comienza por `projectA`. Si el recurso que se está comprobando no tiene esta clave de condición, no deberá tenerse en cuenta”.
Además, la política impide que estos usuarios no autorizados manipulen los recursos utilizando la clave de condición `aws:TagKeys` para no permitir que las acciones de modificación de etiquetas incluyan estos mismos valores de etiqueta. El administrador de un cliente debe asociar esta política de IAM a los usuarios de IAM no autorizados, además de la política de usuario administrada.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:CreatePipeline",
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEqualsIfExists": {
"aws:RequestTag/Project": ["ProjectA", "ProjectB"]
}
}
},
{
"Effect": "Deny",
"Action": [
"codepipeline:UntagResource"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
**Example 2: Limitar acciones en función de etiquetas de recursos**
La política de usuarios `AWSCodePipeline_FullAccess` administrados otorga a los usuarios permisos ilimitados para realizar cualquier CodePipeline acción en cualquier recurso.
La siguiente política limita esta capacidad y deniega a los usuarios no autorizados el permiso para realizar acciones en canalizaciones específicas del proyecto. Para ello, deniega algunas acciones si el recurso tiene una etiqueta denominada `Project` con el valor `ProjectA` o `ProjectB`. (La clave de condición `aws:ResourceTag` se utiliza para controlar el acceso a los recursos en función de las etiquetas que tengan los recursos). El administrador de un cliente debe asociar esta política de IAM a los usuarios de IAM no autorizados, además de la política de usuario administrada.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": ["ProjectA", "ProjectB"]
}
}
}
]
}
```
**Example 3: Permitir acciones en función de etiquetas en la solicitud**
La política siguiente concede a los usuarios permiso para crear canalizaciones de desarrollo en CodePipeline.
Para ello, permite las acciones `CreatePipeline` y `TagResource` si la solicitud especifica una etiqueta denominada `Project` con el valor `ProjectA`. En otras palabras, la única clave de etiqueta que se puede especificar es`Project`, y su valor debe ser`ProjectA`.
(La clave de condición `aws:RequestTag` se utiliza para controlar qué etiquetas se pueden pasar en una solicitud de IAM). La condición `aws:TagKeys` garantiza la distinción entre mayúsculas y minúsculas de las claves de etiqueta. Esta política es útil para los usuarios o roles que no tienen asociada la política de usuario administrada `AWSCodePipeline_FullAccess`. La política administrada otorga a los usuarios permisos ilimitados para realizar cualquier CodePipeline acción en cualquier recurso.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:CreatePipeline",
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "ProjectA"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
**Example 4: Limitar acciones en función de etiquetas de recursos**
La política de usuarios `AWSCodePipeline_FullAccess` administrados otorga a los usuarios permisos ilimitados para realizar cualquier CodePipeline acción en cualquier recurso.
La siguiente política limita esta capacidad y deniega a los usuarios no autorizados el permiso para realizar acciones en canalizaciones específicas del proyecto. Para ello, deniega algunas acciones si el recurso tiene una etiqueta denominada `Project` con el valor `ProjectA` o `ProjectB`.
Además, la política impide que estos usuarios no autorizados manipulen los recursos al utilizar la clave de condición `aws:TagKeys` que no permite que las acciones de modificación de etiquetas incluyan estos mismos valores de etiquetas ni eliminen por completo la etiqueta `Project`. El administrador de un cliente debe asociar esta política de IAM a los usuarios de IAM no autorizados, además de la política de usuario administrada.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:UntagResource"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
# Permisos necesarios para usar la consola
Para usar en la consola de , debe tener un conjunto mínimo de permisos de los siguientes servicios:
+ AWS Identity and Access Management
+ Amazon Simple Storage Service
Estos permisos le permiten describir otros AWS recursos de su AWS cuenta.
En función del resto de los servicios que integre en sus canalizaciones, es posible que necesite permisos de uno o más de los siguientes servicios:
+ AWS CodeCommit
+ AWS CodeBuild
+ CloudFormation
+ AWS CodeDeploy
+ AWS Elastic Beanstalk
+ AWS Lambda
+ AWS OpsWorks
Si crea una política de IAM que sea más restrictiva que el mínimo de permisos necesarios, la consola no funcionará del modo esperado para los usuarios con esa política de IAM. Para asegurarse de que esos usuarios puedan seguir usando la consola, asocie también la política administrada `AWSCodePipeline_ReadOnlyAccess` al usuario, según se explica en [AWS políticas gestionadas para AWS CodePipeline](managed-policies.md).
No es necesario que concedas permisos mínimos de consola a los usuarios que realicen llamadas a la API AWS CLI o a la API.
# Permisos necesarios para ver los registros de procesamiento en la consola
Para ver los registros de la acción de comandos en la CodePipeline consola, el rol de la consola debe tener permisos. Para ver los registros en la consola, añada los permisos `logs:GetLogEvents` al rol de la consola.
En la declaración de las políticas de roles de la consola, limite los permisos al nivel de la canalización como se muestra en el siguiente ejemplo.
```
{
"Effect": "Allow",
"Action": [
"Action": "logs:GetLogEvents"
],
"Resource": "arn:aws:logs:*:YOUR_AWS_ACCOUNT_ID:log-group:/aws/codepipeline/YOUR_PIPELINE_NAME:*"
}
```
# AWS políticas gestionadas para AWS CodePipeline
Una política AWS administrada es una política independiente creada y administrada por AWS. AWS Las políticas administradas están diseñadas para proporcionar permisos para muchos casos de uso comunes, de modo que pueda empezar a asignar permisos a usuarios, grupos y funciones.
Ten en cuenta que es posible que las políticas AWS administradas no otorguen permisos con privilegios mínimos para tus casos de uso específicos, ya que están disponibles para que los usen todos los AWS clientes. Se recomienda definir [políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) específicas para sus casos de uso a fin de reducir aún más los permisos.
No puedes cambiar los permisos definidos en AWS las políticas administradas. Si AWS actualiza los permisos definidos en una política AWS administrada, la actualización afecta a todas las identidades principales (usuarios, grupos y roles) a las que está asociada la política. AWS es más probable que actualice una política AWS administrada cuando Servicio de AWS se lance una nueva o cuando estén disponibles nuevas operaciones de API para los servicios existentes.
Para obtener más información, consulte [Políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) en la *Guía del usuario de IAM*.
**importante**
Las políticas administradas de `AWSCodePipelineFullAccess` y `AWSCodePipelineReadOnlyAccess` han sustituido. Utilice las políticas `AWSCodePipeline_FullAccess` y `AWSCodePipeline_ReadOnlyAccess`.
## AWS política gestionada: `AWSCodePipeline_FullAccess`
Esta es una política que otorga acceso total a CodePipeline. Para ver el documento de política de JSON en la consola de IAM, consulte [AWSCodePipeline\$1FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_FullAccess).
**Detalles de los permisos**
Esta política incluye los siguientes permisos.
+ `codepipeline`— Otorga permisos a. CodePipeline
+ `chatbot`: concede permisos para que las entidades principales administren los recursos de Amazon Q Developer en las aplicaciones de chat.
+ `cloudformation`— Otorga permisos para permitir a los directores administrar las pilas de recursos. CloudFormation
+ `cloudtrail`— Otorga permisos que permiten a los directores gestionar el inicio de sesión de los recursos. CloudTrail
+ `codebuild`— Otorga permisos para permitir a los directores acceder a los recursos del edificio. CodeBuild
+ `codecommit`— Otorga permisos para permitir a los directores acceder a los recursos fuente en. CodeCommit
+ `codedeploy`— Otorga permisos para permitir a los directores acceder a los recursos de implementación en. CodeDeploy
+ `codestar-notifications`— Otorga permisos para permitir a los directores acceder a los recursos de las AWS CodeStar notificaciones.
+ `ec2`— Otorga permisos para permitir que las implementaciones CodeCatalyst administren el balanceo de carga elástico en Amazon EC2.
+ `ecr`: otorga permisos para permitir el acceso a los recursos de Amazon ECR.
+ `elasticbeanstalk`: otorga permisos para permitir a las entidades principales acceder a los recursos de Elastic Beanstalk.
+ `iam`: otorga permisos que permiten a las entidades principales administrar las funciones y las políticas en IAM.
+ `lambda`: otorga permisos para permitir a las entidades principales administrar los recursos en Lambda.
+ `events`— Otorga permisos que permiten a los directores administrar los recursos en Events. CloudWatch
+ `opsworks`— Otorga permisos que permiten a los directores gestionar los recursos en ellos. AWS OpsWorks
+ `s3`: otorga permisos para permitir a las entidades principales administrar los recursos en Amazon S3.
+ `sns`: otorga permisos para que los directores administren los recursos de notificaciones en Amazon SNS.
+ `states`— Otorga permisos que permiten a los directores ver las máquinas estatales en ellas. AWS Step Functions Una máquina de estados consiste en un conjunto de estados que administran las tareas y la transición entre estados.
Para ver la política, consulte [AWSCodePipeline\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_FullAccess.html).
## AWS política gestionada: `AWSCodePipeline_ReadOnlyAccess`
Se trata de una política que concede acceso de solo lectura a. CodePipeline Para ver el documento de política de JSON en la consola de IAM, consulte. [AWSCodePipeline\$1ReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_ReadOnlyAccess)
**Detalles de los permisos**
Esta política incluye los siguientes permisos.
+ `codepipeline`— Otorga permisos a las acciones en CodePipeline.
+ `codestar-notifications`— Otorga permisos para permitir a los directores acceder a los recursos de las AWS CodeStar notificaciones.
+ `s3`: otorga permisos para permitir a las entidades principales administrar los recursos en Amazon S3.
+ `sns`: otorga permisos para que los directores administren los recursos de notificaciones en Amazon SNS.
Para ver la política, consulte [AWSCodePipeline\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_ReadOnlyAccess.html).
## AWS política gestionada: `AWSCodePipelineApproverAccess`
Se trata de una política que otorga permiso para aprobar o rechazar una acción de aprobación manual. Para ver el documento de política de JSON en la consola de IAM, consulte [AWSCodePipelineApproverAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineApproverAccess).
**Detalles de los permisos**
Esta política incluye los siguientes permisos.
+ `codepipeline`— Otorga permisos a las acciones en CodePipeline.
Para ver la política, consulte [AWSCodePipelineApproverAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineApproverAccess.html).
## AWS política gestionada: `AWSCodePipelineCustomActionAccess`
Se trata de una política que permite crear acciones personalizadas en los recursos de Jenkins CodePipeline o integrarlos para crear o probar acciones. Para ver el documento de política de JSON en la consola de IAM, consulte. [AWSCodePipelineCustomActionAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineCustomActionAccess)
**Detalles de los permisos**
Esta política incluye los siguientes permisos.
+ `codepipeline`— Otorga permisos a las acciones en CodePipeline.
Para ver la política, consulte [AWSCodePipelineCustomActionAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineCustomActionAccess.html).
## CodePipeline políticas y notificaciones gestionadas
CodePipeline admite las notificaciones, que pueden notificar a los usuarios los cambios importantes en las canalizaciones. Las políticas gestionadas CodePipeline incluyen declaraciones de políticas para la funcionalidad de notificación. Para obtener más información, consulte [¿Qué son las notificaciones?](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/welcome.html)
### Permisos relacionados con las notificaciones en políticas administradas de acceso total
Esta política gestionada concede permisos CodeCommit CodeBuild, CodePipeline CodeDeploy además de los servicios y AWS CodeStar notificaciones relacionados. La política también otorga los permisos que necesita para trabajar con otros servicios que se integran con sus canalizaciones, como Amazon S3, Elastic CloudTrail Beanstalk, Amazon EC2 y. CloudFormation Los usuarios que tienen aplicada esta política administrada también pueden crear y administrar temas de Amazon SNS para notificaciones, suscribir usuarios a temas y cancelar dicha suscripción, mostrar los temas que se pueden elegir como destinos para las reglas de notificación y mostrar Amazon Q Developer en los clientes de aplicaciones de chat configurados para Slack.
La política administrada `AWSCodePipeline_FullAccess` incluye las siguientes instrucciones para permitir el acceso completo a las notificaciones.
```
{
"Sid": "CodeStarNotificationsReadWriteAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:CreateNotificationRule",
"codestar-notifications:DescribeNotificationRule",
"codestar-notifications:UpdateNotificationRule",
"codestar-notifications:DeleteNotificationRule",
"codestar-notifications:Subscribe",
"codestar-notifications:Unsubscribe"
],
"Resource": "*",
"Condition" : {
"StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"}
}
},
{
"Sid": "CodeStarNotificationsListAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListTargets",
"codestar-notifications:ListTagsforResource",
"codestar-notifications:ListEventTypes"
],
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsSNSTopicCreateAccess",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:SetTopicAttributes"
],
"Resource": "arn:aws:sns:*:*:codestar-notifications*"
},
{
"Sid": "SNSTopicListAccess",
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsChatbotAccess",
"Effect": "Allow",
"Action": [
"chatbot:DescribeSlackChannelConfigurations",
"chatbot:ListMicrosoftTeamsChannelConfigurations"
],
"Resource": "*"
}
```
### Permisos relacionados con las notificaciones en políticas administradas de solo lectura
La política administrada `AWSCodePipeline_ReadOnlyAccess` incluye las siguientes instrucciones para permitir el acceso de solo lectura a las notificaciones. Los usuarios que apliquen esta política pueden consultar notificaciones de recursos, pero no pueden crearlas, administrarlas ni suscribirse a ellas.
```
{
"Sid": "CodeStarNotificationsPowerUserAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:DescribeNotificationRule"
],
"Resource": "*",
"Condition" : {
"StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"}
}
},
{
"Sid": "CodeStarNotificationsListAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListEventTypes",
"codestar-notifications:ListTargets"
],
"Resource": "*"
}
```
Para obtener más información acerca de IAM y las notificaciones consulte [Identity and Access Management para AWS CodeStar Notifications](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security-iam.html).
## AWS CodePipeline actualizaciones de las políticas AWS administradas
Consulte los detalles sobre las actualizaciones de las políticas AWS administradas CodePipeline desde que este servicio comenzó a rastrear estos cambios. Para obtener alertas automáticas sobre los cambios realizados en esta página, suscríbase a la fuente RSS en la CodePipeline Página del historial de revisión de [https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html](https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html).
| Cambio | Descripción | Fecha |
| --- | --- | --- |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)— Actualizaciones de la política existente | CodePipeline agregó un permiso a esta política para ListStacks respaldarla CloudFormation. | 15 de marzo de 2024 |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)— Actualizaciones de la política existente | Esta política se ha actualizado para agregar permisos para Amazon Q Developer en aplicaciones de chat. Para obtener más información, consulte [CodePipeline políticas y notificaciones gestionadas](#notifications-permissions). | 21 de junio de 2023 |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)y políticas [AWSCodePipeline\$1ReadOnlyAccess](#security-iam-awsmanpol-AWSCodePipeline_ReadOnlyAccess)gestionadas: actualizaciones de la política existente | CodePipeline agregó un permiso a estas políticas para admitir un tipo de notificación adicional utilizando Amazon Q Developer en aplicaciones de chat,`chatbot:ListMicrosoftTeamsChannelConfigurations`. | 16 de mayo de 2023 |
| **AWSCodePipelineFullAccess**: obsoleta | Esta política ha sido reemplazada por `AWSCodePipeline_FullAccess`. Después del 17 de noviembre de 2022, esta política no se podrá adjuntar a ningún usuario, grupo o función nuevos. Para obtener más información, consulte [AWS políticas gestionadas para AWS CodePipeline](#managed-policies). | 17 de noviembre de 2022 |
| **AWSCodePipelineReadOnlyAccess**: obsoleta | Esta política ha sido reemplazada por `AWSCodePipeline_ReadOnlyAccess`. Después del 17 de noviembre de 2022, esta política no se podrá adjuntar a ningún usuario, grupo o función nuevos. Para obtener más información, consulte [AWS políticas gestionadas para AWS CodePipeline](#managed-policies). | 17 de noviembre de 2022 |
| CodePipeline comenzó a rastrear los cambios | CodePipeline comenzó a realizar un seguimiento de los cambios de sus políticas AWS gestionadas. | 12 de marzo de 2021 |
## 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"
}
]
}
```
------
# AWS CodePipeline ejemplos de políticas basadas en recursos
**Topics**
Otros servicios, como Amazon S3, también admiten políticas de permisos basadas en recursos. Por ejemplo, puede asociar una política a un bucket de S3 para administrar los permisos de acceso a dicho bucket. Aunque CodePipeline no admite políticas basadas en recursos, sí almacena artefactos para su uso en canalizaciones en buckets S3 versionados.
**Example Crear una política para que un bucket de S3 se utilice como almacén de artefactos CodePipeline**
Puedes usar cualquier bucket de S3 versionado como almacén de artefactos. CodePipeline Si crea su primera canalización con el asistente para **crear canalizaciones**, este bucket de S3 se crea de forma automática para garantizar que todos los objetos subidos al almacén de artefactos estén cifrados y las conexiones con el bucket sean seguras. Se recomienda que, si usted crea su propio bucket de S3, añada la siguiente política o sus elementos al bucket. En esta política, el ARN del bucket de S3 es `codepipeline-us-east-2-1234567890`. Sustituya este ARN por el de su bucket de S3:
****
```
{
"Version":"2012-10-17",
"Id": "SSEAndSSLPolicy",
"Statement": [
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyInsecureConnections",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"Bool": {
"aws:SecureTransport": false
}
}
}
]
}
```
# Solución de problemas de AWS CodePipeline identidad y acceso
Utilice la siguiente información como ayuda para diagnosticar y solucionar los problemas habituales que pueden surgir al trabajar con un CodePipeline IAM.
**Topics**
+ [No estoy autorizado a realizar ninguna acción en CodePipeline](#security_iam_troubleshoot-no-permissions)
+ [No estoy autorizado a realizar lo siguiente: PassRole](#security_iam_troubleshoot-passrole)
+ [Soy administrador y quiero permitir que otras personas accedan CodePipeline](#security_iam_troubleshoot-admin-delegate)
+ [Quiero permitir que personas ajenas a mi AWS cuenta accedan a mis CodePipeline recursos](#security_iam_troubleshoot-cross-account-access)
## No estoy autorizado a realizar ninguna acción en CodePipeline
Si Consola de administración de AWS le indica que no está autorizado a realizar una acción, debe ponerse en contacto con su administrador para obtener ayuda. Su administrador es la persona que le facilitó su nombre de usuario y contraseña.
En el siguiente ejemplo, el error se produce cuando el usuario de IAM de `mateojackson` intenta utilizar la consola para ver detalles sobre una canalización, pero no tiene permisos `codepipeline:GetPipeline`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: codepipeline:GetPipeline on resource: my-pipeline
```
En este caso, Mateo pide a su administrador que actualice sus políticas de forma que pueda obtener acceso al recurso `my-pipeline` mediante la acción `codepipeline:GetPipeline`.
## No estoy autorizado a realizar lo siguiente: PassRole
Si recibe un error que indica que no está autorizado para llevar a cabo la acción `iam:PassRole`, debe ponerse en contacto con su administrador para recibir ayuda. Su administrador es la persona que le facilitó su nombre de usuario y contraseña. Pida a la persona que actualice sus políticas de forma que pueda transferir un rol a CodePipeline.
Algunas Servicios de AWS permiten transferir una función existente a ese servicio, en lugar de crear una nueva función de servicio o una función vinculada a un servicio. Para ello, debe tener permisos para transferir la función al servicio.
En el siguiente ejemplo, el error se produce cuando un usuario de IAM denominado `marymajor` intenta utilizar la consola para realizar una acción en CodePipeline. Sin embargo, la acción requiere que el servicio tenga permisos otorgados por un rol de servicio. Mary no tiene permisos para transferir el rol al servicio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
En este caso, Mary pide a su administrador que actualice sus políticas para que pueda realizar la acción `iam:PassRole`.
## Soy administrador y quiero permitir que otras personas accedan CodePipeline
Para permitir el acceso de otras personas CodePipeline, debes conceder permiso a las personas o aplicaciones que necesitan acceso. Si usa AWS IAM Identity Center para administrar las personas y las aplicaciones, debe asignar conjuntos de permisos a los usuarios o grupos para definir su nivel de acceso. Los conjuntos de permisos crean políticas de IAM y las asignan a los roles de IAM asociados a la persona o aplicación de forma automática. Para obtener más información, consulte la sección [Conjuntos de permisos](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) en la *Guía del usuario de AWS IAM Identity Center *.
Si no utiliza IAM Identity Center, debe crear entidades de IAM (usuarios o roles) para las personas o aplicaciones que necesitan acceso. A continuación, debe asociar una política a la entidad que le conceda los permisos correctos en CodePipeline. Una vez concedidos los permisos, proporcione las credenciales al usuario o al desarrollador de la aplicación. Utilizarán esas credenciales para acceder a AWS. Para obtener más información sobre la creación de usuarios, grupos, políticas y permisos de IAM, consulte [Identidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) y [Políticas y permisos en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*.
## Quiero permitir que personas ajenas a mi AWS cuenta accedan a mis CodePipeline recursos
Se puede crear un rol que los usuarios de otras cuentas o las personas externas a la organización puedan utilizar para acceder a sus recursos. Se puede especificar una persona de confianza para que asuma el rol. En el caso de los servicios que admiten políticas basadas en recursos o listas de control de acceso (ACLs), puedes usar esas políticas para permitir que las personas accedan a tus recursos.
Para obtener más información, consulte lo siguiente:
+ Para saber si CodePipeline es compatible con estas funciones, consulte. [¿Cómo AWS CodePipeline funciona con IAM](security_iam_service-with-iam.md)
+ Para obtener información sobre cómo proporcionar acceso a los recursos de su Cuentas de AWS propiedad, consulte [Proporcionar acceso a un usuario de IAM en otro usuario de su propiedad Cuenta de AWS en](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) la Guía del *usuario de IAM*.
+ Para obtener información sobre cómo proporcionar acceso a tus recursos a terceros Cuentas de AWS, consulta Cómo [proporcionar acceso a recursos que Cuentas de AWS son propiedad de terceros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) en la Guía del usuario de *IAM*.
+ Para obtener información sobre cómo proporcionar acceso mediante una federación de identidades, consulte [Proporcionar acceso a usuarios autenticados externamente (identidad federada)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) en la *Guía del usuario de IAM*.
+ Para conocer sobre la diferencia entre las políticas basadas en roles y en recursos para el acceso entre cuentas, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
# referencia de permisos
Utilice la siguiente tabla como referencia cuando configure políticas de control de acceso y de escritura que pueda asociar a una identidad de IAM (políticas basadas en identidad). En la tabla figuran las operaciones de las API de y las acciones correspondientes para las que puede conceder permisos para realizar la acción. En el caso de las operaciones que admiten *permisos a nivel de recurso*, en la tabla se indica el AWS recurso para el que puede conceder los permisos. Las acciones se especifican en el campo `Action` de la política.
Los *permisos a nivel de recursos* son aquellos que permiten especificar en qué recursos los usuarios pueden realizar acciones. AWS CodePipeline proporciona compatibilidad parcial con los permisos a nivel de recursos. Esto significa que, para algunas llamadas a la AWS CodePipeline API, puedes controlar cuándo se permite a los usuarios usar esas acciones en función de las condiciones que deben cumplirse o qué recursos pueden usar los usuarios. Por ejemplo, puede conceder a los usuarios permiso para generar un listado con información de ejecución de canalizaciones, pero solo para una o varias canalizaciones específicas.
**nota**
En la columna **Recursos**, se muestra el recurso necesario para las llamadas a las API que admiten los permisos de nivel de recurso. En el caso de las llamadas a las API que no admiten los permisos de nivel de recurso, puede conceder permisos a los usuarios para que las utilicen, pero tendrá que usar un carácter comodín (\$1) en el elemento Resource de la instrucción de la política.
**Operaciones de la API y permisos necesarios para las acciones**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/codepipeline/latest/userguide/permissions-reference.html)
# Administre la función CodePipeline de servicio
La función de servicio se configura con una o más políticas que controlan el acceso a los AWS recursos utilizados por la canalización. Puede que desee adjuntar más políticas a esta función, editar la política asociada a la función o configurar políticas para otras funciones de servicio en AWS. También puede asociar una política a un rol al configurar el acceso entre cuentas en su canalización.
**importante**
Si se modifica la instrucción de una política o se asocia otra política al rol, es posible que las canalizaciones dejen de funcionar. Asegúrese de conocer bien las consecuencias antes de modificar el rol de servicio de . Asegúrese de probar las canalizaciones después de implementar cualquier cambio en el rol de servicio.
**nota**
En la consola, los roles de servicio creados antes de septiembre de 2018 se crean con el nombre `oneClick_AWS-CodePipeline-Service_ID-Number`.
Los roles de servicio creados después de septiembre de 2018 usan el formato de nombre de rol de servicio `AWSCodePipelineServiceRole-Region-Pipeline_Name`. Por ejemplo, en el caso de una canalización denominada `MyFirstPipeline` en `eu-west-2`, la consola asigna un nombre al rol y a la política `AWSCodePipelineServiceRole-eu-west-2-MyFirstPipeline`.
## CodePipeline política de rol de servicio
La declaración de política de la función de CodePipeline servicio contiene los permisos mínimos para gestionar las canalizaciones. Puede editar la declaración del rol de servicio para quitar el acceso a los recursos que no use. Consulte la referencia de acción correspondiente para conocer los permisos mínimos requeridos CodePipeline para cada acción.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3BucketAccess",
"Effect": "Allow",
"Action": [
"s3:GetBucketVersioning",
"s3:GetBucketAcl",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::[[pipeArtifactBucketNames]]"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "{{accountId}}"
}
}
},
{
"Sid": "AllowS3ObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:GetObjectVersion",
"s3:PutObjectTagging",
"s3:GetObjectTagging",
"s3:GetObjectVersionTagging"
],
"Resource": [
"arn:aws:s3:::[[pipeArtifactBucketNames]]/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "{{accountId}}"
}
}
}
]
}
```
------
**nota**
En la política, se requieren los siguientes permisos cuando los objetos de S3 del bucket de origen contienen etiquetas:
```
s3:PutObjectTagging
s3:GetObjectTagging
s3:GetObjectVersionTagging
```
## Elimine los permisos del rol CodePipeline de servicio
Puede editar la instrucción del rol de servicio para quitar el acceso a los recursos que no use. Por ejemplo, si ninguna de sus canalizaciones incluye Elastic Beanstalk, puede editar la instrucción de política para quitar la sección que concede acceso a los recursos de Elastic Beanstalk.
Del mismo modo, si ninguna de tus canalizaciones lo incluye CodeDeploy, puedes editar la declaración de política para eliminar la sección que concede acceso a CodeDeploy los recursos:
```
{
"Action": [
"codedeploy:CreateDeployment",
"codedeploy:GetApplicationRevision",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentConfig",
"codedeploy:RegisterApplicationRevision"
],
"Resource": "*",
"Effect": "Allow"
},
```
## Agrega permisos al rol de CodePipeline servicio
Debe actualizar su instrucción de política del rol de servicio con los permisos de Servicio de AWS que no se hayan incluido en la instrucción de política predeterminada del rol de servicio para poder usarlos en las canalizaciones.
Esto es especialmente importante si la función de servicio que utilizas para tus canalizaciones se creó antes de añadir el soporte a una Servicio de AWS.
En la siguiente tabla se muestra cuándo se añadió la compatibilidad con otros Servicios de AWS.
****
| Servicio de AWS | CodePipeline fecha de soporte |
| --- | --- |
| CodePipeline se agregó el soporte para invocar acciones. Consulte [Política de rol de servicio: permisos para la acción de CodePipeline invocación](action-reference-PipelineInvoke.md#action-reference-PipelineInvoke-permissions-action). | 14 de marzo de 2025 |
| Se ha agregado compatibilidad con la acción de EC2. Consulte [Permisos de la política de rol de servicio para la acción de implementación de EC2](action-reference-EC2Deploy.md#action-reference-EC2Deploy-permissions-action). | 21 de febrero de 2025 |
| Se ha agregado compatibilidad con la acción de EKS. Consulte [Permisos para las políticas de roles de servicio](action-reference-EKS.md#action-reference-EKS-service-role). | 20 de febrero de 2025 |
| Se ha agregado compatibilidad con la acción ECRBuildAndPublish de Amazon Elastic Container Registry. Consulte [Permisos del rol de servicio: acción `ECRBuildAndPublish`](action-reference-ECRBuildAndPublish.md#edit-role-ECRBuildAndPublish). | 22 de noviembre de 2024 |
| Se ha agregado compatibilidad con la acción InspectorScan de Amazon Inspector. Consulte [Permisos del rol de servicio: acción `InspectorScan`](action-reference-InspectorScan.md#edit-role-InspectorScan). | 22 de noviembre de 2024 |
| Se ha agregado compatibilidad con la acción de comandos. Consulte [Permisos del rol de servicio: acción de Comandos](action-reference-Commands.md#edit-role-Commands). | 3 de octubre de 2024 |
| CloudFormation se agregó soporte para acciones. Consulte [Permisos del rol de servicio: acción de `CloudFormationStackSet`](action-reference-StackSets.md#edit-role-cfn-stackset) y [Permisos del rol de servicio: acción `CloudFormationStackInstances`](action-reference-StackSets.md#edit-role-cfn-stackinstances). | 30 de diciembre de 2020 |
| CodeCommit Se agregó la compatibilidad con acciones en formato de artefacto de salida de clones completos. Consulte [Permisos de rol de servicio: CodeCommit acción](action-reference-CodeCommit.md#edit-role-codecommit). | 11 de noviembre de 2020 |
| AWS CodeBuild Se agregó el soporte para acciones de construcción por lotes. Consulte [Permisos de rol de servicio: CodeCommit acción](action-reference-CodeCommit.md#edit-role-codecommit). | 30 de julio de 2020 |
| AWS AppConfig se agregó soporte para acciones. Consulte [Permisos del rol de servicio: acción de `AppConfig`](action-reference-AppConfig.md#edit-role-appconfig). | 22 de junio de 2020 |
| AWS Step Functions soporte de acción agregado. Consulte [Permisos del rol de servicio: acción `StepFunctions`](action-reference-StepFunctions.md#edit-role-stepfunctions). | 27 de mayo de 2020 |
| AWS CodeStar Se agregó el soporte para acciones de conexiones. Consulte [Permisos de rol de servicio: CodeConnections acción](action-reference-CodestarConnectionSource.md#edit-role-connections). | 18 de diciembre de 2019 |
| Se ha agregado compatibilidad con la acción de implementación de S3. Consulte [Permisos del rol de servicio: acción de implementación de S3](action-reference-S3Deploy.md#edit-role-s3deploy). | 16 de enero de 2019 |
| Se ha agregado compatibilidad con la acción CodeDeployToECS. Consulte [Permisos del rol de servicio: acción de `CodeDeployToECS`](action-reference-ECSbluegreen.md#edit-role-codedeploy-ecs). | 27 de noviembre de 2018 |
| Se ha agregado compatibilidad con la acción de Amazon ECR. Consulte [Permisos del rol de servicio: acción de Amazon ECR](action-reference-ECR.md#edit-role-ecr). | 27 de noviembre de 2018 |
| Se ha agregado compatibilidad con la acción de Service Catalog. Consulte [Permisos del rol de servicio: acción de Service Catalog](action-reference-ServiceCatalog.md#edit-role-servicecatalog). | 16 de octubre de 2018 |
| AWS Device Farm Se ha añadido un soporte de acción. Consulte [Permisos de rol de servicio: AWS Device Farm acción](action-reference-DeviceFarm.md#edit-role-devicefarm). | 19 de julio de 2018 |
| Se ha agregado compatibilidad con la acción de Amazon ECS. Consulte [Permisos del rol de servicio: acción estándar de Amazon ECS](action-reference-ECS.md#edit-role-ecs). | 12 de diciembre de 2017 /Actualización para optar por la autorización de etiquetado el 21 de julio de 2017 |
| CodeCommit soporte de acción agregado. Consulte [Permisos de rol de servicio: CodeCommit acción](action-reference-CodeCommit.md#edit-role-codecommit). | 18 de abril de 2016 |
| AWS OpsWorks soporte de acción agregado. Consulte [Permisos de rol de servicio: AWS OpsWorks acción](action-reference-OpsWorks.md#edit-role-opsworks). | 2 de junio de 2016 |
| CloudFormation soporte de acción agregado. Consulte [Permisos de rol de servicio: CloudFormation acción](action-reference-CloudFormation.md#edit-role-cloudformation). | 3 de noviembre de 2016 |
| AWS CodeBuild soporte de acción agregado. Consulte [Permisos de rol de servicio: CodeBuild acción](action-reference-CodeBuild.md#edit-role-codebuild). | 1 de diciembre de 2016 |
| Se ha agregado compatibilidad con la acción de Elastic Beanstalk. Consulte [Permisos del rol de servicio: acción de implementación `ElasticBeanstalk`](action-reference-Beanstalk.md#edit-role-beanstalk). | Lanzamiento del servicio inicial |
| CodeDeploy soporte de acción agregado. Consulte [Permisos de rol de servicio: AWS CodeDeploy acción](action-reference-CodeDeploy.md#edit-role-codedeploy). | Lanzamiento del servicio inicial |
| Se ha agregado compatibilidad con la acción de origen de S3. Consulte [Permisos del rol de servicio: acción de origen de S3](action-reference-S3.md#edit-role-s3source). | Lanzamiento del servicio inicial |
Siga estos pasos para añadir permisos a un servicio compatible:
1. Inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En la consola de IAM, en el panel de navegación, elija **Roles** y seleccione su rol `AWS-CodePipeline-Service` en la lista de roles.
1. En la pestaña **Permisos**, en **Políticas en línea**, en la fila de su política de rol de servicio, elija **Editar política**.
1. Añada los permisos necesarios en el cuadro **Documento de política**.
**nota**
Al crear políticas de IAM, siga los consejos de seguridad estándar de concesión de privilegios mínimos, es decir, conceder solo los permisos necesarios para realizar una tarea. Algunas llamadas a la API admiten los permisos basados en recursos y permiten limitar el acceso. Por ejemplo, en este caso, para limitar los permisos cuando se llama a `DescribeTasks` y `ListTasks`, puede sustituir el carácter comodín (\$1) por un ARN de recurso o por un ARN de recurso que contenga un carácter comodín (\$1). Para obtener más información acerca de la creación de un política que concede acceso con privilegios mínimos, consulte [https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).
1. Elija **Revisar política** para asegurarse de que la política no contiene errores. Cuando la política no tenga errores, elija **Aplicar política**.
# Inicio de sesión y supervisión CodePipeline
Puede utilizar las funciones de inicio de sesión AWS para determinar las acciones que los usuarios han realizado en su cuenta y los recursos que se han utilizado. Los archivos de registro muestran:
+ La fecha y la hora de las acciones.
+ La dirección IP de origen de una acción.
+ Las acciones que han fallado debido a permisos inadecuados.
Las características de registro están disponibles en los siguientes Servicios de AWS:
+ AWS CloudTrail se puede usar para registrar las llamadas a la AWS API y los eventos relacionados realizados por o en nombre de un Cuenta de AWS. Para obtener más información, consulte [Registrar llamadas a la CodePipeline API con AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ Amazon CloudWatch Events se puede utilizar para supervisar Nube de AWS los recursos y las aplicaciones en las que se ejecuta AWS. Puede crear alertas en Amazon CloudWatch Events en función de las métricas que defina. Para obtener más información, consulte [Monitorización de CodePipeline eventos](detect-state-changes-cloudwatch-events.md).
# Validación de conformidad para AWS CodePipeline
Para saber si uno Servicio de AWS está dentro del ámbito de aplicación de programas de cumplimiento específicos, consulte [Servicios de AWS Alcance por programa de cumplimiento Servicios de AWS](https://aws.amazon.com/compliance/services-in-scope/) de cumplimiento y elija el programa de cumplimiento que le interese. Para obtener información general, consulte Programas de [AWS cumplimiento > Programas AWS](https://aws.amazon.com/compliance/programs/) .
Puede descargar informes de auditoría de terceros mediante Artifact. Para obtener más información, consulte [Descarga de informes en AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Su responsabilidad de cumplimiento al Servicios de AWS utilizarlos viene determinada por la confidencialidad de sus datos, los objetivos de cumplimiento de su empresa y las leyes y reglamentos aplicables. Para obtener más información sobre su responsabilidad de conformidad al utilizarlos Servicios de AWS, consulte [AWS la documentación de seguridad](https://docs.aws.amazon.com/security/).
# Resiliencia en AWS CodePipeline
La infraestructura AWS global se basa en AWS regiones y zonas de disponibilidad. AWS Las regiones proporcionan varias zonas de disponibilidad aisladas y separadas físicamente, que están conectadas mediante redes de baja latencia, alto rendimiento y alta redundancia. Con las zonas de disponibilidad, puede diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre las zonas sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de uno o varios centros de datos.
[Para obtener más información sobre AWS las regiones y las zonas de disponibilidad, consulte Infraestructura global.AWS](https://aws.amazon.com/about-aws/global-infrastructure/)
# Seguridad de la infraestructura en AWS CodePipeline
Como servicio gestionado, AWS CodePipeline está protegido por la seguridad de la red AWS global. Para obtener información sobre los servicios AWS de seguridad y cómo se AWS protege la infraestructura, consulte [Seguridad AWS en la nube](https://aws.amazon.com/security/). Para diseñar su AWS entorno utilizando las mejores prácticas de seguridad de la infraestructura, consulte [Protección de infraestructuras en un marco](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) de buena * AWS arquitectura basado en el pilar de la seguridad*.
Utiliza las llamadas a la API AWS publicadas para acceder a CodePipeline través de la red. Los clientes deben admitir lo siguiente:
+ Seguridad de la capa de transporte (TLS). Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Conjuntos de cifrado con confidencialidad directa total (PFS) como DHE (Ephemeral Diffie-Hellman) o ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
# Prácticas recomendadas de seguridad
**Topics**
CodePipeline proporciona una serie de características de seguridad que debe tener en cuenta a la hora de desarrollar e implementar sus propias políticas de seguridad. Las siguientes prácticas recomendadas son directrices generales y no constituyen una solución de seguridad completa. Puesto que es posible que estas prácticas recomendadas no sean adecuadas o suficientes para el entorno, considérelas como consideraciones útiles en lugar de como normas.
Utilice el cifrado y la autenticación para los repositorios de origen que se conectan a sus canalizaciones. Estas son las CodePipeline mejores prácticas de seguridad:
+ Si crea una configuración de canalización o acción que debe incluir secretos, como tokens o contraseñas, no introduzca los secretos directamente en la configuración de la acción ni los valores predeterminados de las variables definidas a nivel de canalización o CloudFormation configuración, ya que la información se mostrará en los registros. Utilice Secrets Manager para configurar y almacenar los secretos y, a continuación, utilice el secreto al que se hace referencia en la configuración de la canalización y la acción, tal y como se describe en [Se utiliza AWS Secrets Manager para rastrear las contraseñas de bases de datos o las claves de API de terceros](parameter-store-encryption.md).
+ Si crea una canalización que utiliza un bucket de origen de S3, configure el cifrado del lado del servidor para los artefactos almacenados en Amazon S3 CodePipeline mediante la administración AWS KMS keys, tal y como se describe en. [Configurar el cifrado del lado del servidor para los artefactos almacenados en Amazon S3 para CodePipeline](S3-artifact-encryption.md)
+ Cuando utilice un proveedor de compilación de Jenkins para la acción de compilación o prueba de la canalización, instale Jenkins en una instancia EC2 y configure un perfil de instancia EC2 distinto. Asegúrese de que el perfil de instancia conceda a Jenkins solo los AWS permisos necesarios para realizar las tareas del proyecto, como la recuperación de archivos de Amazon S3. Para saber cómo crear la función para su perfil de instancia de Jenkins, consulte los pasos que se describen en [Creación de un rol de IAM para usar en la integración de Jenkins](tutorials-four-stage-pipeline.md#tutorials-four-stage-pipeline-prerequisites-jenkins-iam-role).