Belajar Vault - Identity Engine (Entities, Aliases & Groups)

#Pendahuluan

Setelah di episode 10 sebelumnya kita membahas authentication methods — token, userpass, AppRole, dan OIDC — kalian mungkin menyadari satu masalah halus namun krusial: setiap kali seorang user login lewat auth method yang berbeda, Vault memperlakukannya sebagai identitas yang terpisah. User yang sama login via userpass pagi hari dan via OIDC siang hari akan mendapat dua token berbeda, dua set policy berbeda, dan dua jejak audit yang tidak terhubung. Di organisasi nyata dengan Okta, GitHub, dan LDAP sekaligus, ini menjadi mimpi buruk governance.

Pada episode kali ini kita akan membahas Identity Engine — jawaban Vault atas masalah tersebut. Identity Engine memperkenalkan tiga konsep: Entity (identitas manusia/mesin yang sebenarnya), Alias (cara identitas tersebut tampil di tiap auth method), dan Group (kumpulan entitas untuk mewariskan policy). Dengan memahami ketiganya, kalian bisa merancang sistem akses yang terpadu: satu orang, banyak metode login, satu kumpulan hak akses, dan satu jejak audit.

Mari kita bedah satu per satu.

#Pembahasan Utama

#Masalah yang Dipecahkan Identity Engine

Coba bayangkan skenario ini di perusahaan kalian:

1. Budi login ke Vault via OIDC (Okta) menggunakan akun budi@company.com → mendapat policy dev-kv.
2. Di laboratorium staging yang terisolasi, Budi juga punya akun userpass budi dengan policy berbeda.
3. Vault menganggap keduanya dua orang berbeda — alias, dua entitas berbeda.

Akibatnya: policy tidak terpadu, audit log tidak bisa menjawab pertanyaan "apa yang dilakukan Budi hari ini?" secara lengkap, dan jika Budi dipecat, admin harus mencabut akses di banyak tempat. Identity Engine menyatukan semua ini.

Konsep intinya:

      +--------------- Entity: Budi Dwi (ID: 1a2b3c) ---------------+
      |   entity policies: [dev-kv]                                  |
      |                                                              |
      |   +-------- Alias 1 --------+   +-------- Alias 2 ---------+ |
      |   | auth: oidc              |   | auth: userpass           | |
      |   | name: budi@company.com  |   | name: budi               | |
      +---+-------------------------+---+--------------------------+

Sekarang, apakah Budi login dari Okta atau userpass, Vault mengenalinya sebagai Entity yang sama. Policy pada entity berlaku untuk keduanya, dan audit log pun mencatat keduanya ke identitas yang sama.

#Entity dan Alias dalam Praktik

Biasanya entity dibuat otomatis oleh Vault saat seseorang pertama kali login lewat auth method tertentu. Namun untuk kontrol penuh, kita juga bisa membuatnya secara manual. Mari kita lihat keduanya.

1. Login pertama kali — Vault membuat entity + alias otomatis

vault login -method=userpass username=budi password=S3cur3Pa55word!

vault identity lookup

Key                              Value
---                              -----
aliases                          [map[canonical_id:71a7... custom_metadata:<nil> creation_time:... id:... last_update_time:... merged_from_canonical_ids:<nil> metadata:<nil> mount_accessor:auth_userpass_8f2... mount_path:auth/userpass/ mount_type:userpass name:budi]]
canonical_id                     71a7e5b1-...
creation_time                    2026-08-02T10:00:00.000Z
id                               71a7e5b1-...
last_update_time                 2026-08-02T10:00:00.000Z
local                            false
metadata                         <nil>
name                             2be7c3d0-... # auto-generated dari login
policies                         []

Perhatikan bagian aliases: di dalamnya ada mount_type: userpass dan name: budi. Ini adalah Alias pertama milik Entity Budi. Entity name yang auto-generated (berupa UUID acak) biasanya akan di-rename manual agar lebih manusiawi — kita akan lakukan sebentar lagi.

2. Membuat entity manual (control penuh)

vault write -format=json identity/entity \
    name="budi-dwi" \
    metadata=team="backend-engineers"

