Belajar Velero - Keamanan Credential & RBAC

#Pendahuluan

Sejak episode 3 kalian menyimpan cloud credential di file credentials-velero lalu menginstall-nya sebagai Secret. Itu berfungsi — tetapi untuk produksi, cara itu saja tidak cukup aman. Episode 13 membahas lapisan keamanan yang sering diabaikan tim: bagaimana credential disimpan, siapa yang bisa membacanya, dan apa yang bisa dilakukan service account Velero di cluster.

Bayangkan backup sebagai isi brankas, dan cloud credential sebagai kunci brankas. Kalian sudah menyimpan isinya dengan baik (bucket, TTL, enkripsi nanti). Tapi kalau kuncinya ditaruh di meja (file ter-commit di repo) dan semua orang boleh membukanya (RBAC longgar), brankas terbaik pun tidak berarti.

#Keamanan Credential Cloud

#Jangan Pernah Commit

Aturan pertama dan paling sering dilanggar: file credential tidak boleh masuk ke repository. Tambahkan ke .gitignore:

credentials-velero
*.pem
*.json
.env*

Alasan: Secret backup berisi Secret Kubernetes (password, token). Siapa pun dengan akses bucket bisa membaca semuanya. Kredensial bucket adalah satu-satunya gerbang — dan kredensial yang bocor di commit berarti gerbang itu terbuka.

#Secret di Namespace velero

Saat velero install --secret-file ./credentials-velero, CLI membuat Secret bernama cloud-credentials di namespace velero. Untuk pembaruan tanpa install ulang:

Update Secret credential

kubectl create secret generic cloud-credentials \
  --namespace velero \
  --from-file=cloud=./credentials-velero \
  --dry-run=client -o yaml | kubectl apply -f -
kubectl delete pod -n velero -l app.kubernetes.io/name=velero

Restart pod server setelah Secret berubah agar Velero membaca credential baru.

#Prinsip Least Privilege untuk IAM

Jangan pernah memberi akses admin penuh ke akun cloud. Buat IAM policy khusus Velero: akses put/get/list/delete ke bucket backup tertentu, dan izin membuat snapshot di region tertentu. Sebaiknya batasi ke satu bucket dan satu region.

#IRSA di EKS dan Workload Identity di GKE

#Mengapa Tidak Menggunakan Key Statis

Access key statis yang tersimpan di Secret: berlaku bertahun-tahun, tidak pernah rotasi otomatis, dan bisa bocor. Pola modern cloud-native adalah identitas workload: pod mendapatkan peran IAM langsung dari provider, tanpa key yang disimpan.

#IRSA (EKS)

IRSA (IAM Roles for Service Accounts) menghubungkan Kubernetes Service Account ke IAM role. Pasang annotation pada service account velero:

ServiceAccount velero dengan IRSA

apiVersion: v1
kind: ServiceAccount
metadata:
  name: velero
  namespace: velero
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/velero-backups

Lalu install Velero tanpa secret file:

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.14.0 \
  --bucket velero-backups \
  --no-secret \
  --backup-location-config region=us-east-1 \
  --snapshot-location-config region=us-east-1

#Workload Identity (GKE)

Pola yang sama di GCP: beri IAM binding antara service account Google dan service account Kubernetes, lalu annotate:

gcloud iam service-accounts add-iam-policy-binding velero-sa@proj.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:proj.svc.id.goog[velero/velero]"
 
kubectl annotate sa velero -n velero \
  iam.gke.io/gcp-service-account=velero-sa@proj.iam.gserviceaccount.com

Kelebihan pola ini: tanpa key sama sekali, otomatis mewarisi permission IAM, dan tidak ada Secret yang bisa dicuri.

#RBAC: Membatasi Akses ke Velero

#Kenapa Perlu Diperhatikan

Velero diinstall dengan ClusterRole yang luas — ia butuh bisa membaca seluruh resource di cluster untuk backup dan menulis resource saat restore. Yang sering luput: siapa pun yang bisa mengakses namespace velero praktis mengendalikan backup seluruh cluster — termasuk menghapusnya.

#Batasi Akses User

Berikan user biasa akses minimal — hanya bisa membaca status backup:

Role read-only di namespace velero

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: velero-viewer
  namespace: velero
rules:
  - apiGroups: ["velero.io"]
    resources: ["backups", "restores", "schedules", "backupstoragelocations"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: velero-viewer
  namespace: velero
subjects:
  - kind: User
    name: devops@example.com
roleRef:
  kind: Role
  name: velero-viewer
  apiGroup: rbac.authorization.k8s.io

Operator yang boleh menjalankan backup butuh Role terpisah dengan verbs create pada resource backups, schedules, restores — bukan ClusterRole admin.

#Verifikasi Permintaan RBAC

kubectl auth can-i get secrets -n velero --as devops@example.com

#Penutup

Inti yang harus dibawa pulang:

• Credential cloud = kunci brankas backup: jangan commit, batasi ke bucket/region tertentu.
• Update Secret via kubectl create secret ... --dry-run=client | kubectl apply lalu restart pod.
• IRSA (EKS) dan Workload Identity (GKE) menghapus kebutuhan key statis; install dengan --no-secret.
• Velero butuh ClusterRole luas; batasi user ke Role minimal (misal read-only velero-viewer).
• Verifikasi dengan kubectl auth can-i.

Di episode 14 selanjutnya kita mengamankan data yang tersimpan: Backup Encryption & Object Storage Security — SSE/KMS di object store, enkripsi snapshot, TLS ke endpoint S3, dan NetworkPolicy untuk komponen Velero.