🥇Pengenalan Otorisasi Kubernetes Konsul Hashicorp

Itu benar, setelah rilis Konsul Hashicorp 1.5.0 pada awal Mei 2019, di Konsul Anda dapat mengotorisasi aplikasi dan layanan yang berjalan di Kubernetes secara asli.

Dalam tutorial ini kita akan membuat langkah demi langkah POC (Bukti konsep, PoC) mendemonstrasikan fitur baru ini. Anda diharapkan memiliki pengetahuan dasar tentang Kubernetes dan Konsul Hashicorp. Meskipun Anda dapat menggunakan platform cloud atau lingkungan lokal apa pun, dalam tutorial ini kita akan menggunakan Cloud Platform Google.

Tinjau

Jika kita pergi ke Konsul dokumentasi tentang metode otorisasinya, kita akan mendapatkan gambaran singkat tentang tujuan dan kasus penggunaannya, serta beberapa detail teknis dan gambaran umum logikanya. Saya sangat merekomendasikan membacanya setidaknya sekali sebelum melanjutkan, karena sekarang saya akan menjelaskan dan mengunyah semuanya.

Diagram 1: Ikhtisar resmi metode otorisasi Konsul

Mari kita lihat ke dalam dokumentasi untuk metode otorisasi Kubernetes tertentu.

Tentu, ada informasi berguna di sana, tetapi tidak ada panduan tentang cara menggunakan semuanya. Jadi, seperti orang waras lainnya, Anda menjelajahi Internet untuk mencari panduan. Dan kemudian... Anda gagal. Itu terjadi. Mari kita perbaiki ini.

Sebelum melanjutkan ke pembuatan POC, mari kita kembali ke ikhtisar metode otorisasi Konsul (Diagram 1) dan menyempurnakannya dalam konteks Kubernetes.

Arsitektur

Dalam tutorial ini, kita akan membuat server Konsul pada mesin terpisah yang akan berkomunikasi dengan cluster Kubernetes dengan klien Konsul terinstal. Kami kemudian akan membuat aplikasi tiruan kami di pod dan menggunakan metode otorisasi yang dikonfigurasi untuk membaca dari penyimpanan kunci/nilai Konsul kami.

Diagram di bawah merinci arsitektur yang kita buat dalam tutorial ini, serta logika di balik metode otorisasi, yang akan dijelaskan nanti.

Diagram 2: Ikhtisar Metode Otorisasi Kubernetes

Catatan singkat: server Konsul tidak perlu berada di luar cluster Kubernetes agar ini dapat berfungsi. Tapi ya, dia bisa melakukannya dengan cara ini dan itu.

Jadi, dengan mengambil diagram ikhtisar Konsul (Diagram 1) dan menerapkan Kubernetes ke dalamnya, kita mendapatkan diagram di atas (Diagram 2), dan logikanya adalah sebagai berikut:

Setiap pod akan memiliki akun layanan yang berisi token JWT yang dihasilkan dan diketahui oleh Kubernetes. Token ini juga dimasukkan ke dalam pod secara default.
Aplikasi atau layanan kami di dalam pod memulai perintah login ke klien Konsul kami. Permintaan login juga akan menyertakan token dan nama kami dibuat secara khusus metode otorisasi (tipe Kubernetes). Langkah #2 ini sesuai dengan langkah 1 diagram Konsul (Skema 1).
Klien Konsul kami kemudian akan meneruskan permintaan ini ke server Konsul kami.
SIHIR! Di sinilah server Konsul memverifikasi keaslian permintaan, mengumpulkan informasi tentang identitas permintaan dan membandingkannya dengan aturan terkait yang telah ditentukan sebelumnya. Di bawah ini adalah diagram lain untuk menggambarkan hal ini. Langkah ini sesuai dengan langkah 3, 4 dan 5 diagram ikhtisar Konsul (Diagram 1).
Server Konsul kami menghasilkan token Konsul dengan izin sesuai dengan aturan metode otorisasi yang kami tentukan (yang telah kami tetapkan) mengenai identitas pemohon. Kemudian token itu akan dikirim kembali. Hal ini sesuai dengan langkah 6 diagram Konsul (Diagram 1).
Klien Konsul kami meneruskan token ke aplikasi atau layanan yang meminta.

