AWS Systems ManagerChange Managernon è più aperto a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta AWS Systems ManagerChange Managerla pagina Modifica della disponibilità.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scopri i dettagli tecnici sull'SSM Agent

Utilizza le informazioni contenute in questo argomento per aiutarti a implementare AWS Systems Manager Agent (SSM Agent) e a 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 operazioni sulle risorse dell'utente.

Quando l'SSM Agent è installato su una macchina, richiede le autorizzazioni per comunicare con il servizio Systems Manager. Nelle istanze Amazon Elastic Compute Cloud (Amazon EC2), queste autorizzazioni vengono fornite in un profilo di istanza collegato all'istanza. Su una EC2 macchina diversa, SSM Agent normalmente ottiene le autorizzazioni necessarie dal file di credenziali condiviso, che si trova in /root/.aws/credentials (Linux andmacOS) o (). %USERPROFILE%\.aws\credentials Windows Server Le autorizzazioni necessarie vengono aggiunte a questo file durante il processo di attivazione ibrida. Se viene annullata la registrazione di un nodo attivato in modalità ibrida, l'agente può entrare in modalità di ibernazione. Per ulteriori informazioni, consulta Comprendere l'ibernazione SSM Agent.

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, supponiamo di aver configurato un' EC2 istanza per essere 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 un up-to-date elenco delle proprietà di configurazione disponibili e dei relativi valori predefiniti, vedere Config Property Definitions nel amazon-ssm-agent repository in. GitHub

Per ulteriori informazioni sul AWS supporto per FIPS, vedere 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, uno strumento 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)

Systems Manager si affida ai metadati delle EC2 istanze per funzionare correttamente. 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' IPv4 indirizzo del servizio di metadati dell'istanza: 169.254.169.254. Per ulteriori informazioni, consulta Metadati dell'istanza e dati utente nella Amazon EC2 User Guide.

Mantenere SSM Agent up-to-date

Una versione aggiornata di SSM Agent viene distribuita ogni volta che vengono aggiunti nuovi strumenti a Systems Manager o eseguiti aggiornamenti degli strumenti esistenti. Il mancato utilizzo della versione più recente dell'agente può impedire al nodo gestito di utilizzare vari strumenti e funzionalità di Systems Manager. Per questo motivo, ti consigliamo di automatizzare il processo di aggiornamento di SSM Agent sulle macchine. Per informazioni, consulta 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.

SSM Agentaggiornamenti continui di Regioni AWS

Una volta reso disponibile un SSM Agent aggiornamento nel relativo GitHub repository, possono essere necessarie fino a due settimane prima che la versione aggiornata venga distribuita a tutti Regioni AWS in momenti diversi. Per questo motivo, potresti ricevere l'errore «Non supportato sulla piattaforma corrente» o «Aggiornamento amazon-ssm-agent a una versione precedente, attiva l'opzione consenti al downgrade di procedere» quando tenti 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, esegui il comando seguente, sostituendolo region con la regione in cui lavori, ad esempio la regione Stati Uniti orientali (us-east-2Ohio).

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

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

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

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

Per informazioni sull'utilizzo di un endpoint VPC (Virtual Private Cloud) nelle operazioni di Systems Manager, consulta Migliorare la sicurezza delle EC2 istanze 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.

JSON

{
        "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:::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 non si utilizzano EC2 macchine in un ambiente ibrido e multicloud, SSM Agent raccoglie una serie di attributi di sistema (denominati hash hardware) e li utilizza per calcolare un'impronta digitale. L'impronta digitale è una stringa opaca che l'agente passa a determinati Systems Manager. APIs 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

Su Windows Server macchine 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.

Comprendere l'ibernazione SSM Agent

AWS Systems Manager L'ibernazione dell'agente (SSM Agent) è una modalità operativa che si verifica quando l'agente non riesce a mantenere una comunicazione corretta con il servizio Systems Manager. Durante l'ibernazione, l'agente riduce la frequenza di comunicazione ed entra in uno stato di standby.

Quando si verifica l'ibernazione SSM Agent

SSM Agentl'ibernazione può verificarsi nei seguenti scenari:

Comportamento di comunicazione durante l'ibernazione

Quando SSM Agent entra in modalità di ibernazione, il modello di comunicazione con il servizio Systems Manager cambia:

Durante l'ibernazione, l'agente continua a riprovare l'autenticazione e i tentativi di connessione con una frequenza ridotta, ma non può elaborare nuovi comandi o riportare informazioni dettagliate sullo stato fino a quando l'ibernazione non viene risolta.

Opzioni di configurazione per prevenire l'ibernazione nelle istanze ibride

L'opzione di configurazione principale per evitare l'ibernazione causata dalle modifiche delle impronte digitali dell'hardware consiste nella regolazione della soglia di somiglianza:

Su macchine Linux:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Su macchine Windows Server che utilizzano: PowerShell

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

La soglia di somiglianza determina la precisione con cui l'agente confronta gli attributi correnti della macchina con l'hash hardware memorizzato:

Registrazione e monitoraggio dell'ibernazione

Quando SSM Agent entra in modalità di ibernazione, crea voci di registro che possono aiutarti a identificare e risolvere i problemi dello stato di ibernazione:

Monitora queste fonti di registro per rilevare tempestivamente gli eventi di ibernazione e intraprendere azioni correttive per ripristinare il normale funzionamento dell'agente.

Ripristino dalla modalità di ibernazione

Per riprendervi dall'ibernazione, risolvete la causa sottostante:

Dopo aver risolto il problema sottostante, l'agente dovrebbe uscire automaticamente dalla modalità di ibernazione e riprendere il normale funzionamento al successivo tentativo di comunicazione.