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 sulla 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 IAM ruolo scelto per la configurazione predefinita della gestione dell'host. Su Linux, solo l'account root può accedere a queste credenziali. SìWindows Server, solo l'SYSTEMaccount 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 SSM Agent è installato su una macchina, richiede le autorizzazioni per comunicare con il servizio Systems Manager. Nelle istanze Amazon Elastic Compute Cloud (AmazonEC2), 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.

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'EC2istanza 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'uso con il Federal Information Processing Standard () FIPS

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

Ogni volta che si modifica la configurazione, riavviareSSM 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 perFIPS, 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 all'avvio di una sessione inSession Manager, una funzionalità di AWS Systems Manager. Puoi 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'IPv4indirizzo 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 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 SSM AgentRelease Notes su GitHub per ricevere notifiche sugli SSM Agent aggiornamenti.

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 daSSM 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 periodici 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, sostituendo region con la regione in cui lavori, ad esempio 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

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, SSM Agent si connette con essi usando chiamate HTTP.

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

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

Per informazioni sull'utilizzo di un endpoint cloud privato virtuale (VPC) nelle operazioni di Systems Manager, consulta Migliorare la sicurezza delle EC2 istanze utilizzando gli VPC endpoint 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 in modo esplicito in un profilo di 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 non si utilizzano EC2 computer 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 di SSM Agent è disponibile su GitHubin modo da poter adattare l'agente alle proprie esigenze. 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.