Di dalam environment Amazon Web Services (AWS) jika ingin berinteraksi dengan API AWS kita dapat menggunakan AWS API key/AWS Credentials for programmatic access yang umumnya terdiri dari AWS Access Key ID dan AWS Secret Access Key. Umumnya API key ini terasosiasi dengan entitas di dalam AWS Identity and Access Management (IAM) dimana salah satu contohnya adalah IAM user. IAM user pun dapat diklasifikasi menjadi IAM user yang digunakan untuk human-to-machine interaction dan machine-to-machine interaction. Contoh penerapan machine-to-machine interaction misalkan kita membuat sebuah IAM machine user yang digunakan di dalam CI/CD engine yang kita gunakan, kemudian kita menyimpan credential API key dari IAM machine user tersebut di dalam environment variable CI/CD engine agar dapat berinteraksi ke AWS misalkan saat ingin push container image ke AWS.
Terkadang API key dari IAM machine user ini perlu disebarluaskan ke developer/engineer yang membutuhkan dan yang memiliki privilege untuk melihat dan menggunakan API key tersebut. Contoh misalkan tim infrastruktur ingin memberikan informasi API key ini ke developer tim service produk A. Jika menggunakan metode menyebarkan API key ini via csv file dan kemudian disimpan oleh developer, mungkin hal ini akan menimbulkan suatu potensi masalah di kemudian hari. Misalkan developer tersebut lupa menyimpan dimana file tersebut, atau mungkin developer/engineer terkait sudah resign dan lupa/tidak menyebarkan file tersebut atau juga potensi lain misalkan API key tersebut tersebar ke pihak yang tidak berkepentingan sehingga menimbulkan celah keamanan.
Melalui blog ini, saya ingin memberikan sebuah solusi yang dapat menjadi pilihan untuk masalah di atas. Caranya adalah dengan memusatkan penyimpanan AWS API key dari IAM machine tersebut. API key akan disimpan di dalam service AWS yang bernama AWS Secrets Manager
Skenario
- Konfigurasi penyimpanan API key akan di-inisiasi menggunakan pendekatan Infrastructure as Code (IaC) menggunakan Terraform
- Terraform akan menggunakan konfigurasi backend remote via Terraform Cloud
Struktur Direktori
Pada artikel ini, struktur direktori yang digunakan oleh terraform code sebagai berikut:
.
└── environment-name/
└── secrets-manager/
└── region-name/
├── main.tf
├── resources.tf
└── variables.tf
Konfigurasi
- Konfigurasi saya mulai dengan membuat file main.tf. Di file ini saya mendeklarasikan konfigurasi Terraform yang akan mengacu ke Terraform Cloud (app.terraform.io) sebagai backend. Dan mereferensikan nama organisasi dan workspace yang digunakan. Kemudian saya juga deklarasikan terraform provider yang digunakan yaitu hashisorp/aws dengan versi terkait. Di akhir saya deklarasikan region aws yang digunakan, mengacu ke variable aws_region yang ada di file variables.tf yang berikutnya akan saya jelaskan.
###########################
# Terraform Configuration #
###########################
terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "my-organization"
workspaces {
name = "my-secretsmanager-workspace"
}
}
}
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.48.0"
}
}
required_version = ">= 1.3.0"
}
provider "aws" {
region = var.aws_region
}
- Selanjutnya mendefinisikan variable yang digunakan oleh Terraform di dalam file variables.tf.
variable "aws_region" {
type = string
description = "AWS Region"
default = "ap-southeast-1"
}
variable "waiting_deletion_period" {
type = number
description = "Waiting period in days before secret deleted. Set to 0 for force destroy"
default = 0
}
- Mengacu ke dokumen Terraform AWS Provider terkait resource aws_secretsmanager_secret_version. Jika kita ingin membuat secret dengan key-value pairs, kita dapat mengambil value tersebut dari beberapa metode dan yang umum adalah via variable. Maka dari itu, masih di dalam file variables.tf, saya membuat sebuah variable yang berisi key-value pairs yang digunakan oleh IAM machine user. Dan karena AWS_SECRET_ACCESS_KEY menyimpan sensitive value, saya tidak mengisi value yang sebenarnya digunakan namun nantinya akan diganti secara manual via AWS Web Console. Tujuannya agar di repository tidak tersimpan sensitive value. Contohnya seperti berikut:
variable "my_machine_credentials" {
type = map(string)
description = "Key value pairs consist of AWS credentials used by my machine user"
default = {
"AWS_ACCESS_KEY_ID" = "AKIAWE1AB2CD34FG5I767"
"AWS_SECRET_ACCESS_KEY" = "change_me"
}
}
- Selanjutnya di file resources.tf saya mendeklarasikan secret beserta valuenya, dimana valuenya mengambil referensi dari variable yang di deklarasikan seperti di poin nomor 3.
###########
# Secrets #
###########
resource "aws_secretsmanager_secret" "dummy_machine_sbx" {
name = "dummy-machine-sbx"
recovery_window_in_days = var.waiting_deletion_period
tags = {
"Name" = "dummy-machine-sbx"
"my:environment" = "sandbox"
"my:owner" = "Luthfi"
}
}
resource "aws_secretsmanager_secret_version" "dummy_machine_sbx" {
secret_id = aws_secretsmanager_secret.dummy_machine_sbx.id
secret_string = jsonencode(var.dummy_machine_user_sbx_credentials)
}
- Selanjutnya adalah melakukan commit dan push terraform code ke repository. Dan lakukan terraform plan dan terraform apply di Terraform Cloud workspace agar infrastructure dapat dibuat/provisioned. Untuk bagian ini hanya saya tampilkan simulasinya saja. Jika ingin melihat lebih detail bagaimana proses provisioning resource AWS via Terraform Cloud, silahkan lihat blogpost saya berikut ini.
- Setelah provisioning resource via Terraform Cloud sudah selesai. Langkah selanjutnya adalah memastikan resource berhasil terbentuk. Kita dapat menggunakan AWS web console untuk memastikannya. Masuk ke halaman service Secrets Manager, kemudian masuk ke menu Secrets. Pastikan secret dengan nama yang didefinisikan di Terraform code sudah berhasil terbentuk.
- Masuk ke halaman detail secret dengan mengklik nama secret. Di halaman ini kita bisa melihat detail konfigurasi secret, misal nama secret, ARN dari secret, encryption key yang digunakan dan tags yang didefinisikan.
- Untuk secret yang saya buat di blogpost ini tidak dikonfigurasi rotation configuration secara automatic.
- Untuk memastikan value dari secret, dapat mengklik tombol Retrieve secret value seperti yang terlihat di poin nomor 7. Kemudian klik tombol Edit untuk merubah value dari AWS_SECRET_ACCESS_KEY.
- Ubah value AWS_SECRET_ACCESS_KEY kemudian Save.
- Pastikan value sudah terupdate.
- Selanjutnya selalu pastikan hanya user-user yang memiliki privilege yang dapat melihat atau mengakses secret
Kesimpulan
Akhirnya kita sampai di penghujung artikel ini. Ada beberapa kesimpulan atau key takeaways yang ingin saya sampaikan:
- Untuk mencegah beberapa potensi masalah terkait celah keamanan dan masalah dalam pembagian/penyimpanan AWS API key yang digunakan IAM machine user, kita dapat memusatkan penyimpanan AWS API key tersebut ke dalam AWS Secrets Manager
- Konfigurasi secret di dalam Secrets Manager dapat dilakukan dengan pendekatan IaC. Sehingga kita memiliki state file dari infrastruktur yang sudah kita buat.
Silahkan kunjungi GitHub repository saya untuk melihat contoh source code konfigurasi yang digunakan dalam artikel ini.
Sekian artikel kali ini. Jika ada saran, kritik, atau masukan silahkan tinggalkan di kolom komentar.
Terima kasih!
Blog LUDES Developer 
Tinggalkan Balasan