{
  "data": {
    "aliases": null,
    "canonical_id": "71a7e5b1-...",
    "creation_time": "2026-08-02T10:05:00.000Z",
    "id": "71a7e5b1-...",
    "last_update_time": "2026-08-02T10:05:00.000Z",
    "name": "budi-dwi",
    "policies": []
  }
}

3. Menambahkan alias userpass ke entity ini

vault write identity/alias \
    name="budi" \
    canonical_id="71a7e5b1-..." \
    mount_accessor="auth_userpass_8f2..." # dari vault auth list -format=json

Sekarang, saat Budi login via userpass, Vault akan menemukan alias budi pada mount auth_userpass_8f2..., memetakannya ke Entity budi-dwi, dan menerapkan policy entity tersebut.

4. Menambah alias OIDC — menyatukan dua metode login

Langkah yang sama dilakukan untuk alias dari auth method OIDC:

vault write identity/alias \
    name="budi@company.com" \
    canonical_id="71a7e5b1-..." \
    mount_accessor="auth_oidc_9d1..."

Voilà — sekarang Budi yang login via userpass maupun OIDC adalah satu Entity. Policy apa pun yang kita tempelkan ke entity budi-dwi berlaku di kedua metode login.

#Entity Policies vs Token Policies: Siapa yang Menang?

Di episode 9 kita belajar tentang policy yang melekat pada token (token_policies). Sekarang ada lapisan baru: entity policies (identity_policies). Keduanya digabung ketika menentukan hak akses — ingat kembali union semantics: capabilities digabungkan. Tapi ada perbedaan penting dalam cara pengelolaannya:

vault token lookup

Key                  Value
---                  -----
accessor             Z6Xb...
creation_time        1722747600
duration             768h
entity_id            71a7e5b1-...
expire_time          2026-09-02T10:00:00.000Z
id                   hvs.CAESILf...
identity_policies    ["dev-kv"]             # dari entity
issue_time           2026-08-02T10:00:00.000Z
meta                 map[username:budi]
policies             ["default" "dev-kv"]  # gabungan
renewable            true
token_policies       ["default"]           # dari token/auth method
ttl                  768h

Perhatikan perbedaan identity_policies dan token_policies pada output di atas. policies adalah gabungan keduanya, dan itulah yang benar-benar dievaluasi saat request masuk.

#Groups: Mewariskan Policy ke Banyak Entity

Mengelola policy satu per satu untuk 500 karyawan tidak akan scalable. Di sinilah Group bekerja: kumpulan entity yang mewariskan policy ke semua anggotanya. Ada dua jenis group di Vault:

1. Internal Groups — dibuat manual oleh admin Vault.

vault write identity/group \
    name="backend-engineers" \
    policies="dev-kv,ci-access"

Key             Value
---             -----
id              e3f4a1b2-...
name            backend-engineers
policies        ["ci-access" "dev-kv"]
type            internal

Kemudian tambahkan entity Budi (dan rekan-rekannya) ke group:

vault write identity/group/id/e3f4a1b2-... \
    member_entity_ids="71a7e5b1-...,9c8d7e6f-..."

2. External Groups — dibuat otomatis saat auth method (LDAP/OIDC) mengirimkan klaim groups dari IdP.

vault write identity/group/name/okta-backend-engineers \
    type="external" \
    policies="dev-kv"

vault read identity/group/name/okta-backend-engineers

External groups bekerja dengan cara: saat user login via OIDC, IdP menyertakan klaim groups (misal backend-engineers dari Okta). Vault otomatis menautkan entity user ke external group yang namanya cocok dengan klaim tersebut, dan policy group pun diwariskan.

#Capability Inheritance: Menelusuri dari Mana Hak Akses Berasal

Karena policy bisa datang dari token, entity, dan group sekaligus, pertanyaan "kenapa user ini bisa akses path itu?" menjadi krusial saat audit. Vault menyediakan alat untuk menelusuri ini:

vault identity lookup-entity -name budi-dwi

