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

Utilizzate le informazioni contenute in questo argomento per aiutarvi a implementare AWS Systems Manager Agent (SSM Agent) e scopri come funziona l'agente.

SSM Agent comportamento delle credenziali della versione 3.2.x.x

SSM Agent memorizza un set di credenziali temporanee in (per Linux e /var/lib/amazon/ssm/credentials macOS) o %PROGRAMFILES%\Amazon\SSM\credentials (per Windows Server) quando un'istanza viene inserita utilizzando la 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. Abilitato Windows Server, solo l'SYSTEMaccount e gli amministratori locali possono accedere a queste credenziali.

SSM Agent precedenza delle credenziali

Questo argomento descrive informazioni importanti su come SSM Agent riceve l'autorizzazione a 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 macchina non utilizzata, EC2 SSM Agent normalmente ottiene le autorizzazioni necessarie dal file di credenziali condivise, che si trova in /root/.aws/credentials (Linux e macOS) o (%USERPROFILE%\.aws\credentialsWindows Server). Le autorizzazioni necessarie vengono aggiunte a questo file durante il processo di attivazione ibrida.

In rari casi, tuttavia, è possibile che su un computer vengano aggiunte le autorizzazioni in più di una delle posizioni in cui SSM Agent verifica le autorizzazioni necessarie per eseguire le proprie 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 Systems Manager sull'istanza, SSM Agent potrebbe provare a utilizzare credenziali diverse da quelle che ci si aspetta che utilizzi, ad esempio da un file di credenziali anziché da un profilo di 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 da utilizzare 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 Agent ( AWS Systems Manager SSM Agent) per utilizzare gli FIPS endpoint nelle regioni supportate.

Ogni volta che modifichi la configurazione, riavvia SSM Agent.

Puoi personalizzare altre funzionalità di SSM Agent utilizzando 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 chiamato ssm-user e lo aggiunge alla /etc/sudoers.d directory (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 SSM Agent si avvia o si riavvia 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 in Session Manager, una capacità di AWS Systems Manager. Puoi modificare le autorizzazioni spostando ssm-user in un gruppo con meno privilegi o cambiando il file sudoers. L'ssm-useraccount non viene rimosso dal sistema quando SSM Agent è disinstallato.

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

A partire da SSM Agent versione 2.3.612.0, l'ssm-useraccount non viene creato automaticamente su Windows Server macchine che vengono utilizzate come controller di dominio. Per utilizzare Session Manager su un Windows Server controller di dominio, crea l'ssm-useraccount manualmente se non è già presente e assegna le autorizzazioni di amministratore di dominio all'utente.

SSM Agent e il Instance Metadata Service (IMDS)

Systems Manager si affida ai metadati delle EC2 istanze per funzionare correttamente. Systems Manager può accedere ai metadati delle istanze 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 rilasciato ogni volta che vengono aggiunte nuove funzionalità a Systems Manager o vengono apportati aggiornamenti alle 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, si consiglia di automatizzare il processo di conservazione SSM Agent aggiornato sulle tue macchine. Per informazioni, consultare Automazione degli aggiornamenti di SSM Agent. Iscriviti al SSM AgentPagina delle note di rilascio su GitHub per ricevere notifiche su SSM Agent aggiornamenti.

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

SSM Agent è 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. Altrimenti, SSM Agent potrebbe smettere di funzionare correttamente.

SSM Agent aggiornamenti continui di Regioni AWS

Dopo un SSM Agent l'aggiornamento è reso disponibile nella sua 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 a tua disposizione, puoi eseguire un curl comando.

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.

SSM Agent comunicazioni con bucket AWS S3 gestiti

Nel corso dell'esecuzione di varie operazioni di Systems Manager, AWS Systems Manager l'agente (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 ad essi tramite HTTP chiamate.

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, devi creare una policy di autorizzazione Amazon S3 personalizzata e quindi collegarla 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 che SSM Agent potrebbe essere necessario accedere per le operazioni di Systems Manager.

Autorizzazioni 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 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, archivia il nuovo hash hardware e la nuova impronta digitale nel Vault e trasmette 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

Abilitato Windows Server macchine che utilizzano: PowerShell

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

SSM Agent on GitHub

Il codice sorgente per SSM Agent è disponibile su GitHubin modo che possiate adattare l'agente alle vostre esigenze. Ti consigliamo di inviare le richieste pull per le modifiche da includere. Tuttavia, Amazon Web Services non fornisce supporto per l'esecuzione di copie modificate di questo software.