Scopri i dettagli tecnici sull'SSM Agent

Utilizzare le informazioni in questo argomento per poter implementare l'Agente di AWS Systems Manager (SSM Agent) e capire come funziona l'agente.

Comportamento delle credenziali di SSM Agent versione 3.2.x.x

SSM Agent memorizza un set di credenziali temporanee in /var/lib/amazon/ssm/credentials (per Linux e macOS) o %PROGRAMFILES%\Amazon\SSM\credentials (per Windows Server) quando si esegue l'onboarding di un'istanza utilizzando la funzionalità Configurazione di gestione host predefinita in Quick Setup. Le credenziali temporanee dispongono delle autorizzazioni specificate per il ruolo IAM scelto per la funzionalità Configurazione gestione host predefinita. Su Linux, solo l'account root può accedere a queste credenziali. Su Windows Server, solo l'account SYSTEM e gli amministratori locali possono accedere a queste credenziali.

Precedenza credenziali SSM Agent

In questa sezione sono riportate informazioni importanti su come SSM Agent ha l'autorizzazione per eseguire azioni sulle risorse dell'utente.

Quando l'SSM Agent è installato su una macchina, richiede le autorizzazioni per comunicare con il servizio Systems Manager. Nelle istanze di Amazon Elastic Compute Cloud (Amazon EC2), queste autorizzazioni vengono fornite in un profilo collegato con l'istanza. Su una macchina non EC2, SSM Agent normalmente ottiene le autorizzazioni necessarie dal file delle credenziali condivise, che si trova in /root/.aws/credentials (Linux e macOS) o %USERPROFILE%\.aws\credentials (Windows Server). Le autorizzazioni necessarie vengono aggiunte a questo file durante il processo di attivazione ibrida.

In rari casi, tuttavia, una macchina potrebbe ritrovarsi autorizzazioni aggiunte a più di una delle posizioni in cui SSM Agent controlla le autorizzazioni per eseguire le sue attività.

Ad esempio, immaginiamo che tu abbia configurato un'istanza EC2 perché fosse gestita da Systems Manager. Questa configurazione include il collegamento di un profilo dell'istanza. Tuttavia, si può decidere di utilizzare tale istanza anche per le attività di sviluppatore o utente finale e di installarvi il AWS Command Line Interface (AWS CLI). Questa installazione comporta l'aggiunta di ulteriori autorizzazioni a un file di credenziali nell'istanza.

Quando si esegue un comando di Systems Manager sull'istanza, SSM Agent potrebbe provare a utilizzare credenziali diverse da quelle previste, ad esempio da un file di credenziali anziché da un profilo dell'istanza. Questo perché SSM Agent cerca le credenziali nell'ordine prescritto per la catena di provider di credenziali predefinita.

La catena di provider predefinita cerca le credenziali nel seguente ordine:

Per le relative informazioni, consultare i seguenti argomenti:

Configurazione SSM Agent per l'utilizzo con FIPS (Federal Information Processing Standard)

Se è necessario utilizzare Systems Manager con moduli crittografici convalidati FIPS (Federal Information Processing Standard) 140-3, è possibile configurare AWS Systems Manager Agent (SSM Agent) per utilizzare gli endpoint FIPS nelle regioni supportate.

Ogni volta che si modifica la configurazione, riavviare SSM Agent.

È possibile personalizzare altre funzionalità diSSM Agentutilizzando la stessa procedura. Per l'elenco aggiornato delle proprietà di configurazione disponibili e dei relativi valori predefiniti, vedi Definizioni delle proprietà di configurazione nel repository amazon-ssm-agent di GitHub.

Per ulteriori informazioni sul supporto AWS per FIPS, consultare Federal Information Processing Standard (FIPS) 140-3.

Informazioni sull'account ssm-user locale

A partire dalla versione 2.3.50.0 di SSM Agent, l'agente crea un account utente locale denominato ssm-user e lo aggiunge alla directory di /etc/sudoers.d (Linux e macOS) o al gruppo Administrators (Windows Server). Nelle versioni dell'agente precedenti alla 2.3.612.0, l'account viene creato la prima volta che SSM Agent viene avviato o riavviato dopo l'installazione. Nella versione 2.3.612.0 e successive, l'account ssm-user viene creato la prima volta che una sessione viene avviata su un'istanza. Questo ssm-user è l'utente del sistema operativo predefinito quando viene avviata una sessione in Session Manager, una funzionalità di AWS Systems Manager. È possibile modificare le autorizzazioni spostando ssm-user in un gruppo con meno privilegi o cambiando il file sudoers. Quando si disinstalla SSM Agent, l'account ssm-user non viene rimosso dal sistema.

