Penyedia komputasi awan publik menyediakan berbagai antarmuka bagi penggunaanya untuk berinteraksi. Salah satu antarmuka tersebut adalah antarmuka pemrograman aplikasi (API) berbasis HTTP yang diakses melalui internet. Klien dapat menggunakan baris perintah, pustaka, atau Software Development Kit (SDK) yang disediakan oleh penyedia komputasi awan publik untuk berinteraksi dengan API mereka. Tulisan ini akan membahas berbagai skenario interaksi klien dengan API AWS.

Interaksi langsung klien ke API AWS

Untuk mengakses API AWS, kita membutuhkan pasangan kunci yang bersifat rahasia. Pasangan kunci tersebut terdiri dari

• ID kunci yang dikenal dengan nama AWS Access Key ID.
• Sandi kunci yang dikenal dengan nama AWS Secret Access Key.

Pasangan kunci ini bisa dibangkitkan pada halaman konsol web AWS. Hal penting selanjutnya setelah membuat pasangan kunci adalah memasukan pasangan kunci ke lingkungan eksekusi klien yang akan memanggil API AWS. Misal kita akan berinteraksi dengan API AWS melalui baris perintah. Setelah antarmuka baris perintah AWS terinstall di mesin klien, kita perlu meletakan pasangan kunci AWS pada lokasi yang sudah ditentukan. Ada 2 pilihan tempat yang umum digunakan yaitu:

• Variabel lingkungan AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY.
• Berkas konfigurasi pada lokasi ~/.aws/config.

Kita bebas memilih salah satu opsi di atas untuk menyimpan pasangan kunci AWS. Setelah antarmuka baris perintah dan pasangan kunci AWS disusun dengan baik, kita siap untuk berinteraksi dengan API AWS. Berikut contoh baris perintah untuk mengetahui identitas dari pasangan kunci yang kita gunakan.

aws sts get-caller-identity

# Keluaran
{
    "UserId": "AIDA6DSVLW6K2VYSOT5PT",
    "Account": "<dihapus>",
    "Arn": "arn:aws:iam::<dihapus>:user/roy"
}

Alur kerja ini sederhana sehingga mudah dipahami. Alur ini memiliki kekurangan dimana pasangan kunci AWS tersimpan dalam bentuk teks biasa tanpa enkripsi. Pasangan kunci ini berlaku selamanya sampai dihapus melalui konsol web AWS. Alur ini digambarkan sebagai berikut

Interaksi menggunakan kredensial sementara

Penggunaan kredensial seumur hidup secara umum tidak dianjurkan dari sudut pandang keamanan perangkat lunak. Alternatif yang lebih baik adalah menggunakan pasangan kunci yang memiliki masa berlaku sementara. Pasangan kunci ini akan otomatis tidak valid ketika sudah melewati waktu hidupnya. Untuk memfasilitasi skenario ini, AWS menyediakan layanan Security Token Service (STS) untuk membangkitkan pasangan kunci AWS yang berlaku sementara. Kunci sementara ini selanjutnya akan digunakan untuk memanggil API AWS. Alur ini digambarkan sebagai berikut

Kita bisa melihat pada diagram di atas bahwa untuk membangkitkan kunci sementara kita membutuhkan pasangan kunci utama. Disini kita dihadapkan pada persoalan penyimpanan kunci utama secara aman. Persoalan lain yang perlu diselesaikan adalah memasok kunci utama ketika meminta kredensial sementara dan memasok kunci sementara untuk selanjutnya digunakan memanggil API AWS. Kedua persoalan ini bisa diselesaikan dengan menggunakan alat yang bernama AWS Vault. AWS Vault menyimpan kunci utama ke dalam ruang penyimpanan aman yang terenkripsi menggunakan kata sandi yang kita tentukan. AWS Vault memiliki sub perintah exec yang berguna untuk membangkitkan kunci sementara dengan memanggil API STS AWS, mengurai respon dari API STS AWS, dan memasok pasangan kunci sementara dalam bentuk variabel lingkungan. Alur ini cocok digunakan oleh administrator akun AWS ketika berinteraksi dengan API AWS menggunakan antarmuka baris perintah pada mesin lokalnya. Berikut contoh penggunaan AWS Vault untuk menyimpan kunci utama dan memanggil baris perintah AWS untuk mengetahui identitas yang kita gunakan.

