Referencias técnicas de SSM Agent - AWS Systems Manager

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.

Referencias técnicas de SSM Agent

Utilice la información de este tema como ayuda para implementar AWS Systems Manager Agent (SSM Agent) y comprender cómo funciona el agente.

Comportamiento de las credenciales de la versión 3.2.x.x de SSM Agent

SSM Agent almacena un conjunto de credenciales temporales en /var/lib/amazon/ssm/credentials (para Linux y macOS) o %PROGRAMFILES%\Amazon\SSM\credentials (para Windows Server) cuando se incorpora una instancia mediante la configuración de administración de host predeterminada en Quick Setup. Las credenciales temporales tienen los permisos que usted especifique para el rol de IAM que eligió para la configuración de administración de host predeterminada. En Linux, solo la cuenta raíz puede acceder a estas credenciales. En Windows Server, solo la cuenta SYSTEM y los administradores locales pueden acceder a estas credenciales.

Prioridad de credenciales de SSM Agent

En este tema se describe información importante acerca de cómo SSM Agent tiene permiso para realizar acciones en los recursos.

nota

La compatibilidad con los dispositivos periféricos difiere ligeramente. Debe configurar sus dispositivos perimetrales para que utilicen el software AWS IoT Greengrass Core, configurar un rol de servicio AWS Identity and Access Management (IAM) e SSM Agent implementarlos en sus dispositivos mediante AWS IoT Greengrass el uso de. Para obtener más información, consulte Configuración de AWS Systems Manager para dispositivos de borde.

Cuando SSM Agent está instalado en un equipo, requiere permisos para comunicarse con el servicio de Systems Manager. En las instancias de Amazon Elastic Compute Cloud (Amazon EC2), estos permisos se proporcionan en un perfil de instancias que está adjunto a la instancia. En un equipo que no es de EC2, por lo general SSM Agent obtiene los permisos necesarios del archivo de credenciales compartidas, ubicado en /root/.aws/credentials (Linux y macOS) o %USERPROFILE%\.aws\credentials (Windows Server). Los permisos necesarios se agregan a este archivo durante el proceso de activación híbrida.

Sin embargo, en raras ocasiones, es posible que un equipo tenga permisos agregados en más de una de las ubicaciones donde SSM Agent verifica los permisos para ejecutar sus tareas.

Por ejemplo, supongamos que configuró una instancia de EC2 para que la administre Systems Manager. Esa configuración incluye que se adjunte un perfil de instancia. Luego usted decide si usar también esa instancia para tareas de desarrollador o de usuario final e instalar la AWS Command Line Interface (AWS CLI) en ella. Como resultado de esta instalación, se agregan permisos adicionales a un archivo de credenciales en la instancia.

Cuando ejecuta un comando de Systems Manager en la instancia, SSM Agent podría intentar usar credenciales diferentes de las que se espera que use, como de un archivo de credenciales en lugar de un perfil de instancias. Esto se debe a que SSM Agent busca las credenciales en el orden prescrito para la cadena predeterminada de proveedores de credenciales.

nota

En Linux y macOS, SSM Agent se ejecuta como el usuario raíz. Por lo tanto, las variables de entorno y el archivo de credenciales que busca SSM Agent en este proceso son solo las del usuario raíz (/root/.aws/credentials). Durante la búsqueda de credenciales, SSM Agent no busca las variables de entorno o el archivo de credenciales de ningún otro usuario en la instancia.

La cadena predeterminada de proveedores busca las credenciales en el orden indicado a continuación:

  1. variables de entorno, si se han configurado (AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY)

  2. archivo de credenciales compartidas ($HOME/.aws/credentials para Linux y macOS o %USERPROFILE%\.aws\credentials para Windows Server) con permisos proporcionados, por ejemplo, por una activación híbrida o una instalación de la AWS CLI

  3. Un rol AWS Identity and Access Management (IAM) para las tareas si hay una aplicación presente que utiliza una definición RunTask de tarea o una operación de API de Amazon Elastic Container Service (Amazon ECS).

  4. un perfil de instancias adjunto a una instancia de Amazon EC2

  5. El rol de IAM elegido para la configuración de administración de host predeterminada.

Para obtener información relacionada, consulte los siguientes temas:

Acerca de la cuenta ssm-user local

