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 y permisos
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los actuales. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Cada uno de tus usuarios debe tener AWS las credenciales adecuadas para acceder a los recursos de AWS tu cuenta. La forma recomendada de proporcionar credenciales a los usuarios es con [AWS Identity and Access Management](https://docs.aws.amazon.com/iam/)(IAM). OpsWorks Stacks se integra con IAM para que puedas controlar lo siguiente:
+ Cómo pueden interactuar los usuarios individuales con OpsWorks Stacks.
Por ejemplo, puede permitir que algunos usuarios implementen aplicaciones en cualquier pila pero no puedan modificar la pila en sí, y permitir que otros usuarios obtengan acceso completo pero solo a determinadas pilas, etcétera.
+ Cómo puede actuar OpsWorks Stacks en tu nombre para acceder a los recursos de la pila, como las EC2 instancias de Amazon y los buckets de Amazon S3.
OpsWorks Stacks proporciona un rol de servicio que otorga permisos para estas tareas.
+ Cómo las aplicaciones que se ejecutan en EC2 instancias de Amazon controladas por OpsWorks Stacks pueden acceder a otros AWS recursos, como los datos almacenados en los buckets de Amazon S3.
Puedes asignar un perfil de instancia a las instancias de una capa que otorgue permisos a las aplicaciones que se ejecutan en esas instancias para acceder a otros AWS recursos.
+ Cómo administrar claves SSH basadas en el usuario y utilizar SSH o RDP para conectarse a las instancias.
Para cada pila, los usuarios administradores pueden asignar a cada usuario de una clave SSH personal, o autorizarles a que especifiquen su propia clave. También puede autorizar el acceso SSH o RDP, y privilegios sudo o de administrador en las instancias de la pila a cada usuario.
Otros aspectos de seguridad:
+ Cómo administrar la actualización del sistema operativo de las instancias con los parches de seguridad más recientes.
Para obtener más información, consulte [Administración de actualizaciones de seguridad](workingsecurity-updates.md).
+ Cómo configurar los [grupos de EC2 seguridad de Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) para controlar el tráfico de red hacia y desde tus instancias.
Cómo especificar grupos de seguridad personalizados en lugar de los grupos de seguridad predeterminados de OpsWorks Stacks. Para obtener más información, consulte [Uso de grupos de seguridad](workingsecurity-groups.md).
**Topics**
+ [Administrar los permisos OpsWorks de usuario de Stacks](opsworks-security-users.md)
+ [¿Permitir que OpsWorks Stacks actúe en tu nombre](opsworks-security-servicerole.md)
+ [Prevención multiservicio de policía confusa en Stacks OpsWorks](cross-service-confused-deputy-prevention-stacks.md)
+ [Especificar los permisos para las aplicaciones que se ejecutan en instancias EC2](opsworks-security-appsrole.md)
+ [Administración del acceso SSH](security-ssh-access.md)
+ [Administración de actualizaciones de seguridad de Linux](workingsecurity-updates.md)
+ [Uso de grupos de seguridad](workingsecurity-groups.md)
# Administrar los permisos OpsWorks de usuario de Stacks
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Como práctica recomendada, restringe a los usuarios de OpsWorks Stacks a un conjunto específico de acciones o a un conjunto de recursos de stack. Puedes controlar los permisos de usuario de OpsWorks Stacks de dos maneras: mediante la página de **permisos** de OpsWorks Stacks y aplicando una política de IAM adecuada.
*La página de OpsWorks **permisos** (o las acciones de CLI o API equivalentes) le permiten controlar los permisos de los usuarios en un entorno multiusuario por pila asignando a cada usuario uno de varios niveles de permisos.* Cada nivel concede permisos para un conjunto estándar de acciones sobre un determinado recurso de la pila. Con la página **Permissions (Permisos)**, puede controlar los elementos siguientes:
+ Quién puede obtener acceso a cada pila.
+ Qué acciones puede realizar cada usuario en cada pila.
Por ejemplo, puede permitir que algunos usuarios solo vean la pila, mientras que otros pueden implementar aplicaciones, añadir instancias, etc.
+ Quién puede administrar cada pila.
Puede delegar la administración de cada conjunto a uno o varios usuarios especificados.
+ Quién tiene acceso SSH y privilegios de sudo a nivel de usuario (Linux) o acceso RDP y privilegios de administrador (Windows) en las instancias de Amazon de cada pila. EC2
Puede conceder o eliminar estos permisos de forma independiente para cada usuario en cualquier momento.
**importante**
Denegar el SSH/RDP acceso no impide necesariamente que un usuario inicie sesión en las instancias. Si especificas un par de EC2 claves de Amazon para una instancia, cualquier usuario con la clave privada correspondiente puede iniciar sesión o utilizar la clave para recuperar la contraseña de administrador de Windows. Para obtener más información, consulte [Administración del acceso SSH](security-ssh-access.md).
Puede utilizar la CLI, la API o la [consola de IAM](https://console.aws.amazon.com/iam) para asociar a los usuarios políticas que concedan permisos explícitos para los distintos recursos y acciones de OpsWorks Stacks.
+ El uso de una política de IAM para especificar permisos es más flexible que usar niveles de permisos.
+ Puede configurar [las identidades de IAM (usuarios, grupos de usuarios y roles),](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) que otorgan permisos a las identidades de IAM, como los usuarios y los grupos de usuarios, o definir [roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que se pueden asociar a los usuarios federados.
+ Una política de IAM es la única forma de conceder permisos para determinadas acciones clave de OpsWorks Stacks.
Por ejemplo, debe utilizar IAM para conceder permisos sobre `opsworks:CreateStack` y `opsworks:CloneStack`, que se utilizan para crear y clonar pilas respectivamente.
Si bien no es posible importar usuarios federados a la consola de forma explícita, un usuario federado puede crear implícitamente un perfil de usuario si selecciona **Mi configuración** en la esquina superior derecha de la consola de OpsWorks Stacks y, a continuación, selecciona **Usuarios**, también en la esquina superior derecha. En la página **Usuarios**, los usuarios federados (cuyas cuentas se crean mediante la API o la CLI, o implícitamente mediante la consola) pueden administrar sus cuentas de forma similar a la de los usuarios de IAM no federados.
Los dos enfoques no son mutuamente excluyentes y en ocasiones es útil combinarlos; en dicho caso, OpsWorks Stacks evalúa ambos conjuntos de permisos. Por ejemplo, supongamos que quiera que los usuarios puedan añadir o eliminar instancias, pero no añadir ni eliminar capas. Ninguno de los niveles de permisos de OpsWorks Stacks otorga ese conjunto específico de permisos. Sin embargo, tiene a su disposición la página **Permisos** para conceder a los usuarios un nivel de permiso **Administrar**, lo que les permite realizar la mayoría de las operaciones de la pila, y después adjuntar una política de IAM que deniegue los permisos para añadir o eliminar capas. Para obtener más información, consulte [Controlar el acceso a recursos de AWS mediante políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html).
A continuación se presenta un modelo típico de administración de permisos de usuario. En cada caso, se presupone que el lector (usted) es un usuario administrativo.
1. Usa la [consola de IAM](https://console.aws.amazon.com/iam) para aplicar AWSOpsWorks\$1FullAccess políticas a uno o más usuarios administrativos.
1. Cree un usuario para cada usuario que no sea administrativo y tenga una política que no conceda permisos de OpsWorks Stacks.
Si un usuario solo necesita acceder a OpsWorks Stacks, es posible que no necesites aplicar ninguna política en absoluto. En su lugar, puedes administrar sus permisos en la página de **permisos OpsWorks ** de Stacks.
1. Usa la página de **usuarios** de OpsWorks Stacks para importar los usuarios no administrativos a Stacks. OpsWorks
1. Para cada pila, utilice la página **Permissions (Permisos)** de la pila para asignar un nivel de permiso a cada usuario.
1. Según sus necesidades, personalice los niveles de permisos de usuarios adjuntando una política de IAM configurada adecuadamente.
Para ver más recomendaciones acerca de la administración de usuarios, consulte [Prácticas recomendadas: Administración de permisos](best-practices-permissions.md).
Para obtener más información sobre las prácticas recomendadas de IAM, consulte las [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía de usuario de IAM*.
**Topics**
+ [Administrar los usuarios de Stacks OpsWorks](opsworks-security-users-manage.md)
+ [Otorgar permisos por OpsWorks pila a los usuarios de Stacks](opsworks-security-users-console.md)
+ [Administra los permisos de OpsWorks Stacks adjuntando una política de IAM](opsworks-security-users-policy.md)
+ [Ejemplos de políticas](opsworks-security-users-examples.md)
+ [OpsWorks Apila los niveles de permisos](opsworks-security-users-standard.md)
# Administrar los usuarios de Stacks OpsWorks
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Para poder importar usuarios a OpsWorks Stacks y concederles permisos, primero debes haber creado un usuario para cada persona. Para crear usuarios de IAM, comienza por iniciar sesión AWS como un usuario al que se le hayan concedido los permisos definidos en la política de IAMFull acceso. Luego, usas la consola de IAM para [crear usuarios de IAM](opsworks-security-users-create-user.md) para todos los que necesiten acceder a Stacks. OpsWorks A continuación, puedes importar esos usuarios a OpsWorks Stacks y conceder los permisos de usuario de la siguiente manera:
**Usuarios habituales de OpsWorks Stacks**
Los usuarios habituales no necesitan una política adjunta. Si tienen uno, normalmente no incluye ningún permiso de OpsWorks Stacks. En su lugar, usa la página de **permisos** de OpsWorks Stacks para asignar uno de los siguientes niveles de permisos a los usuarios normales de forma stack-by-stack periódica.
+ Los permisos **Show (Mostrar)** permiten a los usuarios ver la pila, pero no llevar a cabo ninguna operación.
+ Los permisos **Deploy (Implementar)** contienen los permisos **Show (Mostrar)** y también permiten a los usuarios implementar y actualizar aplicaciones.
+ Los permisos de **administración** incluyen los permisos de **implementación** y también permiten a los usuarios realizar operaciones de administración de pilas, como agregar capas o instancias, usar la página de **permisos** para configurar los permisos de los usuarios y habilitar sus propios SSH/RDP privilegios y los de sudo/administrador.
+ Los permisos **Deny (Denegar)** deniegan el acceso a la pila.
Si estos niveles de permisos no son exactamente lo que quiere para un usuario determinado, puede personalizar los permisos del usuario adjuntando una política de IAM. Por ejemplo, puede utilizar la página de **permisos** de las OpsWorks pilas para asignar el nivel de **gestión** de permisos a un usuario, lo que le otorga permisos para realizar todas las operaciones de administración de pilas, pero no para crear o clonar pilas. A continuación, puede adjuntar una política que restrinja dichos permisos rechazando el permiso para añadir o eliminar capas o que los aumente permitiendo al usuario crear o clonar pilas. Para obtener más información, consulte [Administra los permisos de OpsWorks Stacks adjuntando una política de IAMAdjuntar una política de IAM](opsworks-security-users-policy.md).
**OpsWorks Apila a los usuarios administrativos**
[Los usuarios administrativos son el propietario de la cuenta o un usuario de IAM con los permisos definidos en la AWSOpsWorks\$1FullAccess política.](opsworks-security-users-examples.md#opsworks-security-users-examples-admin) Además de los permisos concedidos a usuarios **Manage (Administrar)**, esta política incluye permisos para realizar acciones que no se pueden conceder a través de la página **Permissions (Permisos)**, como las siguientes:
+ Importación de usuarios a Stacks OpsWorks
+ Creación y clonación de pilas
Para ver la política completa, consulte [Ejemplos de políticas](opsworks-security-users-examples.md). Para obtener una lista detallada de los permisos que se pueden conceder a los usuarios únicamente adjuntando una política de IAM, consulte [OpsWorks Apila los niveles de permisosNiveles de permisos](opsworks-security-users-standard.md).
**Topics**
+ [Usuarios y regiones](#UsersandRegions)
+ [Crear un usuario administrativo OpsWorks de Stacks](opsworks-security-users-manage-admin.md)
+ [Crear usuarios de IAM para Stacks OpsWorks](opsworks-security-users-create-user.md)
+ [Importación de usuarios a pilas OpsWorks](opsworks-security-users-manage-import.md)
+ [Edición de la configuración OpsWorks de usuario de Stack](opsworks-security-users-manage-edit.md)
## Usuarios y regiones
OpsWorks Los usuarios de Stacks están disponibles en el punto final regional en el que se crearon. Puede crear usuarios en cualquiera de las regiones siguientes.
+ Región del Este de EE. UU. (Ohio)
+ Región del Este de EE. UU (Norte de Virginia)
+ Región del Oeste de EE. UU (Oregón)
+ Región Oeste de EE. UU. (Norte de California)
+ Región Canadá (Central) (solo API); no está disponible en Consola de administración de AWS
+ Región de Asia-Pacífico (Bombay)
+ Región de Asia-Pacífico (Singapur)
+ Región de Asia-Pacífico (Sídney)
+ Región de Asia-Pacífico (Tokio)
+ Región de Asia-Pacífico (Seúl)
+ Europe (Frankfurt) Region
+ Región de Europa (Irlanda)
+ Región de Europa (Londres)
+ Región Europa (París)
+ Región de América del Sur (São Paulo)
Cuando importas usuarios a OpsWorks Stacks, los importas a uno de los puntos de enlace regionales; si quieres que un usuario esté disponible en más de una región, debes importarlo a esa región. También puedes importar usuarios de OpsWorks Stacks de una región a otra; si importas un usuario a una región que ya tiene un usuario con el mismo nombre, el usuario importado sustituirá al usuario existente. Para obtener más información acerca de cómo importar los usuarios, consulte [Importación de usuarios](opsworks-security-users-manage-import.md).
# Crear un usuario administrativo OpsWorks de Stacks
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Puedes crear un usuario administrativo de OpsWorks Stacks añadiendo la `AWSOpsWorks_FullAccess` política a un usuario, lo que le otorga a ese usuario los permisos de acceso total de OpsWorks Stacks. Para obtener más información sobre la creación de un usuario administrativo, consulte [Crear un usuario administrativo](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html#create-an-admin).
**nota**
La AWSOpsWorks\$1FullAccess política permite a los usuarios crear y administrar pilas de OpsWorks Stacks, pero los usuarios no pueden crear una función de servicio de IAM para la pila; deben utilizar una función existente. El primer usuario que cree una pila debe tener permisos de IAM adicionales, tal y como se describe en [Permisos administrativos](opsworks-security-users-examples.md#opsworks-security-users-examples-admin). Cuando este usuario crea la primera pila, OpsWorks Stacks crea un rol de servicio de IAM con los permisos necesarios. A partir de entonces, todos los usuarios que tengan permisos `opsworks:CreateStack` pueden utilizar dicho rol para crear pilas adicionales. Para obtener más información, consulte [¿Permitir que OpsWorks Stacks actúe en tu nombre](opsworks-security-servicerole.md).
Al crear un usuario, puede añadir políticas adicionales gestionadas por el cliente para ajustar los permisos del usuario, según sea necesario. Por ejemplo, es posible que quiera que un usuario administrativo pueda crear o eliminar pilas, pero no importar usuarios nuevos. Para obtener más información, consulte [Administra los permisos de OpsWorks Stacks adjuntando una política de IAMAdjuntar una política de IAM](opsworks-security-users-policy.md).
Si tienes varios usuarios administrativos, en lugar de configurar los permisos por separado para cada usuario, puedes añadir la AWSOpsWorks\$1FullAccess política a un grupo de IAM y añadir los usuarios a ese grupo.
Para obtener información acerca de la creación de grupos, consulte [Creación de grupo de usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html). Cuando cree el grupo, añada la **AWSOpsWorks\$1FullAccess**política. También puede añadir la **AdministratorAccess**política, que incluye los **AWSOpsWorks\$1FullAccess**permisos.
Para obtener información sobre cómo agregar permisos a un grupo existente, consulte [Adjuntar una política a un grupo de usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_attach-policy.html).
# Crear usuarios de IAM para Stacks OpsWorks
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Antes de poder importar usuarios de IAM a OpsWorks Stacks, debes crearlos. Puede hacerlo utilizando la [consola de IAM](https://console.aws.amazon.com/iam/), la línea de comandos o la API. Para obtener instrucciones completas, consulta [Cómo crear un usuario de IAM en tu cuenta](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html). AWS
Tenga en cuenta que, a diferencia de los [usuarios administrativos](opsworks-security-users-manage-admin.md), no es necesario adjuntar una política para definir permisos. Puede establecer permisos después de [importar los usuarios a OpsWorks Stacks](opsworks-security-users-manage-import.md), tal y como se explica en [Administración de permisos de usuario](opsworks-security-users.md).
Para obtener más información acerca de cómo crear usuarios y grupos de IAM, consulte [Getting started with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html).
# Importación de usuarios a pilas OpsWorks
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Los usuarios administrativos pueden importar usuarios a OpsWorks Stacks; también pueden importar usuarios de OpsWorks Stacks de un punto final regional a otro. Cuando importas usuarios a OpsWorks Stacks, los importas a uno de los puntos de enlace regionales de OpsWorks Stacks. Si quiere que un usuario esté disponible en más de una región, debe importar el usuario a dicha región.
Si bien no es posible importar usuarios federados a la consola de forma explícita, un usuario federado puede crear implícitamente un perfil de usuario al elegir **Mi configuración** en la esquina superior derecha de la consola de OpsWorks Stacks y, a continuación, elegir **Usuarios**, también en la esquina superior derecha. En la página **Usuarios**, los usuarios federados (cuyas cuentas se crean mediante la API o la CLI, o implícitamente mediante la consola) pueden administrar sus cuentas de forma similar a la de los usuarios de IAM no federados.
**Para importar usuarios a Stacks OpsWorks**
1. Inicia sesión en OpsWorks Stacks como usuario administrativo o como propietario de la cuenta.
1. Elija **Users (Usuarios)** en la parte superior derecha para abrir la página **Users (Usuarios)**.
![\[Página Users que muestra usuarios de us-east-1\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/permissions_users_page.png)
1. Selecciona **Importar usuarios de IAM a < *region name* >** para ver los usuarios que están disponibles, pero que aún no se han importado.
![\[Comandos de importación de la página Users\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/permissions_import.png)
1. Marque la casilla **Select all (Seleccionar todo)** o seleccione uno o varios usuarios individuales. Cuando haya terminado, seleccione **Importar a OpsWorks**.
**nota**
Una vez que hayas importado un usuario a OpsWorks Stacks, si utilizas la consola o la API de IAM para eliminar al usuario de tu cuenta, este no perderá automáticamente el acceso a SSH que le has concedido a través de Stacks. OpsWorks **También debes eliminar al usuario de OpsWorks Stacks. Para ello, abre la página de **usuarios** y selecciona **Eliminar** en la columna Acciones del usuario.**
**Para importar usuarios OpsWorks de Stacks de una región a otra**
OpsWorks Los usuarios de Stacks están disponibles en el punto final regional en el que se crearon. Puede crear usuarios en las regiones que se muestran en [Usuarios y regiones](opsworks-security-users-manage.md#UsersandRegions).
Puedes importar los usuarios de OpsWorks Stacks de una región a la región por la que está filtrada tu lista de **usuarios** actualmente. Si importa un usuario a una región que ya tiene un usuario con el mismo nombre, el usuario importado sustituirá al usuario existente.
1. Inicia sesión en OpsWorks Stacks como usuario administrativo o como propietario de la cuenta.
1. Elija **Users (Usuarios)** en la parte superior derecha para abrir la página **Users (Usuarios)**. Si tienes usuarios de OpsWorks Stacks en más de una región, usa el control de **filtrado** para filtrar por la región a la que deseas importar los usuarios.
![\[Página Users que muestra usuarios de us-east-1\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/permissions_users_page.png)
1. Selecciona **Importar usuarios de OpsWorks Stacks de otra región a < > *current region***.
![\[Página Users que muestra usuarios de us-west-2\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/permissions_import_otherregion.png)
1. Selecciona la región desde la que quieres importar los usuarios de OpsWorks Stacks.
1. Seleccione uno o varios usuarios que desee importar o seleccione todos los usuarios y, a continuación, elija **Import to this region (Importar a esta región)**. Espera a que OpsWorks Stacks muestre los usuarios importados en la lista de **usuarios**.
## Unix IDs y los usuarios creados fuera de Stacks OpsWorks
OpsWorks asigna a los usuarios de las instancias de OpsWorks Stacks valores de ID de Unix (UID) entre 2000 y 4000. Como OpsWorks reserva el rango de 2000 a 4000 UIDs, los usuarios que crees fuera de él OpsWorks (mediante recetas de libros de cocina o importándolos OpsWorks desde IAM, por ejemplo) pueden hacer UIDs que Stacks los sobrescriba para otro usuario. OpsWorks Esto puede provocar que los usuarios que hayas creado fuera de OpsWorks Stacks no aparezcan en los resultados de búsqueda de las bolsas de datos o que queden excluidos de la operación integrada de Stacks. OpsWorks `sync_remote_users`
Los procesos externos también pueden crear usuarios con los UIDs que OpsWorks Stacks los puede sobrescribir. Algunos paquetes de sistemas operativos, por ejemplo, pueden crear un usuario como parte de los procesos posteriores a la instalación. Cuando tú o un proceso de software creáis un usuario en un sistema operativo basado en Linux sin especificar explícitamente un UID (que es el predeterminado), el UID asignado por Stacks es \$11. OpsWorks **
Como práctica recomendada, crea usuarios de OpsWorks Stacks y administra su acceso en la consola de Stacks o mediante un SDK. OpsWorks AWS CLI AWS Si creas usuarios en instancias de OpsWorks Stacks fuera de OpsWorks, usa *UnixID* valores superiores a 4000.
# Edición de la configuración OpsWorks de usuario de Stack
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Después de importar los usuarios, puede editar su configuración, tal y como se indica a continuación:
**Para editar la configuración de usuario**
1. En la página **Users (Usuarios)**, elija **edit** en la columna **Actions (Acciones)** del usuario.
1. Puede especificar las opciones siguientes.
**Administración autónoma**
Selecciona **Sí** para permitir que el usuario utilice la MySettings página para especificar su clave SSH personal.
También puede habilitar la autogestión añadiendo una política de IAM a la identidad de IAM que conceda permisos para las acciones y. [DescribeMyUserProfile[UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html)](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html)
**Clave SSH pública**
(Opcional) Escriba una clave SSH pública para el usuario. Esta clave aparecerá en la página **My Settings (Mi configuración)** del usuario. Si habilita la autogestión, el usuario puede editar **My Settings (Mi configuración)** y especificar su propia clave. Para obtener más información, consulte [Registro de la clave pública SSH de un usuario](security-settingsshkey.md).
OpsWorks Stacks instala esta clave en todas las instancias de Linux; los usuarios pueden usar la clave privada asociada para iniciar sesión. Para obtener más información, consulte [Inicio de sesión con SSH](workinginstances-ssh.md). No puede utilizar esta clave con pilas de Windows.
**Permisos**
(Opcional) Establezca los niveles de permisos del usuario para cada pila en un único lugar, en vez de establecerlos por separado mediante la página **Permissions (Permisos)** de cada pila. Para obtener más información acerca de los niveles de permisos, consulte [Concesión de permisos por pila](opsworks-security-users-console.md).
![\[User details page showing name, ARN, SSH settings, and permission levels for various stacks.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/permissions_edit_user.png)
# Otorgar permisos por OpsWorks pila a los usuarios de Stacks
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
**La forma más sencilla de gestionar los permisos de usuario de OpsWorks Stacks es mediante la página de permisos de un stack.** Cada pila tiene su propia página, que concede permisos de dicha pila.
Debe haber iniciado sesión como usuario administrativo o usuario **Manage (Administrar)** para modificar cualquiera de las opciones de los permisos. La lista muestra solo los usuarios que se han importado a OpsWorks Stacks. Para obtener información acerca de cómo crear e importar usuarios, consulte [Administración de usuarios](opsworks-security-users-manage.md).
El nivel de permiso predeterminado es IAM Policies Only, que concede a los usuarios únicamente los permisos que están en su política de IAM adjunta.
+ Cuando importa un usuario de IAM o de otra región, el usuario se añade a la lista de todas las pilas existentes con un nivel de permiso **Solo Políticas de IAM**.
+ De forma predeterminada, un usuario que se acaba de importar de otra región no tiene acceso a las pilas de la región de destino. Si importa usuarios de otra región, para permitirlos administrar pilas en la región de destino, es preciso asignarles permisos para dichas pilas después de importarlos.
+ Cuando crea una nueva pila, se añaden todos los usuarios actuales a la lista con niveles de permiso **IAM Policies Only (Solo políticas de IAM)**.
**Topics**
+ [Configuración de los permisos de un usuario](#opsworks-security-users-console-set)
+ [Visualización de los permisos](#opsworks-security-users-console-viewing)
+ [Uso de las claves de condición de IAM para verificar credenciales temporales](#w2ab1c14c67c15c37c21)
## Configuración de los permisos de un usuario
**Para establecer los permisos de un usuario**
1. En el panel de navegación, elija **Permissions (Permisos)**.
1. En la página **Permissions (Permisos)**, elija **Edit (Editar)**.
1. Cambie la configuración de **Permission level (Nivel de permisos)** e **Instance access (Acceso a instancia)**:
+ Utilice la opción **Permissions level (Nivel de permisos)** para asignar uno de los niveles de permiso estándar a cada usuario, lo que determina si el usuario puede obtener acceso a la pila en cuestión y qué acciones puede realizar. Si un usuario tiene una política de IAM, OpsWorks Stacks evalúa ambos conjuntos de permisos. Para ver un ejemplo, consulte [Ejemplos de políticas](opsworks-security-users-examples.md).
+ La opción **Instance access (Acceso a instancia)** **SSH/RDP** especifica si el usuario dispone de acceso SSH (Linux) o RDP (Windows) a las instancias de la pila.
Si autoriza el acceso **SSH/RDP**, tiene la opción de seleccionar **sudo/admin**, que concede al usuario privilegios sudo (Linux) o administrativos (Windows) sobre las instancias de la pila.
![\[Administración de usuarios con la página Permissions.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/permissions-edit.png)
Puede asignar a cada usuario uno de los siguientes niveles de permisos. Para obtener una lista de las acciones que se permiten en cada nivel, consulte [OpsWorks Apila los niveles de permisosNiveles de permisos](opsworks-security-users-standard.md).
**Denegar**
El usuario no puede realizar ninguna acción de OpsWorks Stacks en la pila, aunque tenga una política de IAM que conceda OpsWorks a Stacks todos los permisos de acceso. Puede utilizarla para, por ejemplo, denegar a algunos usuarios el acceso a pilas de productos que no se han distribuido.
**IAM Policies Only (Solo políticas de IAM)**
El nivel predeterminado, asignado a todos los usuarios recién importados y a todos los usuarios de las pilas recién creadas. Los permisos de usuario se determinan en función de la política de IAM. Si un usuario no tiene una política de IAM o su política no tiene permisos explícitos de OpsWorks Stacks, no podrá acceder a la pila. Normalmente, se asigna a los usuarios administrativos este nivel porque sus políticas de IAM adjuntas ya conceden permisos de acceso completos.
**Show (Mostrar)**
El usuario puede ver una pila, pero no llevar a cabo ninguna operación. Por ejemplo, es posible que los administradores quieran monitorizar las pilas de una cuenta, pero, en dicho caso, no tendrían que implementar aplicaciones o modificar la pila de alguna forma.
**implementación**
Incluye los permisos **Show (Mostrar)** y también permite al usuario implementar aplicaciones. Por ejemplo, puede que un desarrollador de aplicaciones necesite implementar actualizaciones en las instancias de la pila, pero no añadir capas ni instancias a la pila.
**Administración**
Incluye los permisos **Deploy (Implementar)** y también permite al usuario realizar diversas operaciones de administración de pila, entre las que se incluyen:
+ Añadir o eliminar capas e instancias.
+ Utilizar la página **Permissions (Permisos)** para asignar niveles de permisos a los usuarios.
+ Registrar o anular el registro de recursos.
Por ejemplo, cada pila puede tener un administrador exclusivo, responsable de garantizar que la pila tenga el número y el tipo de instancias adecuado, la gestión de las actualizaciones del paquete y el sistema operativo, etc.
El nivel Manage no permite a los usuarios crear ni clonar pilas. Estos permisos deben concederse mediante una política de IAM adjunta. Para ver un ejemplo, consulta [Administración de permisos](opsworks-security-users-examples.md#opsworks-security-users-examples-manage).
Si el usuario también tiene una política de IAM, OpsWorks Stacks evalúa ambos conjuntos de permisos. De esta forma, podrá asignar un nivel de permiso a un usuario y, a continuación, adjuntar una política para restringir o aumentar las acciones que el nivel permite. Por ejemplo, puede adjuntar una política que permita a un usuario **Administrar** crear o clonar pilas, o deniegue al usuario la capacidad para registrar o anular el registro de recursos. Para ver algunos ejemplos de tales políticas, consulte [Ejemplos de políticas](opsworks-security-users-examples.md).
**nota**
Si la política del usuario permite acciones adicionales, puede parecer que el resultado anula la configuración de la página **Permissions (Permisos)**. Por ejemplo, si un usuario tiene una política que permite la [CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)acción, pero tú utilizas la página de **permisos** para especificar los permisos de **implementación**, el usuario podrá seguir creando capas. La excepción a esta regla es la opción **Denegar**, que deniega el acceso a la pila incluso a los usuarios con AWSOpsWorks\$1FullAccess políticas. Para obtener más información, consulte [Controlar el acceso a AWS los recursos mediante políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html).
## Visualización de los permisos
Si la opción [self-management](opsworks-security-users-manage-edit.md) está habilitada, los usuarios pueden ver un resumen de sus niveles de permisos para cada pila eligiendo **My Settings (Mi configuración)** en la parte superior derecha. Los usuarios también pueden acceder a **Mi configuración** si su política concede permisos para las [UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html)acciones [DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html)y.
## Uso de las claves de condición de IAM para verificar credenciales temporales
OpsWorks Stacks tiene una capa de autorización integrada que admite casos de autorización adicionales (como la administración simplificada del acceso de solo lectura o lectura y escritura a las pilas para usuarios individuales). Esta capa de autorización se basa en el uso de credenciales temporales. Por este motivo, no puede utilizar una condición de `aws:TokenIssueTime` para verificar que los usuarios utilicen credenciales a largo plazo o bloquear acciones de usuarios que utilicen credenciales temporales, tal y como se describe en la sección [Elementos de referencia de la política JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null) de la documentación de IAM.
# Administra los permisos de OpsWorks Stacks adjuntando una política de IAM
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Puedes especificar los permisos de OpsWorks Stacks de un usuario adjuntando una política de IAM. Se necesita una política adjunta para algunos permisos:
+ Permisos de usuarios administrativos, como la importación de usuarios.
+ Permisos para algunas acciones, como la creación o la clonación de una pila.
Para obtener una lista completa de acciones que requieren una política adjunta, consulte [OpsWorks Apila los niveles de permisosNiveles de permisos](opsworks-security-users-standard.md).
También puede utilizar una política adjunta para personalizar niveles de permisos que se concedieron a través de la página **Permisos**. En esta sección se proporciona un breve resumen de cómo aplicar una política de IAM a un usuario para especificar los permisos de Stacks. OpsWorks Para obtener más información, consulta [Administración del acceso a los AWS recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html).
Una política de IAM es un objeto JSON que contiene una o varias *instrucciones*. Cada instrucción tiene una lista de permisos, que tienen tres elementos básicos propios:
**Action**
Las acciones a las que afecta el permiso. Las acciones de OpsWorks Stacks se especifican como`opsworks:action`. Una `Action` puede configurarse como una acción específica como `opsworks:CreateStack`, que especifica si el usuario puede llamar a [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html). También puede utilizar comodines para especificar grupos de acciones. Por ejemplo, `opsworks:Create*` especifica todas las acciones de creación. Para obtener una lista completa de las acciones de OpsWorks Stacks, consulta la referencia de la API de [OpsWorks Stacks](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html).
**Effect**
Se indica si las acciones especificadas se permiten o no.
**Resource**
Los AWS recursos a los que afecta el permiso. OpsWorks Las pilas tienen un tipo de recurso, la pila. Para especificar permisos para un recurso de pila determinado, establezca `Resource` en el ARN de la pila, que tiene el siguiente formato: `arn:aws:opsworks:region:account_id:stack/stack_id/`.
También puede utilizar comodines. Por ejemplo, si configura `Resource` en `*`, concederá permisos para todos los recursos.
Por ejemplo, la política siguiente deniega al usuario la posibilidad de parar instancias de la pila cuyo ID sea `2860-2f18b4cb-4de5-4429-a149-ff7da9f0d8ee`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "opsworks:StopInstance",
"Effect": "Deny",
"Resource": "arn:aws:opsworks:*:*:stack/2f18b4cb-4de5-4429-a149-ff7da9f0d8ee/"
}
]
}
```
------
Para obtener información sobre cómo añadir permisos a un usuario de IAM, consulte [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console).
Para obtener más información acerca de cómo crear o modificar políticas de IAM, consulte [Permissions and Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). Para ver algunos ejemplos de las políticas de OpsWorks Stacks, consulte. [Ejemplos de políticas](opsworks-security-users-examples.md)
# Ejemplos de políticas
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los actuales. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
En esta sección, se describen ejemplos de políticas de IAM que se pueden aplicar a OpsWorks los usuarios de Stacks.
+ [Permisos administrativos](#opsworks-security-users-examples-admin) muestra políticas que se pueden utilizar para conceder permisos a usuarios administrativos.
+ [Administración de permisos](#opsworks-security-users-examples-manage) y [Permisos Deploy](#opsworks-security-users-examples-deploy) muestran ejemplos de políticas que se pueden adjuntar a un usuario para ampliar o restringir los niveles de permisos Manage y Deploy.
OpsWorks **Stacks determina los permisos del usuario evaluando los permisos otorgados por las políticas de IAM, así como los permisos otorgados por la página de permisos.** Para obtener más información, consulta Cómo [controlar el acceso a AWS los recursos mediante políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html). Para obtener más información acerca de los permisos de la página **Permissions (Permisos)**, consulte [OpsWorks Apila los niveles de permisosNiveles de permisos](opsworks-security-users-standard.md).
## Permisos administrativos
Usa la consola de IAM para acceder a la AWSOpsWorks\$1FullAccess política. Adjunta esta política a un usuario para concederle permisos para realizar todas las acciones de OpsWorks Stacks. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) Los permisos de IAM son obligatorios, entre otras cosas, para permitir a un usuario administrativo importar usuarios.
Debes crear [funciones de IAM que permitan](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) a OpsWorks Stacks actuar en tu nombre para acceder a otros AWS recursos, como las instancias de Amazon EC2 . Por lo general, para realizar esta tarea, debes hacer que un usuario administrativo cree la primera pila y dejar que OpsWorks Stacks cree la función por ti. A continuación, puede utilizar este rol para todas las pilas posteriores. Para obtener más información, consulte [¿Permitir que OpsWorks Stacks actúe en tu nombre](opsworks-security-servicerole.md).
El usuario administrativo que crea la primera pila debe tener permisos para algunas acciones de IAM que no estén incluidas en la AWSOpsWorks\$1FullAccess política. Añada los permisos siguientes a la sección `Actions` de la política. Para que la sintaxis JSON sea correcta, asegúrese de añadir comas entre las acciones y de eliminar la coma final al final de la lista de acciones.
```
"iam:PutRolePolicy",
"iam:AddRoleToInstanceProfile",
"iam:CreateInstanceProfile",
"iam:CreateRole"
```
## Administración de permisos
El nivel de permisos **Manage (Administrar)** permite a un usuario realizar diversas acciones de administración de la pila, como añadir o eliminar capas. En este tema se describen varias políticas que puede adjuntar a usuarios **Administrar** para ampliar o restringir los permisos estándar.
Denegar a un usuario **Manage (Administrar)** la capacidad para añadir o eliminar capas
Puede restringir el nivel de permisos **Administrar** para permitir a un usuario realizar todas las acciones **Administrar**, salvo añadir o eliminar capas, adjuntando la siguiente política de IAM. Sustituya *region* y por *stack\$1id* los valores adecuados a su configuración. *account\$1id*
Permitir a un usuario **Manage (Administrar)** crear o clonar pilas
El nivel de permisos **Manage** no permite a los usuarios crear o clonar pilas. Puede aumentar los permisos **Administrar** para permitir a un usuario crear o clonar pilas adjuntando la siguiente política de IAM. Sustituya *region* y *account\$1id* por los valores adecuados a su configuración.
Denegar a un usuario Manage la capacidad para registrar o anular el registro de recursos
El nivel de permisos **Administrar** permite al usuario [registrar y anular el registro de recursos de una dirección IP elástica y de Amazon EBS](resources-reg.md) con la pila. Puede restringir los permisos **Administrar** para permitir al usuario llevar a cabo todas las acciones **Administrar**, salvo registrar recursos adjuntando la siguiente política.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"opsworks:RegisterVolume",
"opsworks:RegisterElasticIp"
],
"Resource": "*"
}
]
}
```
Permitir a un usuario **Manage (Administrar)** importar usuarios
El nivel **Administrar** permisos no permite a los usuarios importar usuarios a OpsWorks Stacks. Puede aumentar los permisos **Administrar** para permitir a un usuario importar y eliminar usuarios adjuntando la siguiente política de IAM. Sustituye *region* y *account\$1id* por los valores adecuados a tu configuración.
## Permisos Deploy
El nivel de permisos **Deploy (Implementar)** no permite a los usuarios crear o eliminar aplicaciones. Puede aumentar los permisos **Implementar** para permitir a un usuario crear y eliminar aplicaciones adjuntando la siguiente política de IAM. Sustituya *region* y *stack\$1id* por valores adecuados a su configuración. *account\$1id*
# OpsWorks Apila los niveles de permisos
**importante**
El AWS OpsWorks Stacks servicio finalizó su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
**En esta sección, se enumeran las acciones que permiten los niveles de permisos de **Mostrar**, **Implementar** y **Administrar** de la página de permisos de OpsWorks Stacks.** También contiene una lista de acciones sobre las que puede conceder permisos adjuntando una política de IAM al usuario.
**Show (Mostrar)**
El nivel **Show (Mostrar)** permite comandos `DescribeXYZ`, salvo las siguientes excepciones:
```
DescribePermissions
DescribeUserProfiles
DescribeMyUserProfile
DescribeStackProvisioningParameters
```
Si un usuario administrativo tiene la autogestión habilitada para el usuario, los usuarios **Show (Mostrar)** también pueden utilizar `DescribeMyUserProfile` y `UpdateMyUserProfile`. Para obtener más información acerca de la autogestión, consulte [Edición de la configuración de usuario](opsworks-security-users-manage-edit.md).
**implementación**
El nivel **Deploy (Implementar)** permite las siguientes acciones, además de las acciones que el nivel **Show (Mostrar)** permite.
```
CreateDeployment
UpdateApp
```
**Administración**
El nivel **Manage (Administrar)** permite las siguientes acciones, además de las acciones que los niveles **Deploy (Implementar)** y **Show (Mostrar)** permiten.
```
AssignInstance
AssignVolume
AssociateElasticIp
AttachElasticLoadBalancer
CreateApp
CreateInstance
CreateLayer
DeleteApp
DeleteInstance
DeleteLayer
DeleteStack
DeregisterElasticIp
DeregisterInstance
DeregisterRdsDbInstance
DeregisterVolume
DescribePermissions
DetachElasticLoadBalancer
DisassociateElasticIp
GrantAccess
GetHostnameSuggestion
RebootInstance
RegisterElasticIp
RegisterInstance
RegisterRdsDbInstance
RegisterVolume
SetLoadBasedAutoScaling
SetPermission
SetTimeBasedAutoScaling
StartInstance
StartStack
StopInstance
StopStack
UnassignVolume
UpdateElasticIp
UpdateInstance
UpdateLayer
UpdateRdsDbInstance
UpdateStack
UpdateVolume
```
**Permisos que necesitan una política de IAM**
Debe conceder permisos para las siguientes acciones adjuntando una política de IAM adecuada al usuario. Para ver algunos ejemplos, consulte [Ejemplos de políticas](opsworks-security-users-examples.md).
```
CloneStack
CreateStack
CreateUserProfile
DeleteUserProfile
DescribeUserProfiles
UpdateUserProfile
```
# ¿Permitir que OpsWorks Stacks actúe en tu nombre
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los actuales. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
OpsWorks Stacks necesita interactuar con una variedad de servicios de AWS en su nombre. Por ejemplo, OpsWorks Stacks interactúa con Amazon EC2 para crear instancias y con Amazon CloudWatch para obtener estadísticas de monitoreo. Cuando creas una pila, especificas una función de IAM, normalmente denominada función de servicio, que otorga a OpsWorks Stacks los permisos adecuados.
![\[Lista de roles de IAM en la página Agregar pila.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/add-stack-iamrole.png)
Cuando especifique un rol de servicio nuevo de la pila, puede hacer una de las acciones siguientes:
+ Especifique un rol de servicio estándar creado anteriormente.
Generalmente puede crear un rol de servicio estándar al crear la primera pila y, a continuación, utilizar dicho rol para todas las pilas subsiguientes.
+ Especifique un rol de servicio personalizado que haya creado mediante la consola o la API de IAM.
Este enfoque resulta útil si quieres conceder a OpsWorks Stacks permisos más limitados que el rol de servicio estándar.
**nota**
Para crear tu primera pila, debes tener los permisos definidos en la plantilla de **AdministratorAccess**política de IAM. Estos permisos permiten a OpsWorks Stacks crear un nuevo rol de servicio de IAM y le permiten a usted importar usuarios, [tal y como se ha descrito anteriormente](opsworks-security-users-manage-import.md). Para todas las pilas siguientes, los usuarios pueden seleccionar el rol de servicio creado para la primera pila; no requieren todos los permisos administrativos para crear una pila.
El rol de servicio estándar concede los siguientes permisos:
+ Realiza todas las EC2 acciones de Amazon (`ec2:*`).
+ Obtenga CloudWatch estadísticas (`cloudwatch:GetMetricStatistics`).
+ Utilice Elastic Load Balancing para distribuir el tráfico entre los servidores (`elasticloadbalancing:*`).
+ Utilice una instancia de Amazon RDS como servidor de bases de datos (`rds:*`)
+ Usa los roles de IAM (`iam:PassRole`) para proporcionar una comunicación segura entre OpsWorks Stacks y tus instancias de Amazon EC2 .
Si creas un rol de servicio personalizado, debes asegurarte de que otorgue todos los permisos que OpsWorks Stacks necesita para administrar tu stack. El siguiente ejemplo JSON la instrucción de política del rol de servicio estándar; un rol de servicio personalizado debe incluir al menos los siguientes permisos en su instrucción de política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:*",
"iam:PassRole",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"ecs:*",
"elasticloadbalancing:*",
"rds:*"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
```
------
Un rol de servicio también tiene una relación de confianza. Los roles de servicio creados por OpsWorks Stacks tienen la siguiente relación de confianza.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "StsAssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
El rol de servicio debe tener esta relación de confianza para que OpsWorks Stacks actúe en tu nombre. Si utiliza el rol de servicio predeterminado, no modifique la relación de confianza. Si crea un rol de servicio personalizado, especifique la relación de confianza mediante una de las opciones siguientes:
+ Si utiliza el asistente **Crear rol** de la [consola de IAM](https://console.aws.amazon.com/iam/home#roles), en **Elegir caso de uso**, seleccione **Opsworks**. Este rol tiene la relación de confianza adecuada, pero no incluye ninguna política implícita. Para conceder a OpsWorks Stacks permisos para que actúe en su nombre, cree una política administrada por el cliente que contenga lo siguiente y asóciela al nuevo rol.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms",
"cloudwatch:GetMetricStatistics",
"ec2:*",
"ecs:*",
"elasticloadbalancing:*",
"iam:GetRolePolicy",
"iam:ListInstanceProfiles",
"iam:ListRoles",
"iam:ListUsers",
"rds:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
}
}
}
]
}
```
------
+ Si utilizas una CloudFormation plantilla, puedes añadir algo como lo siguiente a la sección de **recursos** de la plantilla.
```
"Resources": {
"OpsWorksServiceRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "opsworks.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
} ]
},
"Path": "/",
"Policies": [ {
"PolicyName": "opsworks-service",
"PolicyDocument": {
...
} ]
}
},
}
}
```
# Prevención multiservicio de policía confusa en Stacks OpsWorks
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
El problema de la sustitución confusa es un problema de seguridad en el que una entidad que no tiene permiso para realizar una acción puede obligar a una entidad con más privilegios a realizar la acción. En AWS, la suplantación de identidad entre servicios puede provocar el confuso problema de un diputado. La suplantación entre servicios puede producirse cuando un servicio (el *servicio que lleva a cabo las llamadas*) llama a otro servicio (el *servicio al que se llama*). El servicio que lleva a cabo las llamadas se puedes manipular para utilizar sus permisos a fin de actuar en función de los recursos de otro cliente de una manera en la que no debe tener permiso para acceder. Para evitarlo, AWS proporciona herramientas que lo ayudan a proteger sus datos para todos los servicios con entidades principales de servicio a las que se les ha dado acceso a los recursos de su cuenta.
Recomendamos usar las claves de contexto de condición [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)global [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)y las claves de contexto en las políticas de acceso a las pilas para limitar los permisos que AWS OpsWorks Stacks concede a otro servicio a las pilas. Si el valor de `aws:SourceArn` no contiene el ID de cuenta, como un ARN de bucket de Amazon S3, debe utilizar ambas claves de contexto de condición global para limitar los permisos. Si utiliza claves de contexto de condición global y el valor de `aws:SourceArn` contiene el ID de cuenta, el valor de `aws:SourceAccount` y la cuenta en el valor de `aws:SourceArn` deben utilizar el mismo ID de cuenta cuando se utiliza en la misma instrucción de política. Utilice `aws:SourceArn` si desea que solo se asocie una pila al acceso entre servicios. Utilice `aws:SourceAccount` si quiere permitir que cualquier pila de esa cuenta se asocie al uso entre servicios.
El valor de `aws:SourceArn` debe ser el ARN de una OpsWorks pila.
La forma más eficaz de protegerse contra el problema del suplente confuso es utilizar la clave de contexto de condición global de `aws:SourceArn` con el ARN completo de la pila OpsWorks Stacks. Si no conoce el ARN completo o si está especificando varias pilas ARNs, utilice la clave de condición de contexto `aws:SourceArn` global con caracteres comodín (`*`) para las partes desconocidas del ARN. Por ejemplo, `arn:aws:servicename:*:123456789012:*`.
En la siguiente sección, se muestra cómo utilizar las claves de contexto de condición `aws:SourceAccount` global `aws:SourceArn` y las claves contextuales de OpsWorks Stacks para evitar el confuso problema de los adjuntos.
## Evita las confusas hazañas de los diputados en Stacks OpsWorks
En esta sección, se describe cómo puedes ayudar a prevenir las confusas vulnerabilidades secundarias en OpsWorks Stacks e incluye ejemplos de políticas de permisos que puedes adjuntar a la función de IAM que utilices para acceder a Stacks. OpsWorks Como práctica recomendada de seguridad, recomendamos que agregue las claves de condición `aws:SourceArn` y `aws:SourceAccount` a las relaciones de confianza que su rol de IAM tiene con otros servicios. Las relaciones de confianza permiten a OpsWorks Stacks asumir un rol para realizar acciones en otros servicios que son necesarias para crear o administrar tus Stacks Stacks. OpsWorks
**Para editar las relaciones de confianza y añadir las claves de condición `aws:SourceArn` y `aws:SourceAccount`**
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación izquierdo, elija **Roles**.
1. En el cuadro **de búsqueda**, busca el rol que utilizas para acceder a Stacks. OpsWorks El rol AWS administrado es`aws-opsworks-service-role`.
1. En la página **Resumen** del rol, seleccione la pestaña **Relaciones de confianza**.
1. En la pestaña **Relaciones de confianza**, seleccione **Editar política de confianza**.
1. En la página **Editar política de confianza**, añada al menos una de las claves de condición `aws:SourceArn` o `aws:SourceAccount` a la política. Se usa `aws:SourceArn` para restringir la relación de confianza entre servicios cruzados (como Amazon EC2) y OpsWorks Stacks a grupos de OpsWorks Stacks específicos, lo cual es más restrictivo. Agrega esta `aws:SourceAccount` opción para restringir la relación de confianza entre cross-services y OpsWorks Stacks a las pilas de una cuenta específica, lo cual es menos restrictivo. A continuación se muestra un ejemplo. Ten en cuenta que si utilizas ambas claves de condición, la cuenta IDs debe ser la misma.
1. Cuando haya terminado de agregar claves de condición, seleccione **Actualizar política**.
A continuación puede ver más ejemplos de roles que limitan el acceso a las pilas mediante el uso de `aws:SourceArn` y `aws:SourceAccount`.
**Topics**
+ [Ejemplo: Acceso a pilas en una región específica](#confused-deputy-opsworks-stacks-example1)
+ [Ejemplo: Adición de más de un ARN de pila a `aws:SourceArn`](#confused-deputy-opsworks-stacks-example2)
### Ejemplo: Acceso a pilas en una región específica
La siguiente declaración de relación de confianza entre roles permite acceder a todas las pilas de OpsWorks Stacks de la región EE.UU. Este (Ohio) (). `us-east-2` Tenga en cuenta que la región se especifica en el valor ARN de `aws:SourceArn`, pero el valor del ID de pila es un comodín (\$1).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "opsworks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:opsworks:us-east-2:123456789012:stack/*"
}
}
}
]
}
```
------
### Ejemplo: Adición de más de un ARN de pila a `aws:SourceArn`
El siguiente ejemplo limita el acceso a una matriz de dos pilas de OpsWorks Stacks en el ID de cuenta 123456789012.
# Especificar los permisos para las aplicaciones que se ejecutan en instancias EC2
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Si las aplicaciones que se ejecutan en las EC2 instancias de Amazon de su stack necesitan acceder a otros recursos de AWS, como los buckets de Amazon S3, deben tener los permisos adecuados. Para conceder estos permisos, utilice un perfil de instancia. Puedes especificar un perfil de instancia para cada instancia al [crear una pila de OpsWorks Stacks](workingstacks-creating.md).
![\[Opción avanzada de la página Add Stack.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/add-stack-instanceproflie.png)
También puede [editar la configuración de la capa](workinglayers-basics-edit.md) para especificar un perfil para las instancias de una capa.
El perfil de instancia especifica un rol de IAM. Las aplicaciones que se ejecutan en la instancia pueden asumir ese rol para obtener acceso a los recursos de AWS si la política de la función concede los permisos. Para obtener más información sobre cómo una aplicación asume un rol, consulte [Asumir un rol utilizando una llamada a la API](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-assume-role.html).
Puede crear un perfil de instancia de cualquiera de las siguientes formas:
+ Utilice la consola de IAM o la API para crear un perfil.
Para obtener más información, consulte la sección [Roles (Delegación y Federación)](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html).
+ Usa una CloudFormation plantilla para crear un perfil.
Para consultar algunos ejemplos sobre cómo incluir recursos de IAM en una plantilla, consulte [Fragmentos de código de plantillas de Identity and Access Management (IAM)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html).
Un perfil de instancia debe tener una relación de confianza y una política adjunta que conceda permisos para obtener acceso a los recursos de AWS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
El perfil de la instancia debe tener esta relación de confianza para que OpsWorks Stacks actúe en tu nombre. Si utiliza el rol de servicio predeterminado, no modifique la relación de confianza. Si crea un rol de servicio personalizado, especifique la relación de confianza de la siguiente manera:
+ Si utiliza el asistente **Create Role** de la [consola de IAM](https://console.aws.amazon.com/iam/home#roles), especifique el tipo de EC2 rol de **Amazon** en **AWS Service Roles** en la segunda página del asistente.
+ Si utiliza una CloudFormation plantilla, puede añadir algo como lo siguiente a la sección de **recursos** de la plantilla.
```
"Resources": {
"OpsWorksEC2Role": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "ec2.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
} ]
},
"Path": "/"
}
},
"RootInstanceProfile": {
"Type": "AWS::IAM::InstanceProfile",
"Properties": {
"Path": "/",
"Roles": [ {
"Ref": "OpsWorksEC2Role"
}
]
}
}
}
```
En el caso de que cree su propio perfil de instancia, puede adjuntar una política adecuada al rol del perfil en ese momento. Una vez que haya creado la pila, debe utilizar la [consola de IAM](https://console.aws.amazon.com/iam/) o la API para adjuntar una política adecuada al perfil del rol. Por ejemplo, la siguiente política concede acceso total a todos los objetos del bucket de Amazon S3 denominado amzn-s3-demo-bucket. Sustituya *region* y amzn-s3-demo-bucket por los valores adecuados a su configuración.
Para ver un ejemplo de cómo crear y utilizar un perfil de instancia, consulte [Uso de un bucket de Amazon S3](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted.walkthrough.photoapp.html).
Si tu aplicación usa un perfil de instancia para llamar a la API de OpsWorks Stacks desde una EC2 instancia, la política debe permitir la `iam:PassRole` acción además de las acciones apropiadas para OpsWorks Stacks y otros servicios de AWS. El permiso `iam:PassRole` permite a OpsWorks Stacks asumir el rol de servicio en su nombre. Para obtener más información sobre la API OpsWorks Stacks, consulte [AWS OpsWorks API Reference](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html).
El siguiente es un ejemplo de una política de IAM que te permite llamar a cualquier acción de OpsWorks Stacks desde una EC2 instancia, así como a cualquier acción de Amazon EC2 o Amazon S3.
**nota**
Si no lo permites`iam:PassRole`, cualquier intento de invocar una acción de OpsWorks Stacks fallará y generará un error como el siguiente:
```
User: arn:aws:sts::123456789012:federated-user/Bob is not authorized
to perform: iam:PassRole on resource:
arn:aws:sts::123456789012:role/OpsWorksStackIamRole
```
Para obtener más información sobre el uso de roles en una EC2 instancia para obtener permisos, consulte [Concesión de acceso a los recursos de AWS a las aplicaciones que se ejecutan en EC2 instancias de Amazon](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html) en la *Guía del AWS Identity and Access Management usuario*.
# Administración del acceso SSH
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
OpsWorks Stacks admite claves SSH para las pilas de Linux y Windows.
+ En el caso de Linux, puede utilizar SSH para iniciar sesión en una de sus instancias; por ejemplo, para ejecutar comandos de la [CLI de agente](agent.md).
Para obtener más información, consulte [Inicio de sesión con SSH](workinginstances-ssh.md).
+ Con instancias de Windows, puede utilizar una clave SSH para obtener la contraseña de administrador de la instancia, que después podrá utilizar para iniciar sesión con RDP.
Para obtener más información, consulte [Inicio de sesión con RDP](workinginstances-rdp.md).
La autenticación se basa en un par de claves SSH, que consta de una clave pública y otra privada:
+ Usted instala la clave pública en la instancia.
La ubicación depende del sistema operativo en particular, pero OpsWorks Stacks se encarga de los detalles por ti.
+ La clave privada se almacena localmente y se proporciona a un cliente SSH, como `ssh.exe`, para obtener acceso a la instancia.
El cliente SSH utiliza la clave privada para conectarse a la instancia.
Para proporcionar acceso SSH a los usuarios de una pila, necesita poder crear los pares de claves SSH, instalar las claves públicas en la pila y administrar de forma segura las claves privadas.
Amazon EC2 proporciona una forma sencilla de instalar una clave SSH pública en una instancia. Puede usar la EC2 consola o la API de Amazon para crear uno o más pares de claves para cada región de AWS que vaya a usar. Amazon EC2 almacena las claves públicas en AWS y usted almacena las claves privadas de forma local. Cuando lanzas una instancia, especificas uno de los pares de claves de la región y Amazon lo instala EC2 automáticamente en la instancia. A continuación, utilice la correspondiente clave privada para iniciar sesión en la instancia. Para obtener más información, consulte [Amazon EC2 Key Pairs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html).
Con OpsWorks Stacks, puedes especificar uno de los pares de EC2 claves de Amazon de la región al crear una pila y, si lo deseas, anularlo con un par de claves diferente al crear cada instancia. Cuando OpsWorks Stacks lanza la EC2 instancia de Amazon correspondiente, especifica el par de claves y Amazon EC2 instala la clave pública en la instancia. A continuación, puedes usar la clave privada para iniciar sesión o recuperar una contraseña de administrador, tal y como harías con una EC2 instancia estándar de Amazon. Para obtener más información, consulte [Instalación de una Amazon EC2 Key](security-settingec2key.md).
El uso de un EC2 key pair de Amazon es práctico, pero tiene dos limitaciones importantes:
+ Un par de EC2 claves de Amazon está vinculado a una región de AWS concreta.
Si trabaja en varias regiones, deberá administrar varios pares de claves.
+ Solo puedes instalar un par de EC2 claves de Amazon en una instancia.
Si desea permitir que varios usuarios inicien sesión, todos ellos deben tener una copia de la clave privada, lo cual no constituye una práctica de seguridad recomendada.
En el caso de las pilas de Linux, OpsWorks Stacks proporciona una forma más sencilla y flexible de gestionar los pares de claves SSH.
+ Cada usuario registra un par de claves personales.
Almacenan la clave privada de forma local y registran la clave pública en OpsWorks Stacks, tal y como se describe en. [Registro de la clave pública SSH de un usuario](security-settingsshkey.md)
+ Al configurar los permisos de usuario para una pila, debe especificar qué usuarios obtendrán acceso SSH a las instancias de la pila.
OpsWorks Stacks crea automáticamente un usuario del sistema en las instancias de la pila para cada usuario autorizado e instala su clave pública. Después, el usuario puede utilizar la clave privada correspondiente para iniciar sesión, como se describe en [Inicio de sesión con SSH](workinginstances-ssh.md).
La utilización de claves SSH personales presenta las ventajas siguientes.
+ No es necesario configurar manualmente las claves en las instancias; OpsWorks Stacks instala automáticamente las claves públicas correspondientes en cada instancia.
+ OpsWorks Stacks instala solo las claves públicas personales de los usuarios autorizados.
Los usuarios no autorizados no pueden utilizar su clave privada personal para obtener acceso a las instancias. Con los pares de EC2 claves de Amazon, cualquier usuario con la clave privada correspondiente puede iniciar sesión, con o sin acceso SSH autorizado.
+ Si un usuario ya no necesita acceso SSH, utilice la [página **Permissions (Permisos)**](opsworks-security-users-manage-edit.md) para revocar sus permisos SSH/RDP.
OpsWorks Stacks desinstala inmediatamente la clave pública de las instancias de la pila.
+ Puede utilizar la misma clave en cualquier región de AWS.
Los usuarios solo tienen que administrar una clave privada.
+ No es necesario compartir las claves privadas.
Cada usuario tiene su propia clave privada.
+ Es muy fácil rotar las claves.
Usted o el usuario actualiza la clave pública en **My Settings (Mi configuración)** y OpsWorks Stacks actualiza automáticamente las instancias.
# Instalación de una Amazon EC2 Key
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Al crear una pila, puede especificar una clave EC2 SSH de Amazon que se instala de forma predeterminada en todas las instancias de la pila.
![\[Lista de claves SSH predeterminadas de la página Agregar pila\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/ec2_keys.png)
La lista de **claves SSH predeterminadas** muestra el Amazon EC2keys de su cuenta de AWS. Puede elegir una de las opciones siguientes:
+ Seleccione la clave adecuada de la lista.
+ Seleccione **Do not use a default SSH key (No usar una clave SSH predeterminada)** para no especificar ninguna clave.
Si ha seleccionado **Do not use a default SSH key (No usar una clave SSH predeterminada)** o desea anular una clave predeterminada de pila, puede especificar una clave cuando cree una instancia.
![\[Especificar una clave SSH\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/instance_keys.png)
Al iniciar la instancia, OpsWorks Stacks instala la clave pública en el archivo. `authorized_keys`
# Registro de la clave pública SSH de un usuario
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Hay dos formas de registrar la clave SSH pública de un usuario:
+ Un administrador puede asignar una clave SSH pública a uno o varios usuarios y proporcionarles la correspondiente clave privada.
+ Un administrador puede habilitar la autogestión para uno o varios usuarios.
Estos usuarios pueden especificar sus propias claves SSH públicas.
Para obtener más información acerca de cómo pueden los administradores habilitar la autogestión o asignar claves públicas a los usuarios, consulte [Edición de la configuración de usuario](opsworks-security-users-manage-edit.md).
Para conectar a instancias basadas en Linux utilizando SSH en un terminal PuTTY es necesario realizar más pasos. Para obtener más información, consulte [Conexión a la instancia Linux desde Windows utilizando PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) y [Solución de problemas con la conexión a la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) en la documentación de AWS.
A continuación se describe cómo un usuario con autogestión habilitada puede especificar su clave pública.
**Para especificar una clave SSH pública**
1. Cree un par de claves SSH.
El modo más sencillo es generar el par de claves localmente. Para obtener más información, consulta [Cómo generar tu propia clave e importarla a Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/generating-a-keypair.html#how-to-generate-your-own-key-and-import-it-to-aws).
**nota**
Si usa Pu TTYgen para generar su par de claves, copie la clave pública de la clave pública **para pegarla en el cuadro de archivo authorized\$1keys de OpenSSH**. Al hacer clic en **Guardar clave pública**, se guarda la clave pública en un formato que no admite. MindTerm
1. Inicia sesión en la consola OpsWorks de Stacks como usuario de IAM con la autoadministración habilitada.
**importante**
**Si inicias sesión como propietario de una cuenta o como usuario de IAM que no tiene habilitada la autoadministración, OpsWorks Stacks no mostrará Mi configuración.** Si es usuario administrador o propietario de la cuenta, puede especificar las claves SSH yendo a la página **Users (Usuarios)** y [modificando la configuración del usuario](opsworks-security-users-manage-edit.md).
1. Seleccione **Mi configuración**, que muestra la configuración del usuario que ha iniciado sesión.
![\[El enlace Mi configuración está en el panel de control. OpsWorks\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/permissions-mysettings-link.png)
1. En la página **My Settings (Mi configuración)**, haga clic en **Edit (Editar)**.
![\[Botón Edit en la página My Settings.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/mysettings-editbutton.png)
1. En el **Public SSH Key box (Cuadro de clave SSH pública)**, escriba su clave pública SSH y, a continuación, haga clic en **Save (Guardar)**.
![\[Cuadro de clave SSH pública en la página My Settings.\]](http://docs.aws.amazon.com/es_es/opsworks/latest/userguide/images/mysettings-setsshkey.png)
**importante**
Para usar el cliente MindTerm SSH integrado para conectarse a las EC2 instancias de Amazon, el usuario debe iniciar sesión como usuario de IAM y tener una clave SSH pública registrada en Stacks. OpsWorks Para obtener más información, consulte [Uso del cliente SSH integrado MindTerm](workinginstances-ssh-mindterm.md).
# Administración de actualizaciones de seguridad de Linux
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los actuales. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
## Actualizaciones de seguridad
Los proveedores de sistemas operativos Linux proporcionan actualizaciones periódicas, que en su mayoría son parches de seguridad del sistema operativo, aunque también pueden incluir actualizaciones de los paquetes instalados. Debe asegurarse de que los sistemas operativos de sus instancias estén actualizados con los parches de seguridad más recientes.
De forma predeterminada, OpsWorks Stacks instala automáticamente las actualizaciones más recientes durante la configuración, cuando la instancia termina de arrancar. OpsWorks Stacks no instala las actualizaciones automáticamente una vez que la instancia está en línea, para evitar interrupciones como el reinicio de los servidores de aplicaciones. En cambio, puesto que usted gestiona las actualizaciones de sus instancias online, puede minimizar cualquier interrupción.
Le recomendamos que realice una de las siguientes acciones para actualizar sus instancias online.
+ Cree e inicie las instancias nuevas para sustituir sus instancias online actuales. A continuación, elimine las instancias actuales.
Las instancias nuevas dispondrán del conjunto de parches de seguridad más reciente instalado durante la configuración.
+ En instancias basadas en Linux, en pilas de Chef 11.10 o más antiguas, ejecute el [comando de pila Update Dependencies](workingstacks-commands.md), que instala el conjunto de parches de seguridad actual y otras actualizaciones en las instancias especificadas.
Para ambos enfoques, OpsWorks Stacks realiza la actualización ejecutándola `yum update` para Amazon Linux y Red Hat Enterprise Linux (RHEL) o `apt-get update` para Ubuntu. Cada distribución gestiona las actualizaciones de forma diferente, por lo que debería examinar la información de los vínculos asociados para comprender exactamente cómo afecta una actualización a las instancias:
+ **Amazon Linux**: las actualizaciones de Amazon Linux instalan parches de seguridad y, además, pueden instalar nuevas características, incluidas las actualizaciones de paquete.
Para obtener más información, consulte [AMI de Amazon Linux FAQs](https://aws.amazon.com/amazon-linux-ami/faqs/#lock).
+ **Ubuntu**: las actualizaciones de Ubuntu están muy limitadas a la instalación de parches de seguridad, aunque también podrían instalar actualizaciones de paquete para un número limitado de correcciones críticas.
Para obtener más información, consulte [LTS - Ubuntu Wiki](https://wiki.ubuntu.com/LTS).
+ **CentOS**: las actualizaciones de CentOS, por lo general, mantienen una compatibilidad binaria con versiones anteriores.
+ **RHEL**: las actualizaciones de RHEL, por lo general, mantienen una compatibilidad binaria con versiones anteriores.
Para obtener más información, consulte [Red Hat Enterprise Linux Life Cycle](https://access.redhat.com/support/policy/updates/errata/).
Si desea tener más control sobre las actualizaciones, por ejemplo, especificar versiones de paquetes concretas, puede deshabilitar las actualizaciones automáticas mediante las [UpdateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateLayer.html)acciones [CreateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateInstance.html),, [UpdateInstance[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateInstance.html), o los métodos equivalentes del [SDK de AWS](https://aws.amazon.com/tools/) o los comandos de la [CLI](https://aws.amazon.com/documentation/cli/) de AWS, para establecer el parámetro. `InstallUpdatesOnBoot` `false` El siguiente ejemplo muestra cómo utilizar la CLI de AWS para desactivar `InstallUpdatesOnBoot` como la configuración predeterminada de una capa existente.
```
aws opsworks update-layer --layer-id layer ID --no-install-updates-on-boot
```
Después deberá administrar las actualizaciones usted mismo. Por ejemplo, puede utilizar una de estas estrategias:
+ Implementar una receta personalizada que [ejecute el comando shell adecuado](cookbooks-101-basics-commands.md#cookbooks-101-basics-commands-script) para instalar sus actualizaciones preferidas.
Dado que las actualizaciones del sistema no se mapean de forma natural con un [evento del ciclo de vida](workingcookbook-events.md), incluya la receta en los libros de recetas personalizados y [ejecútela manualmente](workingcookbook-manual.md). Para actualizaciones de paquete, también puede utilizar los recursos [yum\$1package](https://docs.chef.io/chef/resources.html#yum-package) (Amazon Linux) o [apt\$1package](https://docs.chef.io/chef/resources.html#apt-package) (Ubuntu) en lugar de un comando shell.
+ [Inicie sesión en cada instancia con SSH](workinginstances-ssh.md) y ejecute los comandos adecuados manualmente.
# Uso de grupos de seguridad
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
## Grupos de seguridad
**importante**
El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los actuales. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).
Cada EC2 instancia de Amazon tiene uno o más grupos de seguridad asociados que controlan el tráfico de red de la instancia, de forma muy parecida a un firewall. Un grupo de seguridad tiene una o varias *reglas* y cada una de ellas designa una categoría determinada de tráfico permitido. Una regla especifica los elementos siguientes:
+ El tipo de tráfico permitido, como SSH o HTTP.
+ El protocolo del tráfico, como TCP o UDP.
+ El rango de direcciones IP de donde puede provenir el tráfico.
+ El rango de puertos permitidos para el tráfico.
Los grupos de seguridad tienen dos tipos de reglas:
+ Las reglas de entrada que regulan el tráfico de red entrante.
Por ejemplo, las instancias de servidor de aplicaciones suelen tener una regla de entrada que permite el tráfico HTTP de entrada proveniente de cualquier dirección IP al puerto 80, y otra regla de entrada que permite el tráfico SSH proveniente de un conjunto de direcciones IP especificado al puerto 22.
+ Las reglas de salida regulan el tráfico de red de salida.
Una práctica habitual consiste en utilizar la configuración predeterminada, que permite todo el tráfico de salida.
Para obtener más información sobre los grupos de seguridad, consulte [Amazon EC2 Security Groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html).
La primera vez que crea una pila en una región, OpsWorks Stacks crea un grupo de seguridad integrado para cada capa con un conjunto de reglas adecuado. Todos los grupos tienen reglas de salida predeterminadas que permiten todo el tráfico de salida. En general, las reglas de entrada permiten lo siguiente:
+ Tráfico TCP, UDP e ICMP entrante desde las capas de Stacks correspondientes OpsWorks
+ Tráfico TCP de entrada en el puerto 22 (inicio de sesión SSH)
**aviso**
La configuración predeterminada del grupo de seguridad abre SSH (puerto 22) a cualquier ubicación de red (0.0.0.0/0). Esto permite que todas las direcciones IP tengan acceso a su instancia mediante SSH. Para los entornos de producción, debe utilizar una configuración que solo permita el acceso SSH desde una dirección o un rango de direcciones IP específico. Actualice los grupos de seguridad predeterminados inmediatamente después de crearlos o bien utilice grupos de seguridad personalizados.
+ Para las capas de servidor web, todo el tráfico de entrada TCP y UDP a los puertos 80 (HTTP) y 443 (HTTPS)
**nota**
El grupo de seguridad `AWS-OpsWorks-RDP-Server` integrado se asigna a todas las instancias de Windows para permitir el acceso RDP. Sin embargo, de forma predeterminada, no tiene ninguna regla. Si ejecuta una pila de Windows y quiere utilizar RDP para obtener acceso a las instancias, debe añadir una regla de entrada que permita el acceso RDP. Para obtener más información, consulte [Inicio de sesión con RDP](workinginstances-rdp.md).
Para ver los detalles de cada grupo, ve a la [ EC2consola de Amazon](https://console.aws.amazon.com/ec2/), selecciona **Grupos de seguridad** en el panel de navegación y selecciona el grupo de seguridad de la capa correspondiente. Por ejemplo, **AWS- OpsWorks -Default-Server** es el grupo de seguridad integrado predeterminado para todas las pilas y **AWS OpsWorks - WebApp** es el grupo de seguridad integrado predeterminado para la pila de muestras de Chef 12.
**nota**
Si eliminas accidentalmente un grupo de seguridad de OpsWorks Stacks, la forma preferida de volver a crearlo es hacer que OpsWorks Stacks realice la tarea por ti. Solo tiene que crear una pila nueva en la misma región de AWS (y en la VPC, si existe OpsWorks ) y Stacks volverá a crear automáticamente todos los grupos de seguridad integrados, incluido el que haya eliminado. Después podrá borrar la pila si ya no la va a usar más; los grupos de seguridad permanecerán. Si quiere volver a crear el grupo de seguridad manualmente, tiene que ser un duplicado exacto del original, incluidas las mayúsculas y minúsculas del nombre de grupo.
Además, OpsWorks Stacks intentará volver a crear todos los grupos de seguridad integrados si ocurre alguna de las siguientes situaciones:
Haces cualquier cambio en la página de configuración de la pila en la consola de OpsWorks Stacks.
Si inicia una de las instancias de la pila.
Si crea una pila nueva.
Puede utilizar cualquiera de los enfoques siguientes para especificar grupos de seguridad. Al crear una pila, **utilizas la opción Usar grupos de OpsWorks seguridad** para especificar tus preferencias.
+ **Sí** (configuración predeterminada): OpsWorks Stacks asocia automáticamente el grupo de seguridad integrado correspondiente a cada capa.
Puede ajustar el grupo de seguridad integrado de una capa añadiendo un grupo de seguridad personalizado con su configuración preferida. Sin embargo, cuando Amazon EC2 evalúa varios grupos de seguridad, utiliza las reglas menos restrictivas, por lo que no puede utilizar este enfoque para especificar reglas más restrictivas que las del grupo integrado.
+ **No**, OpsWorks Stacks no asocia los grupos de seguridad integrados a las capas.
Debe crear grupos de seguridad adecuados y asociar al menos uno a cada capa que cree. Utilice este enfoque para especificar reglas más restrictivas que las de los grupos integrados. Tenga en cuenta que sigue teniendo la opción de asociar manualmente un grupo de seguridad integrado a una capa si así lo prefiere; los grupos de seguridad personalizados son necesarios solo para las capas que necesitan una configuración personalizada.
**importante**
Si utiliza los grupos de seguridad integrados, no puede crear reglas más restrictivas modificando manualmente la configuración del grupo. Cada vez que creas una pila, OpsWorks Stacks sobrescribe las configuraciones de los grupos de seguridad integrados, por lo que cualquier cambio que realices se perderá la próxima vez que crees una pila. Si una capa requiere una configuración de grupos de seguridad más restrictiva que el grupo de seguridad integrado, establece **Usar grupos de OpsWorks seguridad** en **No**, crea grupos de seguridad personalizados con tu configuración preferida y asígnalos a las capas al crearlos.