Aplikasi atau layanan kami sekarang dapat menggunakan token Konsul ini untuk berkomunikasi dengan data Konsul kami, sebagaimana ditentukan oleh hak istimewa token tersebut.

Keajaiban terungkap!

Bagi anda yang tidak senang hanya dengan kelinci keluar dari topi dan ingin tahu cara kerjanya... izinkan saya "tunjukkan seberapa dalam lubang kelinci'.

Seperti disebutkan sebelumnya, langkah "ajaib" kami (Gambar 2: Langkah 4) adalah saat server Konsul mengautentikasi permintaan, mengumpulkan informasi tentang permintaan tersebut, dan membandingkannya dengan aturan terkait yang telah ditentukan sebelumnya. Langkah ini sesuai dengan langkah 3, 4 dan 5 diagram ikhtisar Konsul (Diagram 1). Di bawah ini adalah diagram (Diagram 3), yang tujuannya adalah untuk menunjukkan dengan jelas apa yang sebenarnya terjadi Dibawah tenda metode otorisasi Kubernetes tertentu.

Diagram 3: Keajaiban terungkap!

Sebagai titik awal, klien Konsul kami meneruskan permintaan login ke server Konsul kami dengan token akun Kubernetes dan nama instance spesifik dari metode otorisasi yang telah dibuat sebelumnya. Langkah ini sesuai dengan langkah 3 pada penjelasan rangkaian sebelumnya.
Sekarang server Konsul (atau pemimpin) perlu memverifikasi keaslian token yang diterima. Oleh karena itu, ia akan berkonsultasi dengan cluster Kubernetes (melalui klien Konsul) dan, dengan izin yang sesuai, kami akan mengetahui apakah token tersebut asli dan milik siapa.
Permintaan yang divalidasi kemudian dikembalikan ke pemimpin Konsul, dan server Konsul mencari contoh metode otorisasi dengan nama yang ditentukan dari permintaan login (dan tipe Kubernetes).
Pemimpin konsul mengidentifikasi contoh metode otorisasi yang ditentukan (jika ditemukan) dan membaca seperangkat aturan mengikat yang dilampirkan padanya. Ia kemudian membaca aturan-aturan ini dan membandingkannya dengan atribut identitas terverifikasi.
TA-dah! Mari kita lanjutkan ke langkah 5 pada penjelasan rangkaian sebelumnya.

Jalankan Consul-server di mesin virtual biasa

Mulai sekarang, saya akan lebih banyak memberikan instruksi tentang cara membuat POC ini, sering kali dalam poin-poin, tanpa penjelasan kalimat lengkap. Selain itu, seperti disebutkan sebelumnya, saya akan menggunakan GCP untuk membuat semua infrastruktur, namun Anda dapat membuat infrastruktur yang sama di tempat lain.

Mulai mesin virtual (instance/server).

Buat aturan untuk firewall (grup keamanan di AWS):
Saya ingin menetapkan nama mesin yang sama untuk aturan dan tag jaringan, dalam hal ini "skywiz-consul-server-poc".
Temukan alamat IP komputer lokal Anda dan tambahkan ke daftar alamat IP sumber sehingga kami dapat mengakses antarmuka pengguna (UI).
Buka port 8500 untuk UI. Klik Buat. Kami akan segera mengubah firewall ini lagi [link].
Tambahkan aturan firewall ke instans. Kembali ke dasbor VM di Server Konsul dan tambahkan “skywiz-consul-server-poc” ke bidang tag jaringan. Klik Simpan.

