Belajar Cloud Engineer - IAM & Identity

#Pendahuluan

Kalian sudah membangun jaringan di episode 5, tetapi semua itu akan sia-sia jika siapa pun bisa membuka, mengubah, atau menghapus resource kalian. Di sinilah IAM (Identity and Access Management) berperan — lapisan keamanan yang menentukan siapa boleh melakukan apa terhadap resource mana.

Mengapa IAM adalah fondasi? Karena hampir semua pelanggaran cloud terjadi bukan lewat "hack canggih", melainkan melalui akses yang terlalu lebar: access key bocor dengan hak admin, akun lama yang tidak dihapus, atau policy yang membiarkan satu user menghapus seluruh bucket. Cloud engineer yang baik menganggap IAM bukan sebagai beban administrasi, tapi sebagai penjaga pintu yang diatur secara eksplisit sejak hari pertama.

#Komponen Dasar IAM

#User dan Group

User adalah identitas untuk manusia (atau aplikasi, via access key). Group adalah kumpulan user dengan peran sama — contoh developers, ops, auditors. Menggunakan group membuat pengelolaan jauh lebih mudah: tambah user ke group = langsung dapat semua izin yang sesuai.

aws iam create-group --group-name developers
aws iam create-user --user-name risa
aws iam add-user-to-group --group-name developers --user-name risa
aws iam create-access-key --user-name risa

#Policy

Policy adalah dokumen JSON yang mendeskripsikan izin: Effect (Allow/Deny), Action (API apa), Resource (objek mana), dan Condition (kapan). Contoh policy read-only untuk S3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::lab-backup",
        "arn:aws:s3:::lab-backup/*"
      ]
    }
  ]
}

Perhatikan dua hal: Action dibatasi ke API baca saja (tidak ada s3:DeleteObject), dan Resource dibatasi ke satu bucket. Ini contoh nyata least privilege — beri izin seminimal mungkin yang masih memungkinkan pekerjaan selesai.

#Role dan Service Account

Role adalah identitas yang bisa diambil alih sementara — tidak punya password/access key permanen. Ini penting karena aplikasi yang berjalan di cloud (VM, Lambda, container) seharusnya tidak menyimpan kredensial panjang di dalam kode; mereka mengasumsikan role saat runtime.

aws iam create-role --role-name lambda-execution \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "lambda.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'
aws iam attach-role-policy --role-name lambda-execution \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

GCP menyebutnya service account, Azure managed identity — konsepnya sama: identitas non-manusia dengan izin minimal yang bisa diasumsikan oleh workload. Di sinilah model shared responsibility bertemu keamanan: resource dalam cloud boleh berbicara ke resource lain tanpa menyimpan rahasia di kode.

#Prinsip Least Privilege

Least privilege berarti setiap identitas hanya punya izin minimum untuk melakukan tugasnya. Implementasinya:

1. Mulai dari nol, bukan dari admin. Jangan beri AdministratorAccess lalu berharap orang tidak menyalahgunakannya. Beri izin spesifik yang dibutuhkan.
2. Pakai managed policy dari provider sebagai titik awal (contoh AmazonS3ReadOnlyAccess), lalu persempit dengan policy custom.
3. Gunakan group, bukan langsung ke user — izin yang konsisten dan mudah diaudit.
4. Rotasi kredensial — buat access key baru, hapus yang lama, rutin.
5. Jangan pakai root account untuk pekerjaan sehari-hari. Root hanya untuk hal yang sangat spesifik (menutup akun, mengubah pengaturan pembayaran).

#Praktik: Setup IAM yang Aman

Mari bangun setup IAM yang aman secara bertahap:

Group: developers  → izin baca infrastruktur + deploy ke environment dev
Group: ops         → izin penuh di lingkungan production
Group: auditors    → read-only seluruh akun
 
Setiap user masuk ke SATU group. Access key hanya untuk CI/CD (episode 14),
bukan untuk user manusia — manusia memakai Single Sign-On / console login.

Langkah latihan di AWS:

1. Aktifkan MFA di akun root.
2. Buat group developers dan lampirkan policy managed ReadOnlyAccess.
3. Buat user risa, masukkan ke group developers, dan uji bahwa ia tidak bisa membuat resource baru.
4. Buat role lambda-execution untuk Lambda (seperti di atas) — buktikan fungsi bisa berjalan tanpa access key.

Jika di GCP, konsepnya diterjemahkan: gcloud iam service-accounts create, assign roles roles/viewer ke grup, dan roles/cloudfunctions.invoker ke service account. Di Azure: az role assignment create --assignee ... --role Reader. Latih ketiganya — kemampuan menerjemahkan konsep ini adalah ciri cloud engineer lintas-provider.

#Kesalahan Umum (Common Pitfalls)

1. Access key di commit — kredensial dalam kode/git. Solusi: role + secret manager (episode 15).
2. Policy */* — Action: "*", Resource: "*" di mana-mana. Solusi: sesempit mungkin, uji dampak dulu.
3. User menumpuk — akun karyawan lama tidak dihapus. Solusi: audit rutin dan hapus/disable user nonaktif.
4. Root dipakai sehari-hari — risiko terbesar. Solusi: buat admin dengan MFA, simpan root di brankas.
5. Tidak pernah mengetes policy — policy ditulis "secara naluriah" tanpa diuji. Solusi: gunakan fitur IAM policy simulator/validation dan dokumentasi contoh-contoh policy untuk dipakai ulang.

#Penutup

Inti yang harus dibawa pulang:

• IAM mengatur siapa boleh melakukan apa terhadap resource mana — fondasi keamanan seluruh akun.
• Empat komponen: user, group, policy, role (GCP: service account, Azure: managed identity).
• Least privilege = izin minimum yang cukup; mulai dari nol, bukan dari admin.
• Workload memakai role, bukan access key di kode; kredensial yang ter-commit dianggap bocor.
• Root account hanya untuk hal langka; MFA wajib; audit user dan policy secara rutin.

Di episode 7 selanjutnya kita akan mengotomasi seluruh provisioning yang barusan kalian lakukan manual — dengan Terraform: konsep IaC, provider, resource, state & remote state, hingga membangun infrastruktur dari kode. Sampai jumpa di episode 7!