A partir de la versión 2.3.50.0 de SSM Agent, el agente crea una cuenta de usuario local denominada ssm-user y la agrega al directorio /etc/sudoers.d (Linux y macOS) o al grupo de administradores (Windows Server). En las versiones del agente anteriores a la 2.3.612.0, la cuenta se crea la primera vez que se inicia SSM Agent o al reiniciar después de la instalación. En la versión 2.3.612.0 y posteriores, la cuenta ssm-user se crea la primera vez que se inicia una sesión en una instancia. Este ssm-user es el usuario predeterminado del sistema operativo cuando se inicia una sesiónSession Manager, una capacidad de AWS Systems Manager. Puede cambiar los permisos al trasladar la cuenta ssm-user a un grupo con menos privilegios o al cambiar el archivo sudoers. La cuenta ssm-user no se elimina del sistema cuando se desinstala SSM Agent.

En Windows Server, SSM Agent controla la configuración de una nueva contraseña para la cuenta ssm-user cada vez que se inicia una sesión. No se establecen contraseñas para ssm-user en las instancias administradas de Linux.

A partir de la versión 2.3.612.0 de SSM Agent, la cuenta ssm-user no se crea de forma automática en equipos Windows Server que se utilizan como controladores de dominio. Para utilizar Session Manager en un controlador de dominio de Windows Server, cree la cuenta ssm-user de forma manual si ella aún no está presente y asigne permisos de administrador de dominio al usuario.

importante

Para que se cree la cuenta ssm-user, el perfil de instancia asociado a la instancia debe proporcionar los permisos necesarios. Para obtener información, consulte el Paso 2: verificar o agregar permisos de instancia para Session Manager.

SSM Agent y Instance Metadata Service (IMDS)

Systems Manager utiliza metadatos de las instancias EC2 para funcionar de forma correcta. Systems Manager puede acceder a los metadatos de las instancias con la versión 1 o la versión 2 de Instance Metadata Service (IMDSv1 y IMDSv2). La instancia debe poder acceder a la dirección IPv4 del servicio de metadatos de la instancia: 169.254.169.254. Para obtener más información, consulte Datos de usuario y metadatos de instancia en la Guía del usuario de instancias de Linux de Amazon EC2.

Manteniendo SSM Agent up-to-date

Cada vez que se agregan capacidades nuevas a Systems Manager o se actualizan las capacidades existentes, se lanza una versión actualizada de SSM Agent. No utilizar la versión más reciente del agente puede impedir que el nodo administrado utilice diversas capacidades y características de Systems Manager. Por este motivo, se recomienda automatizar el proceso de mantener SSM Agent actualizado en los equipos. Para obtener más información, consulte Automatización de las actualizaciones de SSM Agent. Suscríbase a la página de notas de la SSM Agent versión GitHub para recibir notificaciones sobre SSM Agent las actualizaciones.

nota

Cada vez que se agregan capacidades nuevas a Systems Manager o se actualizan las capacidades existentes, se lanza una versión actualizada de SSM Agent. No utilizar la versión más reciente del agente puede impedir que el nodo administrado utilice diversas capacidades y características de Systems Manager. Por este motivo, se recomienda automatizar el proceso de mantener SSM Agent actualizado en los equipos. Para obtener más información, consulte Automatización de las actualizaciones de SSM Agent. Suscríbase a la página de notas de la SSM Agent versión GitHub para recibir notificaciones sobre SSM Agent las actualizaciones.

Las Amazon Machine Images (AMIs) que incluyen SSM Agent de forma predeterminada, pueden tardar hasta dos semanas en disponer de la versión más reciente de SSM Agent. Le recomendamos que configure las actualizaciones automáticas de SSM Agent con una mayor frecuencia.

Ratificación de que el directorio de instalación de SSM Agent no se modifique, mueva o elimine

SSM Agent está instalado en /var/lib/amazon/ssm/ (Linux y macOS) y %PROGRAMFILES%\Amazon\SSM\ (Windows Server). Estos directorios de instalación contienen archivos y carpetas críticos que se utilizan por SSM Agent, como un archivo de credenciales, recursos para la comunicación entre procesos (IPC) y carpetas de orquestación. No se debe modificar, mover ni eliminar nada dentro del directorio de instalación. De lo contrario, SSM Agent podría dejar de funcionar correctamente.

SSM Agentactualizaciones continuas por Regiones de AWS

