🥇Pengenalan kepada Kebenaran Kubernetes Konsul Hashicorp

Betul, selepas dikeluarkan Konsul Hashicorp 1.5.0 pada awal Mei 2019, di Konsul anda boleh membenarkan aplikasi dan perkhidmatan berjalan di Kubernetes secara asli.

Dalam tutorial ini kami akan membuat langkah demi langkah POC (Bukti konsep, PoC) yang menunjukkan ciri baharu ini. Anda dijangka mempunyai pengetahuan asas tentang Kubernetes dan Konsul Hashicorp. Walaupun anda boleh menggunakan mana-mana platform awan atau persekitaran di premis, dalam tutorial ini kami akan menggunakan Platform Awan Google.

Mengkaji

Jika kita pergi ke Dokumentasi konsul mengenai kaedah kebenarannya, kami akan mendapat gambaran keseluruhan pantas tentang tujuan dan kes penggunaannya, serta beberapa butiran teknikal dan gambaran keseluruhan logik. Saya sangat mengesyorkan membacanya sekurang-kurangnya sekali sebelum meneruskan, kerana saya kini akan menerangkan dan mengunyah semuanya.

Rajah 1: Gambaran keseluruhan rasmi kaedah kebenaran Konsul

Jom tengok masuk dokumentasi untuk kaedah kebenaran Kubernetes tertentu.

Sudah tentu, terdapat maklumat yang berguna di sana, tetapi tiada panduan tentang cara benar-benar menggunakan semuanya. Jadi, seperti mana-mana orang yang waras, anda menjelajah Internet untuk mendapatkan panduan. Dan kemudian... Anda gagal. Ia berlaku. Mari kita betulkan ini.

Sebelum kita meneruskan untuk mencipta POC kita, mari kita kembali kepada gambaran keseluruhan kaedah kebenaran Konsul (Rajah 1) dan memperhalusinya dalam konteks Kubernetes.

seni bina

Dalam tutorial ini, kami akan mencipta pelayan Konsul pada mesin berasingan yang akan berkomunikasi dengan kluster Kubernetes dengan klien Konsul dipasang. Kami kemudiannya akan membuat aplikasi dummy kami dalam pod dan menggunakan kaedah kebenaran yang dikonfigurasikan kami untuk membaca dari kedai kunci/nilai Konsul kami.

Rajah di bawah memperincikan seni bina yang kami cipta dalam tutorial ini, serta logik di sebalik kaedah kebenaran, yang akan diterangkan kemudian.

Rajah 2: Gambaran Keseluruhan Kaedah Kebenaran Kubernetes

Nota ringkas: pelayan Konsul tidak perlu tinggal di luar gugusan Kubernetes untuk ini berfungsi. Tetapi ya, dia boleh melakukannya dengan cara ini dan itu.

Jadi, mengambil gambar rajah gambaran keseluruhan Konsul (Rajah 1) dan menggunakan Kubernetes padanya, kami mendapat gambar rajah di atas (Rajah 2), dan logiknya di sini adalah seperti berikut:

Setiap pod akan mempunyai akaun perkhidmatan yang dilampirkan padanya yang mengandungi token JWT yang dijana dan diketahui oleh Kubernetes. Token ini juga dimasukkan ke dalam pod secara lalai.
Aplikasi atau perkhidmatan kami di dalam pod memulakan arahan log masuk kepada pelanggan Konsul kami. Permintaan log masuk juga akan menyertakan token dan nama kami dicipta khas kaedah kebenaran (jenis Kubernetes). Langkah #2 ini sepadan dengan langkah 1 rajah Konsul (Skim 1).
Pelanggan Konsul kami kemudiannya akan memajukan permintaan ini kepada pelayan Konsul kami.
MAGIC! Di sinilah pelayan Konsul mengesahkan kesahihan permintaan, mengumpul maklumat tentang identiti permintaan dan membandingkannya dengan mana-mana peraturan pratakrif yang berkaitan. Di bawah adalah satu lagi rajah untuk menggambarkan ini. Langkah ini sepadan dengan langkah 3, 4 dan 5 rajah gambaran keseluruhan Konsul (Rajah 1).
Pelayan Konsul kami menjana token Konsul dengan kebenaran mengikut peraturan kaedah kebenaran kami yang ditentukan (yang telah kami tentukan) berkenaan identiti peminta. Ia kemudiannya akan menghantar semula token itu. Ini sepadan dengan langkah 6 rajah Konsul (Rajah 1).
Pelanggan Konsul kami memajukan token kepada permohonan atau perkhidmatan yang meminta.

Aplikasi atau perkhidmatan kami kini boleh menggunakan token Konsul ini untuk berkomunikasi dengan data Konsul kami, seperti yang ditentukan oleh keistimewaan token.