aws-vault add roy # aws-vault akan meminta kita untuk memasukan pasangan kunci utama AWS
aws-vault roy exec -- aws sts get-caller-identity

# Keluaran
{
    "UserId": "AIDA6DSVLW6K2VYSOT5PT",
    "Account": "<dihapus>",
    "Arn": "arn:aws:iam::<dihapus>:user/roy"
}

Alur ini juga memfasilitasi penggunaan pasangan kunci utama yang membutuhkan multi factor authentication (MFA). Konfigurasi MFA bisa dilakukan dengan menambahkan kunci pengaturan mfa_serial pada berkas ~/.aws/config seperti contoh berikut.

[profile roy]
mfa_serial = arn:aws:iam::111111111111:mfa/roy

Nilai mfa_serial bisa dilihat tab Security Credentials pada dashbor Users IAM AWS.

Skenario lain yang difasilitasi pada skenario ini adalah mendelegasikan izin menggunakan wewenang (AWS Role). Kunci utama AWS yang dimiliki oleh administrator umumnya memiliki izin yang tidak terbatas. Adakalanya administrator butuh mengeksekusi perintah yang akan berkomunikasi dengan API AWS menggunakan izin yang lebih terbatas. Misalkan ketika administrator ingin menguji wewenang yang baru dibuat apakah sudah memenuhi prinsip penerapan batas akses secukupnya (principle of least privileges). Pengubahan peran bisa dilakukan dengan menyesuaikan isi dari berkas ~/.aws/config.

[profile roy]
mfa_serial = arn:aws:iam::111111111111:mfa/roy

[profile rds-monitor]
role_arn = arn:aws:iam::111111111111:role/rds-monitoring-role
source_profile = roy

Profil rds-monitor pada konfigurasi di atas memiliki wewenang baru yang berbeda dengan wewenang yang dimiliki oleh kunci utama. Berikut contoh pemanggilan API STS dengan peran yang berbeda.

aws-vault exec rds-monitor -- aws sts get-caller-identity

# Keluaran
{
    "UserId": "AROAWDX4EPHWDLZ47RON2:<dihapus>",
    "Account": "<dihapus>",
    "Arn": "arn:aws:sts::<dihapus>:assumed-role/rds-monitoring-role/<dihapus>"
}

Interaksi menggunakan token OpenID Connect

Pembangkitan kredensial sementara pada alur sebelumnya membutuhkan kredensial utama. Kredensial ini memiliki masa hidup yang abadi dan akan terus bisa digunakan sampai dinonaktifkan. Pengguna kredensial utama seperti ini tidak cocok pada lingkungan eksekusi tertentu dimana lingkungan bersifat sementara dan memiliki idenditas lain. Pada keadaan seperti ini identitas tersebut bisa digunakan sebagai pengganti kredensial utama untuk memperoleh kredensial AWS sementara. Salah satu lingkungan eksekusi yang memenuhi kriteria di atas adalah kubernetes pod. Pod adalah abstraksi lingkungan eksekusi pada kubernetes. Setiap pod kubernetes memiliki identitas bawaan yang dikenal dengan nama service account. Alur pemanggilan skenario ini bisa digambarkan sebagai berikut .

EKS Pod Identity Webhook pada gambar di atas adalah komponen yang bekerja di dalam kluster kubernetes. Komponen ini bertanggungjawab menyuntikan informasi id peran (role arn) dan token OIDC ke dalam pod. Selanjutnya program yang berjalan di dalam pod menggunakan kedua informasi tersebut untuk berkomunikasi dengan API STS AWS untuk memperoleh kredensial sementara. Ketika menerima permintaan kredensial sementara berdasarkan token OIDC, API STS AWS akan melakukan validasi keabsahan token berdasarkan informasi yang disediakan oleh Penyedian Identias OpenID Connect. Selanjutnya API STS AWS akan mengembalikan kredensial sementara ketika validasi berhasil dilakukan. Kredensial sementara ini siap digunakan oleh program yang berjalan di dalam pod untuk memanggil API AWS lainnya. Sebelum API STS AWS dapat melakukan validasi token, kita perlu membangun hubungan kepercayaan antara API STS AWS dan Penyedia Idenditas OpenID Connect.