Una vez que una SSM Agent actualización esté disponible en su GitHub repositorio, pueden pasar hasta dos semanas hasta que la versión actualizada esté disponible para todos Regiones de AWS en diferentes momentos. Por este motivo, es posible que recibas el mensaje de error «No es compatible con la plataforma actual» o «si estás actualizando amazon-ssm-agent a una versión anterior, por favor, activa la opción para continuar con la degradación» cuando intentes implementar una nueva versión de una SSM Agent región.

Para determinar la versión de SSM Agent a la que pueda acceder, puede ejecutar un comando curl.

Para ver la versión del agente disponible en el bucket de descarga global, ejecute el siguiente comando.

curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION

Para ver la versión del agente disponible en una región específica, ejecute el siguiente comando y sustituya la region con la región en la que está trabajando, como us-east-2 para la región EE. UU. Este (Ohio).

curl https://s3.region.amazonaws.com/amazon-ssm-region/latest/VERSION

También puede abrir el archivo VERSION directamente en su navegador sin un comando curl.

Instalación de SSM Agent en VM e instancias locales

Para obtener información sobre la instalación de SSM Agent en equipos que no sean de EC2 para un entorno híbrido y multinube, consulte Instalación de SSM Agent para un entorno híbrido (Linux) e Instalación de SSM Agent para un entorno híbrido (Windows).

Validación de equipos activados de manera híbrida mediante una huella digital de hardware

Cuando se trata de equipos que no son de EC2 en un entorno híbrido y multinube, SSM Agent recopila una serie de atributos del sistema (denominados como hash de hardware) y utiliza estos atributos para calcular una huella digital. La huella digital es una cadena opaca que el agente envía a determinadas API de Systems Manager. Esta huella digital única asocia a la persona que llama con un nodo administrado activado de manera híbrida en particular. El agente almacena la huella digital y el hash de hardware en el disco local en una ubicación denominada el Almacén.

El agente calcula el hash de hardware y la huella digital cuando el equipo se registra para su uso con Systems Manager. Luego, la huella digital se envía de nuevo al servicio de Systems Manager cuando el agente envía un comando RegisterManagedInstance.

Más tarde, al momento de enviar un comando RequestManagedInstanceRoleToken, el agente verifica la huella digital y el hash de hardware en el almacén para asegurarse de que los atributos de la máquina actual coincidan con el hash de hardware almacenado. Si los atributos de la máquina actual coinciden con el hash de hardware guardado en el almacén, el agente envía la huella digital del almacén a RegisterManagedInstance, lo que resulta en una llamada exitosa.

Si los atributos de la máquina actual no coinciden con el hash de hardware almacenado, SSM Agent calcula una nueva huella digital, almacena los nuevos hash de hardware y huella digital en el almacén, y envía la nueva huella digital a RequestManagedInstanceRoleToken. Esto provoca que se produzca un error con RequestManagedInstanceRoleToken, por lo que el agente no podrá obtener un token de rol para conectarse al servicio de Systems Manager.

Este error es intencional y se utiliza como paso de verificación para evitar que varios nodos administrados se comuniquen con el servicio de Systems Manager como el mismo nodo administrado.

Cuando compara los atributos de la máquina actual con el hash de hardware guardado en el almacén, el agente utiliza la siguiente lógica para determinar si los hash antiguos y los nuevos coinciden:

  • Si el SID (ID del sistema/máquina) es diferente, no hay coincidencia.

  • Pero si la dirección IP es la misma, entonces coinciden.

  • De lo contrario, el porcentaje de atributos de las máquinas que coinciden se calcula y se compara con el límite de similitud que configuró el usuario para determinar si hay una coincidencia.

El límite de similitud se guarda en el almacenamiento, como parte del hash de hardware.

El límite de similitud se puede establecer después de registrar una instancia mediante un comando como el siguiente.

En equipos Linux:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

En Windows Server máquinas que utilizan: PowerShell

cd "C:\Program Files\Amazon\SSM\" ` .\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1
importante

El hecho de que uno de los componentes utilizados para calcular la huella digital cambie puede producir que el agente hiberne. Para evitar esta hibernación, establezca el límite de similitud en un valor bajo, como 1.

SSM Agent del GitHub

El código fuente SSM Agent está disponible para que GitHubpueda adaptar el agente a sus necesidades. Le recomendamos enviar solicitudes de inserción para los cambios que le gustaría que incluyamos. No obstante, Amazon Web Services no admite la ejecución de copias modificadas de este software.