Keajaiban terbongkar!

Bagi anda yang tidak berpuas hati dengan hanya seekor arnab yang keluar dari topi dan ingin tahu bagaimana ia berfungsi... izinkan saya "tunjukkan kepada anda sejauh mana lubang Arnab'.

Seperti yang dinyatakan sebelum ini, langkah "ajaib" kami (Rajah 2: Langkah 4) ialah tempat pelayan Konsul mengesahkan permintaan, mengumpul maklumat tentang permintaan dan membandingkannya dengan mana-mana peraturan pratakrif yang berkaitan. Langkah ini sepadan dengan langkah 3, 4 dan 5 rajah gambaran keseluruhan Konsul (Rajah 1). Di bawah adalah gambar rajah (Rajah 3), tujuannya adalah untuk menunjukkan dengan jelas apa yang sebenarnya berlaku di bawah tudung kaedah kebenaran Kubernetes tertentu.

Rajah 3: Keajaiban terbongkar!

Sebagai titik permulaan, pelanggan Konsul kami memajukan permintaan log masuk ke pelayan Konsul kami dengan token akaun Kubernetes dan nama contoh khusus bagi kaedah kebenaran yang telah dibuat sebelum ini. Langkah ini sepadan dengan langkah 3 dalam penjelasan litar sebelumnya.
Kini pelayan Konsul (atau ketua) perlu mengesahkan ketulenan token yang diterima. Oleh itu, ia akan merujuk kluster Kubernetes (melalui pelanggan Konsul) dan, dengan kebenaran yang sesuai, kami akan mengetahui sama ada token itu tulen dan milik siapa ia.
Permintaan yang disahkan kemudian dikembalikan kepada ketua Konsul, dan pelayan Konsul mencari contoh kaedah kebenaran dengan nama yang ditentukan daripada permintaan log masuk (dan jenis Kubernetes).
Ketua konsul mengenal pasti contoh kaedah kebenaran yang ditentukan (jika ditemui) dan membaca set peraturan mengikat yang dilampirkan padanya. Ia kemudian membaca peraturan ini dan membandingkannya dengan atribut identiti yang disahkan.
TA-dah! Mari kita teruskan ke langkah 5 dalam penjelasan litar sebelumnya.

Jalankan pelayan Konsul pada mesin maya biasa

Mulai sekarang, kebanyakannya saya akan memberikan arahan tentang cara membuat POC ini, selalunya dalam titik peluru, tanpa penjelasan ayat penuh. Selain itu, seperti yang dinyatakan sebelum ini, saya akan menggunakan GCP untuk mencipta semua infrastruktur, tetapi anda boleh mencipta infrastruktur yang sama di tempat lain.

Mulakan mesin maya (contoh/pelayan).

Buat peraturan untuk tembok api (kumpulan keselamatan dalam AWS):
Saya suka memberikan nama mesin yang sama kepada kedua-dua peraturan dan tag rangkaian, dalam kes ini "skywiz-consul-server-poc".
Cari alamat IP komputer tempatan anda dan tambahkannya pada senarai alamat IP sumber supaya kami boleh mengakses antara muka pengguna (UI).
Buka port 8500 untuk UI. Klik Buat. Kami akan menukar tembok api ini semula tidak lama lagi [pautan].
Tambahkan peraturan tembok api pada contoh. Kembali ke papan pemuka VM pada Pelayan Konsul dan tambahkan "skywiz-consul-server-poc" pada medan tag rangkaian. Klik Simpan.

Pasang Konsul pada mesin maya, semak di sini. Ingat anda memerlukan versi Konsul ≥ 1.5 [pautan]
Mari kita buat Konsul nod tunggal - konfigurasi adalah seperti 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 yang lebih terperinci tentang memasang Konsul dan menyediakan gugusan 3 nod, lihat di sini.
Cipta fail /etc/consul.d/agent.json seperti berikut [pautan]:

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

Mulakan pelayan 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 sepatutnya melihat sekumpulan output dan berakhir dengan "... kemas kini disekat oleh ACL."
Cari alamat IP luaran pelayan Konsul dan buka penyemak imbas dengan alamat IP ini pada port 8500. Pastikan UI dibuka.
Cuba tambah pasangan kunci/nilai. Mesti ada kesilapan. Ini kerana kami memuatkan pelayan Konsul dengan ACL dan melumpuhkan semua peraturan.
Kembali ke shell anda pada pelayan Konsul dan mulakan proses di latar belakang atau cara lain untuk menjalankannya dan masukkan yang berikut:

consul acl bootstrap