In Windows Server, SSM Agent gestisce l'impostazione di una nuova password per l'account ssm-user all'avvio di ogni sessione. Nessuna password viene impostata per ssm-user su istanze gestite Linux.

A partire dalla versione di SSM Agent 2.3.612.0, l'account ssm-user non viene creato automaticamente sui computer Windows Server utilizzati come controller di dominio. Per utilizzare Session Manager su un controller di dominio Windows Server, creare l'account ssm-user manualmente, se non è già presente, e assegnare le autorizzazioni di amministratore di dominio all'utente.

SSM Agent e Instance Metadata Service (IMDS)

Per funzionare correttamente Systems Manager si basa sui metadati dell'istanza EC2. Systems Manager può accedere ai metadati dell'istanza utilizzando la versione 1 o la versione 2 di Instance Metadata Service (IMDSv1 e IMDSv2). L'istanza deve essere in grado di accedere all'indirizzo IPv4 del servizio di metadati dell'istanza: 169.254.169.254. Per ulteriori informazioni, consulta Metadati e dati dell'utente delle istanze nella Guida per l'utente di Amazon EC2.

Mantenere SSM Agent aggiornato

Una versione aggiornata di SSM Agent viene distribuita ogni volta che vengono aggiunte nuove funzionalità a Systems Manager o eseguiti aggiornamenti delle funzionalità esistenti. Il mancato utilizzo della versione più recente dell'agente può impedire al nodo gestito di utilizzare varie funzionalità e caratteristiche di Systems Manager. Per questo motivo, ti consigliamo di automatizzare il processo di aggiornamento di SSM Agent sulle macchine. Per informazioni, consultare Automazione degli aggiornamenti di SSM Agent. Iscriviti alla pagina Note di rilascio di SSM Agent su GitHub per ricevere notifiche sugli aggiornamenti di SSM Agent.

Verifica che la directory di installazione SSM Agent non venga modificata, spostata o eliminata

SSM Agent sia installato in /var/lib/amazon/ssm/ (Linux e macOS) e %PROGRAMFILES%\Amazon\SSM\ (Windows Server). Queste directory di installazione contengono file e cartelle critici utilizzati da SSM Agent, ad esempio un file di credenziali, risorse per la comunicazione tra processi (IPC) e cartelle di orchestrazione. Nulla all'interno della directory di installazione deve essere modificato, spostato o eliminato. In caso contrario, SSM Agent potrebbe smettere di funzionare correttamente.

Aggiornamenti di SSM Agent in sequenza per Regioni AWS (Regioni AWS)

Dopo che un aggiornamento dell'SSM Agent viene reso disponibile nel repository GitHub, c'è la possibilità che siano necessarie fino a due settimane prima che la versione aggiornata venga distribuita a tutte le Regioni AWS in momenti diversi. Per questo motivo, è possibile che venga visualizzato l'errore “Non supportato sulla piattaforma corrente” o “aggiornamento di amazon-ssm-agent a una versione precedente, abilitare il downgrade per procedere” quando si tenta di distribuire una nuova versione di SSM Agent in una regione.

Per determinare la versione di SSM Agent disposizione per l'utente, è possibile eseguire un comando curl.

Per visualizzare la versione dell'agente disponibile nel bucket di download globale, eseguire il comando seguente.

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

Per visualizzare la versione dell'agente disponibile in una regione specifica, eseguire il comando seguente, sostituendoregion (regione) con la regione in cui si sta lavorando, come us-east-2 per la regione Stati Uniti orientali (Ohio).

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

È possibile anche aprire il file VERSION direttamente nel browser senza un comando curl.

Comunicazioni di SSM Agent con i bucket S3 gestiti di AWS

Nel corso dell'esecuzione di varie operazioni di Systems Manager, AWS Systems Manager Agent (SSM Agent) accede a una serie di bucket Amazon Simple Storage Service (Amazon S3). Questi bucket S3 sono accessibili pubblicamente e, per impostazione predefinita, SSM Agent si connette con essi usando chiamate HTTP.

Tuttavia, se utilizzi un endpoint cloud privato virtuale (VPC) nelle operazioni di Systems Manager, devi fornire un'autorizzazione esplicita in un profilo dell'istanza Amazon Elastic Compute Cloud (Amazon EC2) per Systems Manager o in un ruolo di servizio per le macchine non EC2 in un ambiente ibrido e multicloud. In caso contrario, le risorse non possono accedere a questi bucket pubblici.

