AWS Systems ManagerChange Managertidak lagi terbuka untuk pelanggan baru. Pelanggan yang sudah ada dapat terus menggunakan layanan ini seperti biasa. Untuk informasi selengkapnya, lihat perubahan AWS Systems ManagerChange Manager ketersediaan.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pelajari detail teknis tentang SSM Agent

Gunakan informasi dalam topik ini untuk membantu Anda menerapkan AWS Systems Manager Agen (SSM Agent) dan memahami cara kerja agen.

SSM Agentversi 3.2.xx perilaku kredensi

SSM Agentmenyimpan satu set kredensi sementara di /var/lib/amazon/ssm/credentials (untuk Linux danmacOS) atau %PROGRAMFILES%\Amazon\SSM\credentials (untukWindows Server) ketika sebuah instance di-onboard menggunakan Konfigurasi Manajemen Host Default di. Quick Setup Kredensi sementara memiliki izin yang Anda tentukan untuk peran IAM yang Anda pilih untuk Konfigurasi Manajemen Host Default. Di Linux, hanya akun root yang dapat mengakses kredensil ini. Windows ServerAktif, hanya akun SYSTEM dan Administrator lokal yang dapat mengakses kredensil ini.

SSM Agentkredensialnya diutamakan

Topik ini menjelaskan informasi penting tentang bagaimana izin SSM Agent diberikan untuk melakukan tindakan pada sumber daya Anda.

Ketika SSM Agent diinstal pada mesin, itu memerlukan izin untuk berkomunikasi dengan layanan Systems Manager. Pada instans Amazon Elastic Compute Cloud (Amazon EC2), izin ini disediakan dalam profil instans yang dilampirkan ke instance. Pada EC2 non-mesin, SSM Agent biasanya mendapatkan izin yang diperlukan dari file kredensi bersama, yang terletak di /root/.aws/credentials (Linux danmacOS) atau %USERPROFILE%\.aws\credentials (). Windows Server Izin yang diperlukan ditambahkan ke file ini selama proses aktivasi hybrid. Jika node yang diaktifkan hibrida dideregistrasi, agen dapat memasuki mode hibernasi. Untuk informasi selengkapnya, lihat Memahami SSM Agent hibernasi.

Namun, dalam kasus yang jarang terjadi, mesin mungkin berakhir dengan izin yang ditambahkan ke lebih dari satu lokasi tempat SSM Agent memeriksa izin untuk menjalankan tugasnya.

Misalnya, Anda telah mengonfigurasi EC2 instance yang akan dikelola oleh Systems Manager. Konfigurasi itu termasuk melampirkan profil instance. Tetapi kemudian Anda memutuskan untuk juga menggunakan instance itu untuk tugas pengembang atau pengguna akhir dan menginstal AWS Command Line Interface (AWS CLI) di atasnya. Instalasi ini menghasilkan izin tambahan yang ditambahkan ke file kredensial pada instans.

Ketika Anda menjalankan perintah Systems Manager pada instance, SSM Agent mungkin mencoba menggunakan kredensial yang berbeda dari yang Anda harapkan untuk digunakan, seperti dari file kredensial alih-alih profil instance. Ini karena SSM Agent mencari kredensil dalam urutan yang ditentukan untuk rantai penyedia kredensi default.

Rantai penyedia default mencari kredensial dalam urutan sebagai berikut:

Untuk informasi terkait, lihat topik berikut:

Konfigurasi SSM Agent untuk digunakan dengan Federal Information Processing Standard (FIPS)

Jika Anda perlu menggunakan Systems Manager dengan Federal Information Processing Standard (FIPS) 140-3 modul kriptografi tervalidasi, Anda dapat mengonfigurasi AWS Systems Manager Agent (SSM Agent) untuk menggunakan endpoint FIPS di Wilayah yang didukung.

Setiap kali Anda mengubah konfigurasi, restartSSM Agent.