Instal Konsul di mesin virtual, periksa di sini. Ingat Anda memerlukan versi Konsul ≥ 1.5 [link]
Mari kita buat satu node Konsul - konfigurasinya adalah sebagai berikut.

groupadd --system consul
useradd -s /sbin/nologin --system -g consul consul
mkdir -p /var/lib/consul
chown -R consul:consul /var/lib/consul
chmod -R 775 /var/lib/consul
mkdir /etc/consul.d
chown -R consul:consul /etc/consul.d

Untuk panduan lebih rinci tentang cara menginstal Konsul dan menyiapkan cluster yang terdiri dari 3 node, lihat di sini.
Buat file /etc/consul.d/agent.json sebagai berikut [link]:

### /etc/consul.d/agent.json
{
 "acl" : {
 "enabled": true,
 "default_policy": "deny",
 "enable_token_persistence": true
 }
}

Mulai server Konsul kami:

consul agent 
-server 
-ui 
-client 0.0.0.0 
-data-dir=/var/lib/consul 
-bootstrap-expect=1 
-config-dir=/etc/consul.d

Anda akan melihat banyak keluaran dan berakhir dengan "... pembaruan diblokir oleh ACL."
Temukan alamat IP eksternal server Konsul dan buka browser dengan alamat IP ini pada port 8500. Pastikan UI terbuka.
Coba tambahkan pasangan kunci/nilai. Pasti ada kesalahan. Ini karena kami memuat server Konsul dengan ACL dan menonaktifkan semua aturan.
Kembali ke shell Anda di server Konsul dan mulai proses di latar belakang atau cara lain untuk menjalankannya dan masukkan yang berikut ini:

consul acl bootstrap

Temukan nilai "SecretID" dan kembali ke UI. Di tab ACL, masukkan ID rahasia token yang baru saja Anda salin. Salin SecretID di tempat lain, kita akan membutuhkannya nanti.
Sekarang tambahkan pasangan kunci/nilai. Untuk POC ini, tambahkan yang berikut: key: “custom-ns/test_key”, value: “Saya berada di folder custom-ns!”

Meluncurkan cluster Kubernetes untuk aplikasi kita dengan klien Konsul sebagai Daemonset

Buat kluster K8s (Kubernetes). Kami akan membuatnya di zona yang sama dengan server untuk akses lebih cepat, sehingga kami dapat menggunakan subnet yang sama untuk terhubung dengan mudah dengan alamat IP internal. Kami akan menyebutnya "skywiz-app-with-consul-client-poc".

Sebagai catatan tambahan, berikut adalah tutorial bagus yang saya temukan saat menyiapkan cluster Konsul POC dengan Consul Connect.
Kami juga akan menggunakan bagan helm Hashicorp dengan file nilai yang diperluas.
Instal dan konfigurasikan Helm. Langkah-langkah konfigurasi:

kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-admin-binding 
   --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
./helm init --service-account=tiller
./helm update

bagan kemudi: https://www.consul.io/docs/platform/k8s/helm.html
Gunakan file nilai berikut (catatan saya telah menonaktifkan sebagian besar):

### poc-helm-consul-values.yaml
global:
 enabled: false
 image: "consul:latest"
# Expose the Consul UI through this LoadBalancer
ui:
 enabled: false
# Allow Consul to inject the Connect proxy into Kubernetes containers
connectInject:
 enabled: false
# Configure a Consul client on Kubernetes nodes. GRPC listener is required for Connect.
client:
 enabled: true
 join: ["<PRIVATE_IP_CONSUL_SERVER>"]
 extraConfig: |
{
  "acl" : {
 "enabled": true,   
 "default_policy": "deny",   
 "enable_token_persistence": true 
  }
}
# Minimal Consul configuration. Not suitable for production.
server:
 enabled: false
# Sync Kubernetes and Consul services
syncCatalog:
 enabled: false

Terapkan bagan kemudi:

./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc

