Dalam artikel ini, kita akan fokus pada dua konsep penting yang mungkin. Konsep pertama adalah bagaimana otentikasi berbasis Kunci SSH dan berbasis kata sandi bekerja di Ansible. Konsep kedua adalah bagaimana meningkatkan hak istimewa saat bekerja dengan perintah ad hoc dan playbooks.
Saya memiliki pengaturan lab tiga simpul yang menjalankan mesin Ubuntu 20.04 LTS menggunakan VirtualBox dan Vagrant. Ada artikel terperinci tentang pengaturan lab yang dapat Anda baca dari tautan di bawah ini.
Pengaturan Lab Otomatis Dengan Vagrant Dan Virtualbox Di LinuxContents
Otentikasi Berbasis Kunci Di AnsibleSSH Otentikasi Berbasis Kata Sandi Di AnsibleEskalasi Privilege Di AnsibleConclusionOtentikasi Berbasis Kunci Di Ansible
Hal pertama yang Anda miliki memahami kapan belajar yang memungkinkan adalah bagaimana komunikasi terjadi antara pengontrol dan node yang dikelola. Ansible menggunakan protokol SSH untuk terhubung ke node yang dikelola dan menjalankan tugas.
Setiap kali Anda menjalankan playbook atau perintah ad hoc, Anda harus memberikan kata sandi SSH untuk memungkinkan otentikasi ke node yang dikelola melalui SSH.
Untuk menghilangkan ini, disarankan untuk membuat pasangan kunci SSH dan berbagi kunci publik dengan semua node sehingga memungkinkan dapat berkomunikasi menggunakan keypair.
Saya telah membuat dua pasangan kunci bernama first_key dan second_key menggunakan skrip di bawah ini untuk demonstrasi.
Buat teks file bernama create_keypair.sh dengan isi sebagai berikut.
#!/usr/bin/env bash # SKRIP INI AKAN MENCIPTAKAN SSH KEY PAIR DAN mendistribusikan DI SELURUH NODES read -p "Masukkan nama untuk kuncinya : " KEY_NAME ssh-keygen - b 2048 -t rsa -f /home/vagrant/.ssh/${KEY_NAME} -q -N "" # LOOPING MELALUI DAN mendistribusikan KUNCI untuk val di controller managed1 managed2; do echo "-------------------- MENYALIN KUNCI KE ${val^^} NODE ----------------- -------------" sshpass -p 'vagrant' ssh-copy-id -f -i /home/vagrant/.ssh/${KEY_NAME}.pub -o "StrictHostKeyChecking=no" [email protected]$val done
Berikan izin eksekusi ke skrip dan jalankan.
$ chmod +x path/to/create_keypair.sh
$ ./create_keypair.sh
Saya telah membuat skrip ini untuk penyiapan lab saya. Anda dapat mengedit bagian for loop dan menambahkan nama node terkelola yang sesuai.
$ tree .ssh/.ssh/├── Authorized_keys├── first_key├── first_key.pub├── known_hosts├── second_key└── second_key .pub
Ketika Anda memiliki kunci yang dibuat dengan nama berbeda selain nama default(id_rsa), ssh akan mencoba menemukan nama kunci default dan jika tidak ditemukan, ia akan meminta otentikasi berbasis kata sandi.
debug1: SSH2_MSG_SERVICE_ACCEPT menerima debug1: Otentikasi yang dapat lanjutkan: kunci publik, kata sandi debug1: Metode otentikasi berikutnya: debug kunci publik1: Mencoba kunci pribadi: /home/vagrant/.ssh/id_rsa debug1: Mencoba kunci pribadi: /home/vagrant/.ssh/id_dsa debug1: Mencoba kunci pribadi: /home /vagrant/.ssh/id_ecdsa debug1: Mencoba kunci pribadi: /home/vagrant/.ssh/id_ecdsa_sk debug1: Mencoba kunci pribadi: /home/vagrant/.ssh/id_ed25519 debug1: Mencoba kunci pribadi: /home/vagrant/.ssh /id_ed25519_sk debug1: Mencoba kunci pribadi: /home/vagrant/.ssh/id_xmss debug1: Metode otentikasi berikutnya: passw ord [email protected]'s password:
Dalam hal ini, Anda harus menyebutkan file kunci pribadi secara eksplisit menggunakan -i flag.
$ ssh -v -i /home/vagrant/.ssh/first_key [email protected]
Ketika Anda menjalankan perintah ad hoc atau buku pedoman, Anda dapat menggunakan flag –key-file atau –private-key dan meneruskan file kunci pribadi sebagai argumen. Dalam contoh di bawah ini, Anda dapat melihat saya telah menggunakan kedua kunci (kunci_pertama & kunci_kedua) untuk berhasil berkomunikasi dengan node yang dikelola.
# MENGGUNAKAN --key-file FLAG $ ansible managed1 -m ping --key-file /home/vagrant /.ssh/second_key managed1 | SUKSES => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3" }, "berubah": false, "ping": "pong" }
# MENGGUNAKAN --private-key FLAG $ ansible managed1 - m ping --private-key /home/vagrant/.ssh/first_key managed1 | SUKSES => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3" }, "changed": false, "ping": "pong" }
Anda juga dapat menambahkan parameter “private_key_file” di ansible. File konfigurasi cfg yang akan diterapkan ke perintah adhoc dan semua tugas playbook.
$ vim ansible.cfg
Tambahkan baris berikut:
Private_key_file = /home/vagrant/.ssh/first_key
Ganti /home/vagrant/.ssh/first_key dengan your own.
juga dapat menambahkan parameter “ansible_ssh_private_key” di file inventaris Anda yang akan lebih diutamakan daripada file ansible.cfg. Di bawah ini adalah bagaimana inventaris saya sekarang disiapkan. Node managed1 akan menggunakan “first_key” dan managed2 akan menggunakan “second_key”.
[ubuntu1] managed1 ansible_ssh_private_key_file=/home/vagrant/.ssh/first_key [ubuntu2] managed2 ansible_ssh_private_key_file=/home/vagrant/.ssh/second_key
n perintah adhoc atau playbook lagi, Anda dapat melihat kedua kunci akan berhasil diautentikasi. Anda dapat meningkatkan verbositas untuk memeriksa apakah kunci yang sesuai digunakan sesuai input kami.
$ ansible -vvv all -m ping
Sekarang Anda harus memiliki pemahaman yang baik tentang cara kerja otentikasi berbasis kunci di ansible. Penting untuk memahami prioritas saat menambahkan parameter di file yang berbeda. Opsi baris perintah lebih diutamakan diikuti oleh file inventaris dan file konfigurasi ansible.cfg.
SSH Otentikasi Berbasis Kata Sandi Di Ansible
Ketika Anda menjalankan tugas apa pun, ansible akan menggunakan pengguna saat ini di node pengontrol untuk berkomunikasi dengan node yang dikelola melalui SSH . Anda dapat menggunakan modul shell dan menjalankan perintah “whoami” untuk memverifikasi nama pengguna di node yang dikelola. Dalam kasus saya, nama pengguna adalah “gelandangan”. Pengguna gelandangan mengautentikasi menggunakan kunci yang telah saya siapkan di bagian sebelumnya.
$ whoamivagrant
$ ansible all -m shell -a "whoami" managed2 | DIUBAH | rc=0 >> gelandangan dikelola1 | DIUBAH | rc=0 >> gelandangan
Jika Anda ingin terhubung ke node yang dikelola sebagai pengguna yang berbeda, Anda dapat menggunakan flag –u atau –user dan meneruskan nama pengguna sebagai argumen. Jika Anda melihat gambar di bawah ini, saya mencoba menggunakan pengguna “karthick” yang tidak memiliki pengaturan kunci SSH dan tidak ada kunci yang didistribusikan ke node yang dikelola sehingga konektivitasnya semakin gagal.
$ ansible all -m shell -a "whoami " -u karthick$ ansible all -m shell -a "whoami" --user karthick
Untuk menggunakan otentikasi berbasis kata sandi, Anda dapat menggunakan flag -k atau –ask-pass. Ini akan meminta Anda untuk memasukkan kata sandi SSH untuk pengguna (karthick). Pastikan kata sandi sama di semua node untuk pengguna.
$ ansible all -m shell -a "whoami" -u karthick -k$ ansible all -m shell -a "whoami" -u karthick --ask- pass
Anda juga dapat menyimpan kata sandi dalam file dan meneruskan nama file sebagai argumen ke –connection-password-file atau –conn-pass-file flag. Ini bukan cara yang disarankan karena Anda menyimpan kata sandi dalam file teks biasa. Anda dapat menggunakan brankas yang memungkinkan untuk mengenkripsi file kata sandi tetapi ini adalah topik terpisah untuk didiskusikan.
$ memungkinkan semua -m shell -a "whoami" -u karthick --connection-password-file pass.txt$ memungkinkan semua -m shell -a "whoami" -u karthick --conn-pass-file pass.txt
Anda juga dapat memberikan nama pengguna dan sandi sebagai parameter dalam file inventaris. Sekali lagi ini bukan cara terbaik untuk menyimpan kata sandi. Di bawah ini adalah bagaimana file inventaris saya sekarang diatur.
[ubuntu1] managed1 ansible_ssh_private_key_file=/home/vagrant/.ssh/first_key ansible_user=vagrant [ubuntu2] managed2 ansible_user=karthick ansible_ssh_pass=password
$ ansible all -m shell -a "whoami " -u karthick managed1 | DIUBAH | rc=0 >> gelandangan dikelola2 | DIUBAH | rc=0 >> karthick
Heads Up: Saya mungkin menjalankan contoh menggunakan perintah adhoc tetapi flag yang sama juga berlaku untuk buku pedoman.
Eskalasi Hak Istimewa Di Ansible
Ada kalanya tugas Anda memerlukan hak istimewa yang lebih tinggi (root) untuk berjalan dengan sukses. Misalnya, manajemen paket. Anda hanya dapat menginstal, menghapus, atau memutakhirkan paket sebagai pengguna root atau dengan hak istimewa sudo.
Ketika Anda menjalankan bendera bantuan bersama dengan buku pedoman yang mungkin atau yang memungkinkan, Anda akan menemukan bagian eskalasi hak istimewa seperti yang ditunjukkan pada gambar.
$ ansible --help$ ansible-playbook --help
Ketika Anda ingin menjalankan tugas apa pun dengan hak akses root, anda harus menggunakan -b atau –become flag.
$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -b managed1 | DIUBAH => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3" }, "berubah": true, "name": "sshd", "state": "started",
Secara default, sudo akan digunakan sebagai metode eskalasi hak istimewa. Anda dapat mengubah metode dengan menyetel tanda –become-method. Anda bisa mendapatkan daftar metode yang didukung dengan menjalankan perintah berikut.
$ ansible-doc -t menjadi -l ansible.netcommon.enable Beralih ke izin yang lebih tinggi pada perangkat jaringan community.general.doas Lakukan Sebagai komunitas pengguna.general.dzdo Centrify's Direct Authorize community.general.ksu Kerberos pengganti user community.general.machinectl Systemd's machinectl privilege escalation community.general.pbrun PowerBroker run community.general.pfexec eksekusi berbasis profil community.general.pmrun Privilege Manager run community.general.sesu CA Privileged Pengelola Akses community.general.sudosu Jalankan tugas menggunakan sudo su - runas Jalankan Sebagai pengguna su Pengguna Pengganti sudo Pengguna Pengganti LAKUKAN
Anda dapat atau tidak memberikan kata sandi sudo untuk node yang dikelola tergantung pada bagaimana pengguna diatur. Dalam kasus saya, saya telah mengatur gelandangan pengguna untuk menjalankan sudo tanpa meminta kata sandi.
Jika pengguna sudo Anda memerlukan kata sandi untuk berfungsi, maka Anda harus menggunakan flag -K atau –ask-become-pass yang akan meminta kata sandi sudo.
Seperti yang dapat Anda lihat dari kesalahan di bawah ini, ketika saya mencoba menjalankan tanpa memberikan kata sandi sudo untuk pengguna “karthick”, itu memberi saya kesalahan yang mengatakan “Kata sandi sudo hilang”.
$ ansible ubuntu1 -m service -a "name= sshd state=restart" -i inventory -u karthick -k -b kata sandi SSH: managed1 | GAGAL! => { "msg": "Kata sandi sudo tidak ada" }
$ layanan ubuntu1 -m yang dimungkinkan -a "nama=sshd state=restart" -i inventory -u karthick -k -b -K
Sudo password dapat disimpan dalam sebuah file dan diteruskan sebagai argumen ke –become-password-file atau –become-pass-file flag. Gudang yang memungkinkan dapat digunakan untuk mengenkripsi file ini tetapi bukan praktik yang disarankan.
$ layanan ubuntu1 -m yang memungkinkan -a "name=sshd state=restarted" -i inventory -u karthick -k -b --become-password-file pass.txt $ ansible ubuntu1 -m service -a "name=sshd state=restart" -i inventory -u karthick -k -b --become-pass-file pass.txt
Anda juga dapat menyertakan direktif “become” di buku pedoman pada level tugas atau level permainan.
Gambar di bawah menunjukkan bagaimana direktif “menjadi” digunakan di level permainan.
Gambar di bawah menunjukkan bagaimana direktif “menjadi” digunakan pada level tugas.
Seperti yang dapat Anda lihat dari output, layanan ssh dimulai ulang dengan baik di managed1 node.
$ ansible-playbook restart_service.yml PLAY [Mulai ulang layanan SSHD] ************************* ************************************************** TUGAS [Mulai ulang SSHD di managed1.anslab.com] *************************************** ********************* diubah: [managed1] PLAY RECAP ********** ************************************************** ******************************** dikelola1 : ok=1 diubah=1 tidak dapat dijangkau=0 gagal=0 dilewati=0 diselamatkan =0 diabaikan=0
Direktif “menjadi” juga dapat diatur di file konfigurasi ansible.cfg dan file inventaris. Tetapi disarankan untuk mengatur arahan di buku pedoman. Anda bisa mendapatkan parameter yang berbeda untuk file ansible.cfg dari link di bawah ini.
Menjadi directive
Jika Anda ingin menjalankan tugas sebagai pengguna yang berbeda setelah terhubung ke node yang dikelola, maka Anda harus menggunakan flag –become-user. Secara default, ini diatur ke root user.
Conclusion
Dalam artikel ini, kita telah melihat bagaimana otentikasi berbasis kunci dan kata sandi bekerja di Ansible dan flag berbeda yang didukung untuk otentikasi. Kami juga telah melihat bagaimana eskalasi hak istimewa bekerja di Ansible.
Untuk menyelam lebih dalam, Anda harus memiliki pemahaman yang adil tentang cara kerja metode eskalasi hak istimewa yang berbeda dan sesuai dengan kebutuhan Anda, atur lingkungan tanpa mengorbankan keamanan.