Anda dapat menyesuaikan fitur lain SSM Agent menggunakan prosedur yang sama. Untuk up-to-date daftar properti konfigurasi yang tersedia dan nilai defaultnya, lihat Config Property Definitions dalam amazon-ssm-agent repositori di. GitHub

Untuk informasi selengkapnya tentang AWS dukungan untuk FIPS, lihat Federal Information Processing Standard (FIPS) 140-3.

Tentang akun ssm-user lokal

Dimulai dengan versi 2.3.50.0 dariSSM Agent, agen membuat akun pengguna lokal yang disebut ssm-user dan menambahkannya ke /etc/sudoers.d direktori (Linux danmacOS) atau ke grup Administrator (). Windows Server Pada versi agen sebelum 2.3.612.0, akun dibuat pertama kali SSM Agent dimulai atau dimulai ulang setelah instalasi. Pada versi 2.3.612.0 dan yang lebih baru, akun ssm-user dibuat saat pertama kali sesi dimulai pada sebuah instans. Ini ssm-user adalah pengguna OS default ketika sesi dimulaiSession Manager, alat di AWS Systems Manager. Anda dapat mengubah izin dengan memindahkan ssm-user ke grup yang kurang istimewa atau dengan mengubah file sudoers. ssm-userAkun tidak dihapus dari sistem saat SSM Agent dihapus.

Windows ServerAktif, SSM Agent menangani pengaturan kata sandi baru untuk ssm-user akun saat setiap sesi dimulai. Tidak ada kata sandi yang ditetapkan untuk ssm-user pada instans yang dikelola Linux.

Dimulai dengan SSM Agent versi 2.3.612.0, ssm-user akun tidak dibuat secara otomatis pada Windows Server mesin yang digunakan sebagai pengontrol domain. Untuk digunakan Session Manager pada pengontrol Windows Server domain, buat ssm-user akun secara manual jika belum ada, dan tetapkan izin Administrator Domain kepada pengguna.

SSM Agentdan Instance Metadata ServiceIMDS

Systems Manager mengandalkan metadata EC2 instance agar berfungsi dengan benar. Systems Manager dapat mengakses metadata instans menggunakan versi 1 atau versi 2 dari Instance Metadata Service (IMDSv1 dan IMDSv2). Instans Anda harus dapat mengakses IPv4 alamat layanan metadata instans: 169.254.169.254. Untuk informasi selengkapnya, lihat Metadata instans dan data pengguna di EC2 Panduan Pengguna Amazon.

Menjaga SSM Agent up-to-date

Versi terbaru dirilis setiap kali alat baru ditambahkan ke Systems Manager atau pembaruan dibuat ke alat yang ada. SSM Agent Gagal menggunakan agen versi terbaru dapat mencegah node terkelola Anda menggunakan berbagai alat dan fitur Systems Manager. Untuk alasan itu, kami menyarankan Anda mengotomatiskan proses menjaga agar tetap SSM Agent up to date pada mesin Anda. Untuk informasi, lihat Mengotomatiskan pembaruan ke SSM Agent. Berlangganan halaman Catatan SSM Agent Rilis GitHub untuk mendapatkan pemberitahuan tentang SSM Agent pembaruan.

Memastikan bahwa direktori SSM Agent instalasi tidak diubah, dipindahkan, atau dihapus

SSM Agentdiinstal di /var/lib/amazon/ssm/ (Linux danmacOS) dan %PROGRAMFILES%\Amazon\SSM\ (Windows Server). Direktori instalasi ini berisi file dan folder penting yang digunakan olehSSM Agent, seperti file kredensial, sumber daya untuk komunikasi antar-proses (IPC), dan folder orkestrasi. Tidak ada dalam direktori instalasi yang harus dimodifikasi, dipindahkan, atau dihapus. Jika tidak, SSM Agent mungkin berhenti berfungsi dengan baik.

SSM Agentpembaruan bergulir oleh Wilayah AWS