Cari nilai "SecretID" dan kembali ke UI. Dalam tab ACL, masukkan ID rahsia token yang baru anda salin. Salin SecretID di tempat lain, kami akan memerlukannya kemudian.
Sekarang tambahkan pasangan kunci/nilai. Untuk POC ini, tambahkan yang berikut: kunci: “custom-ns/test_key”, nilai: “Saya dalam folder custom-ns!”

Melancarkan kluster Kubernetes untuk aplikasi kami dengan pelanggan Konsul sebagai Daemonset

Buat gugusan K8s (Kubernetes). Kami akan menciptanya dalam zon yang sama dengan pelayan untuk akses yang lebih pantas, dan supaya kami boleh menggunakan subnet yang sama untuk menyambung dengan mudah dengan alamat IP dalaman. Kami akan memanggilnya "skywiz-app-with-consul-client-poc".

Sebagai nota sampingan, berikut ialah tutorial bagus yang saya temui semasa menyediakan kluster POC Consul dengan Consul Connect.
Kami juga akan menggunakan carta helm Hashicorp dengan fail nilai lanjutan.
Pasang dan konfigurasikan Helm. 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

carta helm: https://www.consul.io/docs/platform/k8s/helm.html
Gunakan fail nilai berikut (nota saya paling banyak melumpuhkan):

### 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

Gunakan carta helm:

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

Apabila ia cuba dijalankan, ia memerlukan kebenaran untuk pelayan Konsul, jadi mari tambahkannya.
Perhatikan "Julat Alamat Pod" yang terdapat pada papan pemuka kluster dan rujuk kembali peraturan tembok api "skywiz-consul-server-poc" kami.
Tambahkan julat alamat untuk pod ke senarai alamat IP dan buka port 8301 dan 8300.

Pergi ke UI Konsul dan selepas beberapa minit anda akan melihat kluster kami muncul dalam tab nod.

Mengkonfigurasi Kaedah Kebenaran dengan Mengintegrasikan Konsul dengan Kubernetes

Kembali ke cangkerang pelayan Konsul dan eksport token yang anda simpan sebelum ini:

export CONSUL_HTTP_TOKEN=<SecretID>

Kami memerlukan maklumat daripada kluster Kubernetes kami untuk membuat contoh kaedah pengesahan:
kubernetes-host

kubectl get endpoints | grep kubernetes

kubernetes-service-account-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:

Token ini dikodkan base64, jadi nyahsulitnya menggunakan alat kegemaran anda [pautan]
kubernetes-ca-cert

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

Ambil sijil "ca.crt" (selepas penyahkodan base64) dan tuliskannya ke dalam fail "ca.crt".
Sekarang nyatakan kaedah pengesahan, menggantikan ruang letak dengan nilai yang baru 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>"

Seterusnya kita perlu membuat peraturan dan melampirkannya pada peranan baharu. Untuk bahagian ini anda boleh menggunakan UI Konsul, tetapi kami akan menggunakan baris arahan.
Tulis peraturan

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

Gunakan peraturan

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

Cari ID peraturan yang baru anda buat daripada output.
Buat peranan dengan peraturan baharu.

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

Sekarang kami akan mengaitkan peranan baharu kami dengan contoh kaedah pengesahan. Ambil perhatian bahawa bendera "pemilih" menentukan sama ada permintaan log masuk kami akan menerima peranan ini. Semak di sini untuk pilihan pemilih lain: 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"'

Akhir sekali konfigurasi

Hak akses

Cipta hak akses. Kami perlu memberi kebenaran kepada Konsul untuk mengesahkan dan mengenal pasti identiti token akaun perkhidmatan K8s.
Tulis yang berikut pada fail [pautan]:

###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 buat hak akses

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

Menyambung kepada Pelanggan Konsul

Seperti yang dinyatakan di siniTerdapat beberapa pilihan untuk menyambung ke daemonset, tetapi kami akan beralih kepada penyelesaian mudah berikut:
Gunakan fail berikut [pautan].

### 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 arahan terbina berikut untuk mencipta peta konfigurasi [pautan]. Sila ambil perhatian bahawa kami merujuk kepada nama perkhidmatan kami, gantikannya 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 kaedah pengesahan

Sekarang mari kita lihat keajaiban dalam tindakan!

Buat beberapa folder kunci lagi dengan kunci peringkat atas yang sama (iaitu. /sample_key) dan nilai pilihan anda. Buat dasar dan peranan yang sesuai untuk laluan utama baharu. Kami akan melakukan pengikatan kemudian.

Ujian ruang nama tersuai:

Mari buat ruang nama kita sendiri:

kubectl create namespace custom-ns

Mari buat pod dalam ruang nama baharu kami. 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 bekas berjalan, pergi ke sana dan pasang curl.

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