Saat mencoba dijalankan, diperlukan izin untuk server Konsul, jadi mari tambahkan.
Catat “Rentang Alamat Pod” yang terletak di dasbor cluster dan lihat kembali aturan firewall “skywiz-consul-server-poc” kami.
Tambahkan rentang alamat pod ke daftar alamat IP dan buka port 8301 dan 8300.

Buka UI Konsul dan setelah beberapa menit Anda akan melihat cluster kami muncul di tab node.

Mengonfigurasi Metode Otorisasi dengan Mengintegrasikan Konsul dengan Kubernetes

Kembali ke shell server Konsul dan ekspor token yang Anda simpan sebelumnya:

export CONSUL_HTTP_TOKEN=<SecretID>

Kami memerlukan informasi dari cluster Kubernetes untuk membuat instance metode autentikasi:
kubernetes-host

kubectl get endpoints | grep kubernetes

kubernetes-layanan-akun-jwt

kubectl get sa <helm_deployment_name>-consul-client -o yaml | grep "- name:"
kubectl get secret <secret_name_from_prev_command> -o yaml | grep token:

Tokennya dikodekan base64, jadi dekripsi menggunakan alat favorit Anda [link]
kubernetes-ca-cert

kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:

Ambil sertifikat “ca.crt” (setelah decoding base64) dan tulis ke dalam file “ca.crt”.
Sekarang buat instance metode autentikasi, ganti placeholder dengan nilai yang baru saja Anda terima.

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "This is an auth method using kubernetes for the cluster skywiz-app-with-consul-client-poc" 
-kubernetes-host "<k8s_endpoint_retrieved earlier>" 
[email protected] 
-kubernetes-service-account-
jwt="<decoded_token_retrieved_earlier>"

Selanjutnya kita perlu membuat aturan dan melampirkannya ke peran baru. Untuk bagian ini bisa menggunakan Consul UI, namun kita akan menggunakan command line.
Tulis aturan

### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
 policy = "write"
}

Terapkan aturannya

consul acl policy create 
-name kv-custom-ns-policy 
-description "This is an example policy for kv at custom-ns/" 
-rules @kv-custom-ns-policy.hcl

Temukan ID aturan yang baru saja Anda buat dari output.
Buat peran dengan aturan baru.

consul acl role create 
-name "custom-ns-role" 
-description "This is an example role for custom-ns namespace" 
-policy-id <policy_id>

Sekarang kita akan mengaitkan peran baru kita dengan contoh metode autentikasi. Perhatikan bahwa tanda "pemilih" menentukan apakah permintaan login kita akan menerima peran ini. Periksa di sini untuk opsi pemilih lainnya: https://www.consul.io/docs/acl/auth-methods/kubernetes.html#trusted-identity-attributes

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-ns-role' 
-selector='serviceaccount.namespace=="custom-ns"'

Konfigurasi terakhir

Hak akses

Buat hak akses. Kita perlu memberikan izin kepada Konsul untuk memverifikasi dan mengidentifikasi identitas token akun layanan K8.
Tulis yang berikut ini ke file [tautan]:

###skywiz-poc-consul-server_rbac.yaml
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: review-tokens
 namespace: default
subjects:
- kind: ServiceAccount
 name: skywiz-app-with-consul-client-poc-consul-client
 namespace: default
roleRef:
 kind: ClusterRole
 name: system:auth-delegator
 apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: service-account-getter
 namespace: default
rules:
- apiGroups: [""]
 resources: ["serviceaccounts"]
 verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: get-service-accounts
 namespace: default
subjects:
- kind: ServiceAccount
 name: skywiz-app-with-consul-client-poc-consul-client
 namespace: default
roleRef:
 kind: ClusterRole
 name: service-account-getter
 apiGroup: rbac.authorization.k8s.io

Mari kita buat hak akses

kubectl create -f skywiz-poc-consul-server_rbac.yaml

Menghubungkan ke Klien Konsul

Seperti disebutkan di siniAda beberapa opsi untuk menghubungkan ke daemonset, tapi kami akan beralih ke solusi sederhana berikut:
Terapkan file berikut [link].