Setelah SSM Agent pembaruan tersedia di GitHub repositori, dapat memakan waktu hingga dua minggu hingga versi yang diperbarui diluncurkan ke semua Wilayah AWS pada waktu yang berbeda. Untuk alasan ini, Anda mungkin menerima kesalahan “Tidak didukung pada platform saat ini” atau “memperbarui amazon-ssm-agent ke versi yang lebih lama, aktifkan izinkan penurunan versi untuk melanjutkan” saat mencoba menerapkan versi baru SSM Agent di Wilayah.

Untuk menentukan versi yang SSM Agent tersedia untuk Anda, Anda dapat menjalankan curl perintah.

Untuk melihat versi agen yang tersedia di bucket unduhan global, jalankan perintah berikut.

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

Untuk melihat versi agen yang tersedia di Wilayah tertentu, jalankan perintah berikut, ganti region dengan Wilayah tempat Anda bekerja, seperti us-east-2 untuk Wilayah Timur AS (Ohio).

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

Anda juga dapat membuka file VERSION secara langsung di peramban Anda tanpa perintah curl.

SSM Agentkomunikasi dengan bucket S3 AWS terkelola

Dalam menjalankan berbagai operasi Systems Manager, AWS Systems Manager Agent (SSM Agent) mengakses sejumlah bucket Amazon Simple Storage Service (Amazon S3). Bucket S3 ini dapat diakses publik, dan secara default, SSM Agent terhubung ke mereka menggunakan panggilan. HTTP

Namun, jika Anda menggunakan titik akhir virtual private cloud (VPC) dalam operasi Systems Manager, Anda harus memberikan izin eksplisit di profil instans Amazon Elastic Compute Cloud ( EC2Amazon) untuk Systems Manager, atau dalam peran layanan untuk EC2 non-mesin di lingkungan hybrid dan multicloud. Jika tidak, sumber daya Anda tidak dapat mengakses bucket publik ini.

Untuk memberikan akses node terkelola ke bucket ini saat Anda menggunakan titik akhir VPC, Anda membuat kebijakan izin Amazon S3 khusus, lalu melampirkannya ke profil instans (untuk instance) atau peran layanan Anda ( EC2 untuk node yang tidak dikelola). EC2

Untuk informasi tentang penggunaan titik akhir virtual private cloud (VPC) dalam operasi Systems Manager Anda, lihat Meningkatkan keamanan EC2 instans dengan menggunakan titik akhir VPC untuk Systems Manager.

Untuk informasi selengkapnya, lihat topik berikut:

Izin bucket yang diperlukan

Tabel berikut menjelaskan setiap bucket S3 yang SSM Agent mungkin perlu diakses untuk operasi Systems Manager.

Izin Amazon S3 diperlukan oleh SSM Agent

Contoh