Sekarang kami akan menghantar permintaan log masuk kepada Konsul menggunakan kaedah kebenaran yang kami buat sebelum ini [pautan].
Untuk melihat token yang dimasukkan daripada akaun perkhidmatan anda:

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

Tulis yang berikut pada fail di dalam bekas:

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

Log masuk!

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

Untuk melengkapkan langkah di atas dalam satu baris (memandangkan kami akan menjalankan berbilang ujian), anda boleh melakukan perkara 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

Berfungsi! Sekurang-kurangnya sepatutnya. Sekarang ambil SecretID dan cuba akses kunci/nilai yang sepatutnya kami akses.

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

Anda boleh base64 menyahkod "Nilai" dan melihat bahawa ia sepadan dengan nilai dalam custom-ns/test_key dalam UI. Jika anda menggunakan nilai yang sama di atas dalam tutorial ini, nilai anda yang dikodkan ialah IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Ujian akaun perkhidmatan pengguna:

Cipta Akaun Perkhidmatan tersuai menggunakan arahan berikut [pautan].

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

Buat fail konfigurasi baharu untuk pod. Sila ambil perhatian bahawa saya menyertakan pemasangan curl untuk menjimatkan 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

Selepas itu, jalankan shell di dalam bekas.

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

Log masuk!

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

Kebenaran ditolak. Oh, kami terlupa untuk menambah peraturan baharu yang mengikat dengan kebenaran yang sesuai, mari lakukannya sekarang.

Ulangi langkah sebelumnya di atas:
a) Buat Dasar yang sama untuk awalan “custom-sa/”.
b) Cipta Peranan, panggil "peranan tersuai"
c) Lampirkan Polisi pada Peranan.

Buat Rule-Binding (hanya mungkin daripada cli/api). Perhatikan maksud berbeza 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"'

Log masuk semula dari bekas "poc-ubuntu-custom-sa". Berjaya!
Lihat akses kami ke laluan kunci tersuai-sa/.

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

Anda juga boleh memastikan bahawa token ini tidak memberikan akses kepada kv dalam "custom-ns/". Hanya ulangi arahan di atas selepas menggantikan "custom-sa" dengan awalan "custom-ns".
Kebenaran ditolak.

Contoh tindanan:

Perlu diingat bahawa semua pemetaan yang mengikat peraturan akan ditambahkan pada token dengan hak ini.
Bekas kami "poc-ubuntu-custom-sa" berada dalam ruang nama lalai - jadi mari kita gunakannya untuk mengikat peraturan yang berbeza.
Ulangi langkah sebelumnya:
a) Buat Dasar yang sama untuk awalan kunci “lalai/”.
b) Cipta Peranan, namakannya "default-ns-role"
c) Lampirkan Polisi pada Peranan.
Buat Peraturan-Binding (hanya mungkin daripada 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 bekas "poc-ubuntu-custom-sa" kami dan cuba akses laluan kv "lalai/".
Kebenaran ditolak.
Anda boleh melihat bukti kelayakan yang ditentukan untuk setiap token dalam UI di bawah ACL > Token. Seperti yang anda lihat, token semasa kami hanya mempunyai satu "peranan tersuai" yang dilampirkan padanya. Token yang sedang kami gunakan telah dijana semasa kami log masuk dan hanya ada satu peraturan yang mengikat yang sepadan dengan itu. Kami perlu log masuk semula dan menggunakan token baharu.
Pastikan anda boleh membaca dari kedua-dua laluan kv "custom-sa/" dan "default/".
Kejayaan!
Ini kerana "poc-ubuntu-custom-sa" kami sepadan dengan pengikatan peraturan "custom-sa" dan "default-ns".

Kesimpulan

TTL token mgmt?

Pada masa penulisan ini, tiada cara bersepadu untuk menentukan TTL untuk token yang dijana oleh kaedah kebenaran ini. Ia akan menjadi peluang yang hebat untuk menyediakan automasi yang selamat bagi kebenaran Konsul.

Terdapat pilihan untuk membuat token secara manual dengan TTL:

https://www.consul.io/docs/acl/acl-system.html#acl-tokens
Masa Tamat - Masa token ini akan dibatalkan. (Pilihan; ditambah dalam Konsul 1.5.0)
Wujud hanya untuk penciptaan/kemas kini manual https://www.consul.io/api/acl/tokens.html#expirationtime

Semoga dalam masa terdekat kami akan dapat mengawal cara token dijana (setiap peraturan atau kaedah kebenaran) dan menambah TTL.

Sehingga itu, adalah dicadangkan anda menggunakan titik akhir log keluar dalam logik anda.

Pengenalan kepada Kebenaran Kubernetes Konsul Hashicorp