Información sobre detalles técnicos acerca de SSM Agent

Utilice la información de este tema para implementar AWS Systems Manager Agent (SSM Agent) y entender cómo funciona.

Temas

• Comportamiento de las credenciales de la versión 3.2.x.x de SSM Agent
• Prioridad de credenciales de SSM Agent
• Acerca de la cuenta ssm-user local
• SSM Agent y Instance Metadata Service (IMDS)
• Mantener el SSM Agent actualizado
• Ratificación de que el directorio de instalación de SSM Agent no se modifique, mueva o elimine
• Actualizaciones continuas de SSM Agent por Regiones de AWS
• Comunicaciones de SSM Agent con buckets de S3 administrados de AWS
• Búsqueda de AMIs con SSM Agent preinstalado
• Uso de SSM Agent en instancias de EC2 para Linux
• Uso de SSM Agent en instancias de EC2 para macOS
• Uso de SSM Agent en instancias de EC2 para Windows Server
• Verificación del estado de SSM Agent e inicio del agente
• Verificación del número de versión de SSM Agent
• Visualización de registros de SSM Agent
• Restricción del acceso a los comandos de nivel raíz con SSM Agent
• Automatización de las actualizaciones de SSM Agent
• Suscripción a las notificaciones de SSM Agent

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 los dispositivos periféricos para que utilicen el software AWS IoT Greengrass Core, configurar un rol de servicio de AWS Identity and Access Management (IAM) e implementar SSM Agent en los dispositivos mediante AWS IoT Greengrass. Para obtener más información, consulte Administración de dispositivos periféricos con Systems Manager.

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 de AWS Identity and Access Management (IAM) para tareas en caso de que haya una aplicación que utilice una definición de tarea de Amazon Elastic Container Service (Amazon ECS) o una operación RunTask de la API

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:

• Perfiles de instancia para instancias de EC2: Configuración de permisos de instancia requeridos para Systems Manager

• Activaciones híbridas: Creación de una activación híbrida para registrar nodos con Systems Manager

• Credenciales de la AWS CLI: ajustes de los archivos de credenciales y configuración en la Guía del usuario de la AWS Command Line Interface

• Cadena predeterminada de proveedores de credenciales: Especificación de credenciales en la Guía para desarrolladores de AWS SDK for Go

  nota

  Este tema de la Guía para desarrolladores de AWS SDK for Go describe la cadena predeterminada de proveedores en términos del SDK para Go. Sin embargo, los mismos principios se aplican a la evaluación de las credenciales de SSM Agent.

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. ssm-user es el usuario de SO predeterminado cuando se inicia una sesión en Session 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 Metadatos de instancia y datos de usuario en la Guía del usuario de Amazon EC2.

Mantener el SSM Agent actualizado

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 SSM Agent Release Notes en GitHub para recibir notificaciones sobre las actualizaciones de SSM Agent.

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 SSM Agent Release Notes en GitHub para recibir notificaciones sobre las actualizaciones de SSM Agent.

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.

Actualizaciones continuas de SSM Agent por Regiones de AWS

Después de que una actualización de SSM Agent está disponible en su repositorio de GitHub, la implementación de la versión actualizada en todas las Regiones de AWS en diferentes momentos puede demorar hasta dos semanas. Por este motivo, es posible que reciba un error del tipo “No compatible en la plataforma actual” o “actualizando amazon-ssm-agent a una versión anterior; permita la opción para volver a una versión anterior para continuar” cuando intente implementar una nueva versión de SSM Agent en una 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.

Comunicaciones de SSM Agent con buckets de S3 administrados de AWS

En el curso de la realización de diversas operaciones de Systems Manager, AWS Systems Manager Agent (SSM Agent) accede a varios buckets de Amazon Simple Storage Service (Amazon S3). Se puede acceder públicamente a estos buckets de S3 y, de forma predeterminada, SSM Agent se conecta a ellos a través de llamadas a HTTP.