Contoh berikut menggambarkan cara menyediakan akses ke bucket S3 yang diperlukan untuk operasi Systems Manager di Wilayah US East (Ohio) Region (us-east-2). Dalam kebanyakan kasus, Anda perlu memberikan izin ini secara eksplisit dalam profil instans atau peran layanan hanya saat menggunakan titik akhir 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/*"
                ]
            }
        ]
    }

Memvalidasi mesin yang diaktifkan hibrida menggunakan sidik jari perangkat keras

Ketika EC2 non-mesin di lingkungan hybrid dan multicloud, SSM Agent mengumpulkan sejumlah atribut sistem (disebut sebagai hash perangkat keras) dan menggunakan atribut ini untuk menghitung sidik jari. Sidik jari adalah string buram yang dilewatkan agen ke Systems Manager APIs tertentu. Sidik jari unik ini mengaitkan penelepon dengan node terkelola yang diaktifkan hibrida tertentu. Agen menyimpan sidik jari dan hash perangkat keras pada disk lokal di lokasi yang disebut Vault.

Agen menghitung hash perangkat keras dan sidik jari saat mesin terdaftar untuk digunakan dengan Systems Manager. Kemudian, sidik jari diteruskan kembali ke layanan Systems Manager ketika agen mengirimkan perintah RegisterManagedInstance.

Kemudian, ketika mengirim perintah RequestManagedInstanceRoleToken, agen memeriksa sidik jari dan hash perangkat keras di Vault untuk memastikan bahwa atribut mesin saat ini cocok dengan hash perangkat keras yang disimpan. Jika atribut mesin saat ini cocok dengan hash perangkat keras yang disimpan di Vault, agen akan meneruskan sidik jari dari Vault ke RegisterManagedInstance, menghasilkan panggilan yang sukses.

Jika atribut mesin saat ini tidak cocok dengan hash perangkat keras yang disimpan, SSM Agent menghitung sidik jari baru, menyimpan hash perangkat keras dan sidik jari baru di Vault, dan meneruskan sidik jari baru ke. RequestManagedInstanceRoleToken Ini menyebabkan RequestManagedInstanceRoleToken gagal, dan agen tidak akan dapat memperoleh token peran untuk menghubungkan ke layanan Systems Manager.

Kegagalan ini dirancang dan digunakan sebagai langkah verifikasi untuk mencegah beberapa node terkelola berkomunikasi dengan layanan Systems Manager sebagai node terkelola yang sama.

Ketika membandingkan atribut mesin saat ini untuk hash perangkat keras yang disimpan di Vault, agen menggunakan logika berikut untuk menentukan apakah hash lama dan yang baru cocok:

Batas kesamaan disimpan di Vault, sebagai bagian dari hash perangkat keras.

Batas kesamaan dapat diatur setelah instans terdaftar menggunakan perintah seperti berikut.

Pada mesin Linux:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Pada Windows Server mesin yang menggunakan PowerShell:

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

SSM Agent pada GitHub

Kode sumber SSM Agent tersedia GitHubsehingga Anda dapat menyesuaikan agen untuk memenuhi kebutuhan Anda. Kami mendorong Anda untuk mengirim permintaan tarik untuk perubahan yang ingin Anda sertakan. Namun, Amazon Web Services tidak menyediakan dukungan untuk menjalankan salinan yang dimodifikasi dari perangkat lunak ini.

Memahami SSM Agent hibernasi

AWS Systems Manager Hibernasi Agen (SSM Agent) adalah mode operasional yang terjadi ketika agen tidak dapat mempertahankan komunikasi yang tepat dengan layanan Systems Manager. Selama hibernasi, agen mengurangi frekuensi komunikasinya dan memasuki keadaan siaga.

Ketika SSM Agent hibernasi terjadi

SSM Agenthibernasi dapat terjadi dalam skenario berikut:

Perilaku komunikasi hibernasi

Saat SSM Agent memasuki mode hibernasi, pola komunikasinya dengan layanan Systems Manager berubah:

Selama hibernasi, agen terus mencoba lagi otentikasi dan upaya koneksi pada frekuensi yang dikurangi, tetapi tidak dapat memproses perintah baru atau melaporkan informasi status terperinci sampai hibernasi diselesaikan.

Opsi konfigurasi untuk mencegah hibernasi dalam instance hybrid

Opsi konfigurasi utama untuk membantu mencegah hibernasi yang disebabkan oleh perubahan sidik jari perangkat keras adalah menyesuaikan ambang kesamaan:

Pada mesin Linux:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Pada mesin Windows Server menggunakan PowerShell:

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

Ambang kesamaan menentukan seberapa ketat agen membandingkan atribut mesin saat ini dengan hash perangkat keras yang disimpan:

Pencatatan dan pemantauan hibernasi

Saat SSM Agent memasuki mode hibernasi, itu membuat entri log yang dapat membantu Anda mengidentifikasi dan memecahkan masalah status hibernasi:

Pantau sumber log ini untuk mendeteksi peristiwa hibernasi lebih awal dan mengambil tindakan korektif untuk memulihkan operasi agen normal.

Memulihkan dari hibernasi

Untuk pulih dari hibernasi, atasi penyebab yang mendasarinya:

Setelah Anda menyelesaikan masalah mendasar, agen harus secara otomatis keluar dari mode hibernasi dan melanjutkan operasi normal pada upaya komunikasi berikutnya.