### poc-consul-client-ds-svc.yaml
apiVersion: v1
kind: Service
metadata:
 name: consul-ds-client
spec:
 selector:
   app: consul
   chart: consul-helm
   component: client
   hasDNS: "true"
   release: skywiz-app-with-consul-client-poc
 ports:
 - protocol: TCP
   port: 80
   targetPort: 8500

Kemudian gunakan perintah bawaan berikut untuk membuat configmap [link]. Harap dicatat bahwa kami mengacu pada nama layanan kami, ganti jika perlu.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
 labels:
   addonmanager.kubernetes.io/mode: EnsureExists
 name: kube-dns
 namespace: kube-system
data:
 stubDomains: |
   {"consul": ["$(kubectl get svc consul-ds-client -o jsonpath='{.spec.clusterIP}')"]}
EOF

Menguji metode autentikasi

Sekarang mari kita lihat keajaiban beraksi!

Buat beberapa folder kunci lagi dengan kunci tingkat atas yang sama (mis. /sample_key) dan nilai pilihan Anda. Buat kebijakan dan peran yang sesuai untuk jalur utama baru. Kami akan melakukan pengikatannya nanti.

Tes namespace khusus:

Mari buat namespace kita sendiri:

kubectl create namespace custom-ns

Mari buat pod di namespace baru kita. Tulis konfigurasi untuk pod.

###poc-ubuntu-custom-ns.yaml
apiVersion: v1
kind: Pod
metadata:
 name: poc-ubuntu-custom-ns
 namespace: custom-ns
spec:
 containers:
 - name: poc-ubuntu-custom-ns
   image: ubuntu
   command: ["/bin/bash", "-ec", "sleep infinity"]
 restartPolicy: Never

Buat di bawah:

kubectl create -f poc-ubuntu-custom-ns.yaml

Setelah container berjalan, pergi ke sana dan instal curl.

kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y

Sekarang kami akan mengirimkan permintaan login ke Konsul menggunakan metode otorisasi yang kami buat sebelumnya [link].
Untuk melihat token yang dimasukkan dari akun layanan Anda:

cat /run/secrets/kubernetes.io/serviceaccount/token

Tulis yang berikut ini ke file di dalam wadah:

### payload.json
{
 "AuthMethod": "auth-method-test",
 "BearerToken": "<jwt_token>"
}

Gabung!

curl 
--request POST 
--data @payload.json 
consul-ds-client.default.svc.cluster.local/v1/acl/login

Untuk menyelesaikan langkah-langkah di atas dalam satu baris (karena kita akan menjalankan beberapa pengujian), Anda dapat melakukan hal berikut:

echo "{ 
"AuthMethod": "auth-method-skywiz-consul-poc", 
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)" 
}" 
| curl 
--request POST 
--data @- 
consul-ds-client.default.svc.cluster.local/v1/acl/login

Berhasil! Setidaknya memang seharusnya demikian. Sekarang ambil SecretID dan coba akses kunci/nilai yang seharusnya kita akses.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”

Anda dapat mendekode "Nilai" base64 dan melihatnya cocok dengan nilai di custom-ns/test_key di UI. Jika Anda menggunakan nilai yang sama di atas dalam tutorial ini, nilai yang dikodekan adalah IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Tes akun layanan pengguna:

Buat ServiceAccount kustom menggunakan perintah berikut [link].

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: custom-sa
EOF

Buat file konfigurasi baru untuk pod. Harap dicatat bahwa saya menyertakan instalasi curl untuk menghemat tenaga kerja :)

###poc-ubuntu-custom-sa.yaml
apiVersion: v1
kind: Pod
metadata:
 name: poc-ubuntu-custom-sa
 namespace: default
spec:
 serviceAccountName: custom-sa
 containers:
 - name: poc-ubuntu-custom-sa
   image: ubuntu
   command: ["/bin/bash","-ec"]
   args: ["apt-get update && apt-get install curl -y; sleep infinity"]
 restartPolicy: Never

