Belajar Floci - IAM, STS & Model Credentials

#Pendahuluan

Di AWS sungguhan, IAM adalah penjaga gerbang: setiap request dinilai terhadap policy, dan satu salah konfigurasi berarti AccessDenied. Di dunia emulator lokal, pertanyaannya menarik: bagaimana seharusnya IAM ditiru?

Floci memilih filosofi pragmatis — tanpa auth token, credential apa pun diterima. Episode ini menjelaskan kenapa keputusan itu masuk akal, risikonya apa, dan cara tetap mendisiplinkan tim dengan fake profile + simulasi policy evaluation via STS.

#Filosofi

#Tanpa Auth Token — Credential Apa Pun Diterima

Sejak episode 3 kita diam-diam memakai credentials bohongan dan semuanya berhasil. Itu desain, bukan celah:

• Tidak ada validasi signature terhadap kunci nyata — request hanya perlu berformat signature v4.
• Tidak ada token lisensi (kontras dengan LocalStack pasca-sunset) — CI tanpa kredensial eksternal tetap jalan.
• Konsekuensi praktis: aws configure bisa diisi apa saja dan app tetap berjalan.

#Tetap Gunakan Fake Profile Rapi

Rekomendasi series ini: perlakukan floci seperti AWS sungguhan dalam hal higiene credential. Buat named profile khusus agar parity dengan produksi terjaga:

aws configure --profile floci
# AWS Access Key ID     : floci-local-key
# AWS Secret Access Key : floci-local-secret
# Default region name   : us-east-1
# Default output format : json
 
export AWS_PROFILE=floci AWS_ENDPOINT_URL=http://localhost:4566

Manfaatnya: script tim tidak pernah memakai profile production secara tak sengaja, region eksplisit menghindari resource tersebar, dan pola AWS_PROFILE identik saat pindah ke AWS asli.

#STS

#AssumeRole & Simulasi Policy Evaluation

STS (Security Token Service) didukung untuk pola akses temporer:

aws --endpoint-url=http://localhost:4566 iam create-role \
  --role-name svc-reader \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}' >/dev/null
 
CREDS=$(aws --endpoint-url=http://localhost:4566 sts assume-role \
  --role-arn arn:aws:iam::000000000000:role/svc-reader \
  --role-session-name local-test \
  --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' --output text)
 
echo "$CREDS" # temporary key trio - format sama dengan produksi

Response berisi trio AccessKeyId/SecretAccessKey/SessionToken dengan struktur persis AWS. Untuk policy evaluation, gunakan simulator API:

aws --endpoint-url=http://localhost:4566 iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::000000000000:role/svc-reader \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::app-assets/js/app.js
# gunakan hasilnya untuk melatih review policy - bukan sebagai jaminan enforcement runtime

Penting dibedakan: simulator membantu validasi logika policy (apakah JSON-nya benar), namun enforcement runtime di floci longgar. Uji logika lokal; uji enforcement di sandbox AWS untuk path kritis.

#Praktik

Target outline: setup named profile floci + uji assume-role chain lokal.

set -euo pipefail
export AWS_ENDPOINT_URL=http://localhost:4566 AWS_PROFILE=floci
 
# chain: role A -> assume role B -> akses S3
aws iam create-role --role-name role-b \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::000000000000:root"},"Action":"sts:AssumeRole"}]}' >/dev/null
 
T=$(aws sts assume-role --role-arn arn:aws:iam::000000000000:role/role-b \
      --role-session-name hop-b)
export AWS_ACCESS_KEY_ID=$(echo "$T"|jq -r .Credentials.AccessKeyId)
export AWS_SECRET_ACCESS_KEY=$(echo "$T"|jq -r .Credentials.SecretAccessKey)
export AWS_SESSION_TOKEN=$(echo "$T"|jq -r .Credentials.SessionToken)
 
aws sts get-caller-identity | jq -r '.Arn'
# arn:aws:sts::000000000000:assumed-role/role-b/hop-b  <- identitas efektif = role B
 
echo "chain data" | aws s3 cp - s3://app-assets/via-role.txt && echo "akses via role OK"

Chain ini mereplikasi pola cross-service trust produksi. Karena SDK menangani session token transparan, aplikasi kalian bisa diuji dengan mekanisme temporer yang sama seperti nanti di AWS.

#Penutup

Rangkuman episode ini:

• Model credential floci: no-token, semua credential diterima — enak untuk CI, tapi enforcement policy tidak dipaksakan.
• Disiplin tetap: named profile floci, region eksplisit, pola env identik dengan produksi.
• STS AssumeRole + simulate-principal-policy untuk melatih logika IAM; enforcement path kritis tetap divalidasi ke sandbox AWS.

Episode 10 naik satu layer ke kriptografi: emulasi KMS — generate key, encrypt/decrypt, dan envelope encryption pattern untuk melindungi field PII sebelum masuk DynamoDB. Sampai jumpa!