Sin embargo, si utiliza un punto de conexión de nube privada virtual (VPC) en las operaciones de Systems Manager, debe conceder un permiso explícito en un perfil de instancia de Amazon Elastic Compute Cloud (Amazon EC2) para Systems Manager o en un rol de servicio para equipos que no sean de EC2 en un entorno híbrido y multinube. De lo contrario, sus recursos no puede acceder a estos buckets públicos.

Para otorgar a sus nodos administrados acceso a estos buckets cuando se utiliza un punto de conexión de VPC, cree una política de permisos de Amazon S3 personalizada y luego, adjúntela al perfil de instancia (para instancias de EC2) o al rol de servicio (para nodos administrados que no sean de EC2).

Para obtener información sobre el uso de un punto de conexión de nube privada virtual (VPC) en las operaciones de Systems Manager, consulte Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager.

nota

Estos permisos tan solo proporcionan acceso a los bukets administrados de AWS solicitados por SSM Agent. No conceden los permisos necesarios para otras operaciones de Amazon S3. Tampoco concede permiso para sus propios buckets de S3.

Para obtener más información, consulte los temas siguientes:

• Configuración de permisos de instancia requeridos para Systems Manager

• Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube

Permisos de bucket necesarios

En la siguiente tabla, se describe cada uno de los buckets de S3 a los que SSM Agent puede necesitar acceder para las operaciones de Systems Manager.

nota

region representa el identificador de una Región de AWS compatible con AWS Systems Manager, como us-east-2 para la región EE. UU. Este (Ohio). Para ver una lista de los valores de regiones admitidos, consulte la columna Región en Puntos de conexión de servicio de Systems Manager en la Referencia general de Amazon Web Services.

Los permisos de Amazon S3 que necesita SSM Agent