Setelah itu, jalankan shell di dalam wadah.

kubectl exec -it poc-ubuntu-custom-sa /bin/bash

Gabung!

echo "{ 
"AuthMethod": "auth-method-skywiz-consul-poc", 
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)" 
}" 
| curl 
--request POST 
--data @- 
consul-ds-client.default.svc.cluster.local/v1/acl/login

Izin ditolak. Oh, kami lupa menambahkan aturan baru yang mengikat dengan izin yang sesuai, ayo lakukan sekarang.

Ulangi langkah sebelumnya di atas:
a) Buat Kebijakan yang identik untuk awalan “custom-sa/”.
b) Buat Peran, sebut saja “peran khusus”
c) Lampirkan Kebijakan pada Peran tersebut.

Buat Pengikatan Aturan (hanya dapat dilakukan dari cli/api). Perhatikan perbedaan arti dari bendera pemilih.

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-sa-role' 
-selector='serviceaccount.name=="custom-sa"'

Masuk lagi dari wadah "poc-ubuntu-custom-sa". Kesuksesan!
Lihat akses kami ke jalur custom-sa/key.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”

Anda juga dapat memastikan bahwa token ini tidak memberikan akses ke kv di "custom-ns/". Ulangi saja perintah di atas setelah mengganti "custom-sa" dengan awalan "custom-ns".
Izin ditolak.

Contoh hamparan:

Perlu diperhatikan bahwa semua pemetaan yang mengikat aturan akan ditambahkan ke token dengan hak ini.
Wadah kita "poc-ubuntu-custom-sa" ada di namespace default - jadi mari kita gunakan untuk pengikatan aturan yang berbeda.
Ulangi langkah sebelumnya:
a) Buat Kebijakan yang identik untuk awalan kunci “default/”.
b) Buat Peran, beri nama “default-ns-role”
c) Lampirkan Kebijakan pada Peran tersebut.
Buat Pengikatan Aturan (hanya dapat dilakukan dari cli/api)

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='default-ns-role' 
-selector='serviceaccount.namespace=="default"'

Kembali ke wadah "poc-ubuntu-custom-sa" kami dan coba akses jalur kv "default/".
Izin ditolak.
Anda dapat melihat kredensial yang ditentukan untuk setiap token di UI pada ACL > Tokens. Seperti yang Anda lihat, token kami saat ini hanya memiliki satu “peran khusus” yang melekat padanya. Token yang kami gunakan saat ini dibuat saat kami masuk dan hanya ada satu pengikatan aturan yang cocok saat itu. Kita perlu login lagi dan menggunakan token baru.
Pastikan Anda dapat membaca dari jalur kv "custom-sa/" dan "default/".
Sukses!
Ini karena “poc-ubuntu-custom-sa” kami cocok dengan ikatan aturan “custom-sa” dan “default-ns”.

Kesimpulan

Manajemen token TTL?

Pada saat penulisan ini, belum ada cara terintegrasi untuk menentukan TTL untuk token yang dihasilkan dengan metode otorisasi ini. Ini akan menjadi peluang luar biasa untuk menyediakan otomatisasi otorisasi Konsul yang aman.

Ada opsi untuk membuat token secara manual dengan TTL:

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
Waktu Kedaluwarsa - Waktu di mana token ini akan dicabut. (Opsional; ditambahkan di Konsul 1.5.0)
Hanya ada untuk pembuatan/pembaruan manual https://www.consul.io/api/acl/tokens.html#expirationtime

Mudah-mudahan dalam waktu dekat kami dapat mengontrol cara pembuatan token (sesuai aturan atau metode otorisasi) dan menambahkan TTL.

Sampai saat itu tiba, disarankan agar Anda menggunakan titik akhir logout dalam logika Anda.

Pengantar Otorisasi Kubernetes Konsul Hashicorp