Per concedere l'accesso dei nodi gestiti a questi bucket quando utilizzi un endpoint VPC, devi creare una policy di autorizzazioni Amazon S3 personalizzata e collegarla al profilo dell'istanza (per le istanze EC2) o al ruolo del servizio (per i nodi gestiti non EC2).

Per informazioni sull'utilizzo dell'endpoint di un cloud privato virtuale (VPC) nelle operazioni di Systems Manager, consulta Migliora la sicurezza delle istanze EC2 utilizzando gli endpoint VPC per Systems Manager.

Per ulteriori informazioni, consulta i seguenti argomenti:

Autorizzazioni dei bucket necessarie

La tabella seguente descrive ciascuno dei bucket S3 di cui SSM Agent potrebbe aver bisogno per accedere alle operazioni di Systems Manager.

Autorizzazioni di Amazon S3 richieste da SSM Agent

Esempio

L'esempio seguente mostra come fornire l'accesso al bucket S3 richiesto per le operazioni di Systems Manager nella regione Stati Uniti orientali (Ohio) (us-east-2). Nella maggior parte dei casi, è necessario fornire queste autorizzazioni esplicitamente in un profilo dell'istanza o in un ruolo di servizio solo quando si utilizza un endpoint VPC.

{
        "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:::aws-ssm-us-east-2/*",
                    "arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
                    "arn:aws:s3:::aws-patch-manager-us-east-2-552881074/*",
                    "arn:aws:s3:::aws-patchmanager-macos-us-east-2-552881074/*"
                ]
            }
        ]
    }

Convalida di macchine attivate da sistemi tramite un'impronta digitale hardware

Quando si utilizzano macchine non EC2 in un ambiente ibrido e multicloud, SSM Agent raccoglie una serie di attributi di sistema (denominati hash hardware) e utilizza questi attributi per calcolare un'impronta digitale. L'impronta digitale è una stringa opaca che l'agente passa a determinate API di Systems Manager. Questa impronta digitale univoca associa il chiamante a un particolare nodo gestito attivato da sistemi ibridi. L'agente memorizza l'impronta digitale e l'hash hardware sul disco locale in una posizione chiamata Vault.

L'agente calcola l'hash hardware e l'impronta digitale quando la macchina viene registrata per essere utilizzata con Systems Manager. Quindi, l'impronta digitale viene restituita al servizio Systems Manager quando l'agente invia un comando RegisterManagedInstance.

Più tardi, quando si invia un comando RequestManagedInstanceRoleToken, l'agente controlla l'impronta digitale e l'hash hardware nel vault per verificare che gli attributi correnti della macchina corrispondano all'hash hardware archiviato. Se gli attributi correnti della macchina corrispondono effettivamente all'hash hardware archiviato nel vault, l'agente passa l'impronta digitale dal vault a RegisterManagedInstance, dando come risultato una chiamata riuscita.

Se gli attributi correnti della macchina non corrispondono all'hash hardware memorizzato, SSM Agent calcola una nuova impronta digitale, memorizza il nuovo hash hardware e l'impronta digitale nel vault e passa la nuova impronta digitale a RequestManagedInstanceRoleToken. Questo causa un errore in RequestManagedInstanceRoleToken e l'agente non sarà in grado di ottenere un token di ruolo per connettersi al servizio Systems Manager.

Questo errore varia in base alla progettazione e viene utilizzato come fase di verifica per impedire che più nodi gestiti comunichino con il servizio Systems Manager come fossero lo stesso nodo gestito.

Quando si confrontano gli attributi correnti della macchina con l'hash hardware memorizzato nel vault, l'agente utilizza la logica seguente per stabilire se gli hash vecchi e nuovi corrispondono:

La soglia di somiglianza viene memorizzata nel vault, insieme all'hash hardware.

La soglia di somiglianza può essere impostata dopo che un'istanza è stata registrata utilizzando un comando simile al seguente.

Su macchine Linux:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Sulle macchine Windows Server che utilizzano PowerShell:

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

SSM Agent - GitHub

Il codice sorgente per SSM Agent è disponibile su GitHub in modo da poter adattare l'agente per soddisfare le esigenze dell'utente. Ti consigliamo di inviare le richieste pull per le modifiche da includere. Tuttavia, Amazon Web Services attualmente non fornisce il supporto per eseguire copie modificate di questo software.