Key                          Value
---                          -----
aliases                      [map[mount_path:auth/userpass mount_type:userpass name:budi] map[mount_path:auth/oidc mount_type:oidc name:budi@company.com]]
id                           71a7e5b1-...
name                         budi-dwi
policies                     [dev-kv]
merged_entity_ids            []
metadata                     map[team:backend-engineers]
groups                       [map[name:backend-engineers policies:[ci-access dev-kv]]]

Output ini menjawab banyak pertanyaan audit: entity Budi punya policy dev-kv langsung, dan mewarisi ci-access + dev-kv dari group backend-engineers. Total hak akses Budi = gabungan policy entity + policy group + policy token saat login.

Dengan perintah di bawah ini, kalian bisa memeriksa apakah sebuah token punya hak akses ke path tertentu beserta sumbernya:

vault token capabilities hvs.CAESILf... secret/data/app

read list

#Skenario Praktik: Multi-Auth dengan Satu Identitas

Mari kita rangkai seluruh konsep dalam satu skenario lengkap. Perusahaan kalian punya tim backend yang aksesnya harus konsisten, baik mereka login dari Okta (OIDC) maupun dari lab staging (userpass).

1. Persiapkan kedua auth method

vault auth enable userpass
vault auth enable oidc

2. Buat policy bersama

path "secret/data/staging/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
 
path "secret/metadata/staging/*" {
  capabilities = ["list"]
}

vault policy write dev-kv policy/dev-kv.hcl

3. Buat internal group dengan policy

vault write identity/group/name=backend-engineers \
    policies="dev-kv"

4. Buat userpass user dan entity

vault write auth/userpass/users/budi password="S3cur3Pa55word!"

vault write identity/entity name="budi-dwi" metadata=team="backend-engineers"

vault write identity/alias name="budi" \
    canonical_id="<entity-id>" \
    mount_accessor="<accessor-userpass>"

vault write identity/alias name="budi@company.com" \
    canonical_id="<entity-id>" \
    mount_accessor="<accessor-oidc>"

5. Masukkan entity ke group

vault write identity/group/id/<group-id> \
    member_entity_ids="<entity-id>"

Sekarang, apakah Budi login via userpass di lab maupun via Okta di produksi, hasilnya sama: token dengan policies: [default dev-kv] (dari group backend-engineers). Satu kali konfigurasi, berlaku untuk semua jalur login, dan tercatat dalam satu audit trail.

#Menjelajahi Identity: Entity, Alias, dan Group

Seiring pertumbuhan organisasi, kalian akan membutuhkan cara untuk memetakan seluruh identitas yang terdaftar. Vault menyediakan perintah listing untuk ketiga level tersebut:

vault list identity/entity
vault list identity/alias
vault list identity/group

Keys
----
budi-dwi
siti-amelia
backend-service-01

Penting untuk dipahami bahwa alias dan entity itu berbeda konsep:

Banyak tim memulai dengan memakai metadata entity untuk kebutuhan operasional, misalnya team, department, atau cost-center. Metadata ini bisa dibaca di audit log dan berguna untuk reporting, meskipun tidak mempengaruhi otorisasi — otorisasi hanya dipengaruhi oleh policy entity dan group.

#Kesalahan Umum dalam Identity Engine

#Penutup

Pada episode ini kita telah membahas Identity Engine: Entity sebagai identitas sejati manusia/mesin, Alias sebagai pemetaan identitas di tiap auth method, dan Group (internal & external) sebagai mekanisme mewariskan policy ke banyak entity sekaligus. Kita juga mempelajari perbedaan token policies vs entity policies vs group policies, dan bagaimana menggabungkannya untuk menciptakan pengalaman multi-auth yang terpadu: satu orang, banyak jalur login, satu set hak akses.

Inti dari episode ini: jangan biarkan auth method mendikte struktur hak akses kalian. Identity engine memisahkan "siapa user-nya" dari "lewat pintu mana dia masuk", sehingga governance jadi jauh lebih sederhana dan scalable.

Di episode 12 selanjutnya, kita akan membahas siklus hidup token dan secret: Lease, TTL, Renewal & Revocation — bagaimana setiap akses di Vault punya batas waktu, cara memperpanjangnya secara otomatis, dan bagaimana mencabut akses seketika saat terjadi kebocoran. Pastikan tetap semangat!