ARN del bucket de S3	Descripción
arn:aws:s3:::aws-windows-downloads-region/*	Necesario para algunos documentos SSM que solo admiten sistemas operativos Windows Server y para algunos documentos para la compatibilidad entre plataformas, como AWSEC2-ConfigureSTIG.
arn:aws:s3:::amazon-ssm-region/*	Se necesita para actualizar las instalaciones del SSM Agent. Estos buckets contienen los paquetes de instalación del SSM Agent y los manifiestos de instalación a los que se hace referencia en el complemento y documento AWS-UpdateSSMAgent. Si no se proporcionan estos permisos, SSM Agent realiza una llamada HTTP para descargar la actualización.
arn:aws:s3:::amazon-ssm-packages-region/*	Se necesita para utilizar versiones de SSM Agent anteriores a la 2.2.45.0 para ejecutar el documento de SSM AWS-ConfigureAWSPackage.
arn:aws:s3:::region-birdwatcher-prod/*	Proporciona acceso al servicio de distribución utilizado por la versión 2.2.45.0 y posteriores del SSM Agent. Este servicio se utiliza para ejecutar el documento AWS-ConfigureAWSPackage. Este permiso es necesario para todas las Regiones de AWS excepto la región África (Ciudad del Cabo) (af-south-1) y la región Europa (Milán) (eu-south-1).
arn:aws:s3:::aws-ssm-distributor-file-region/*	Proporciona acceso al servicio de distribución utilizado por la versión 2.2.45.0 y posteriores del SSM Agent. Este servicio se utiliza para ejecutar el documento de SSM AWS-ConfigureAWSPackage. Este permiso es necesario solo para las regiones África (Ciudad del Cabo) (af-south-1) y Europa (Milán) (eu-south-1).
arn:aws:s3:::aws-ssm-document-attachments-region/*	Proporciona acceso al bucket de S3 que incluye los paquetes deDistributor, una capacidad de AWS Systems Manager, que son propiedad de AWS.
arn:aws:s3:::patch-baseline-snapshot-region/*	Proporciona acceso al bucket de S3 que incluye las instantáneas de las líneas de base de revisiones. Es necesario si utiliza cualquiera de los siguientes documentos de SSM: AWS-RunPatchBaseline AWS-RunPatchBaselineAssociation AWS-RunPatchBaselineWithHooks AWS-ApplyPatchBaseline (un documento de SSM heredado) nota Solo en la región Medio Oriente (Baréin) (me-south-1), estos buckets de S3 utilizan convenciones de nomenclatura diferentes. Solo en esta Región de AWS, utilice el siguiente bucket en su lugar. patch-baseline-snapshot-me-south-1-uduvl7q8 Solo en la región África (Ciudad del Cabo) (af-south-1), este bucket de S3 utiliza una convención de nomenclatura diferente. Solo en esta Región de AWS, utilice el siguiente bucket en su lugar. patch-baseline-snapshot-af-south-1-tbxdb5b9
Para nodos administrados de Linux y Windows Server: arn:aws:s3:::aws-ssm-region/* En instancias de Amazon EC2 para macOS: arn:aws:s3:::aws-patchmanager-macos-region/*	Proporciona acceso al bucket de S3 que incluye los módulos que es necesario utilizar con ciertos documentos de Systems Manager (documentos de SSM). Por ejemplo: arn:aws:s3:::aws-ssm-us-east-2/* aws-patchmanager-macos-us-east-2/* Excepciones En algunas Regiones de AWS, los nombres del bucket de S3 utilizan una convención de nomenclatura extendida, como se muestra en sus ARN. En estas regiones, utilice los siguientes ARN en su lugar: Región Medio Oriente (Baréin) (me-south-1): aws-patch-manager-me-south-1-a53fc9dce Región África (Ciudad del Cabo) (af-south-1): aws-patch-manager-af-south-1-bdd5f65a9 Región Europa (Milán) (eu-south-1): aws-patch-manager-eu-south-1-c52f3f594 Asia Pacífico (Osaka) (ap-northeast-3): aws-patch-manager-ap-northeast-3-67373598a Documentos de SSM Estos son algunos documentos de SSM que suelen utilizarse y que se almacenan en estos buckets. En arn:aws:s3:::aws-ssm-region/: AWS-RunPatchBaseline AWS-RunPatchBaselineAssociation AWS-RunPatchBaselineWithHooks AWS-InstanceRebootWithHooks AWS-ConfigureWindowsUpdate AWS-FindWindowsUpdates AWS-PatchAsgInstance AWS-PatchInstanceWithRollback AWS-UpdateSSMAgent AWS-UpdateEC2Config En arn:aws:s3:::aws-patchmanager-macos-region/: AWS-RunPatchBaseline AWS-RunPatchBaselineAssociation AWS-RunPatchBaselineWithHooks AWS-InstanceRebootWithHooks AWS-PatchAsgInstance AWS-PatchInstanceWithRollback

Ejemplo

En el siguiente ejemplo se muestra cómo proporcionar acceso a los buckets de S3 necesarios para las operaciones de Systems Manager en la región EE. UU. Este (Ohio) (us-east-2). En la mayoría de los casos, debe proporcionar estos permisos de forma explícita en un perfil de instancias o un rol de servicio solo cuando se utiliza un punto de enlace de la VPC.

importante

Recomendamos que evite el uso de caracteres comodín (*) en lugar de regiones específicas en esta política. Por ejemplo, utilice arn:aws:s3:::aws-ssm-us-east-2/* y no arn:aws:s3:::aws-ssm-*/*. El uso de caracteres comodín podría conceder acceso a buckets de S3 a los que no quiere darlo. Si desea utilizar el perfil de instancia para más de una región, le recomendamos repetir el primer bloque de Statement de cada región.

{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "s3:GetObject",
                "Resource": [
                    "arn:aws:s3:::aws-windows-downloads-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
                    "arn:aws:s3:::us-east-2-birdwatcher-prod/*",
                    "arn:aws:s3:::aws-ssm-document-attachments-us-east-2/*",
                    "arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
                    "arn:aws:s3:::aws-ssm-us-east-2/*",
                    "arn:aws:s3:::aws-patchmanager-macos-us-east-2/*"
                ]
            }
        ]
    }

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 equipos Windows Server 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 del SSM Agent está disponible en GitHub para que pueda 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.