All Products
Search

This Product

    Container Service for Kubernetes:Gunakan proyeksi volume token ServiceAccount

    Document Center

    Container Service for Kubernetes:Gunakan proyeksi volume token ServiceAccount

    Last Updated:Aug 21, 2026

    Token ServiceAccount mengotentikasi komunikasi antara Pod dan server API Kubernetes. Pendekatan tradisional menyimpan token dalam Secrets dan memasangnya sebagai file—meninggalkan Pod rentan terhadap serangan penyamaran (impersonation), peningkatan hak istimewa, serta token usang yang tidak pernah kedaluwarsa. Proyeksi Volume Token Akun Layanan menghilangkan risiko ini dengan memasang token berumur pendek yang dibatasi berdasarkan audience secara langsung sebagai volume terproyeksi, tanpa bergantung pada Secrets.

    Latar Belakang

    Token ServiceAccount tradisional memiliki empat kelemahan keamanan struktural:

    • Audience tidak dibatasi: Token Web JSON (JWT) tidak memiliki batasan audience, sehingga token yang dikompromikan dapat digunakan ulang terhadap layanan apa pun di dalam kluster, memungkinkan serangan penyamaran.

    • Secrets terlalu berhak istimewa: Token disimpan dalam Secrets dan dikirimkan sebagai file ke node. Token komponen sistem sering kali memiliki izin yang melebihi kebutuhan beban kerja individual, memperluas permukaan serangan.

    • Tidak ada masa kedaluwarsa: JWT tetap valid sepanjang masa berlaku ServiceAccount. Rotasi token memerlukan penggantian manual kunci penandatangan—proses yang tidak diotomatisasi oleh client-go.

    • Penyebaran Secret berlebihan: Satu Secret per ServiceAccount mengurangi elastisitas kluster dalam skala besar.

    Proyeksi volume token ServiceAccount mengatasi keempat masalah tersebut. Token dibatasi untuk audience tertentu, kedaluwarsa setelah periode yang dapat dikonfigurasi, dan secara otomatis diputar oleh kubelet—tanpa memerlukan Secrets.

    Cara Kerja

    Ketika Pod dengan volume token ServiceAccount terproyeksi dimulai, kubelet meminta token berumur pendek yang ditandatangani dari server API dan menuliskannya ke jalur pemasangan yang dikonfigurasi di dalam kontainer. Kubelet memantau token tersebut dan secara proaktif meminta pengganti sebelum token kedaluwarsa. Aplikasi bertanggung jawab untuk memuat ulang file token saat rotasi terjadi; polling setiap lima menit sudah cukup untuk sebagian besar beban kerja.

    Prasyarat

    Sebelum memulai, pastikan Anda telah memiliki:

    • Kluster ACK yang dikelola, kluster khusus ACK, atau kluster ACK Serverless yang menjalankan Kubernetes versi 1.20 atau lebih baru. Lihat Buat kluster ACK yang dikelola, Buat kluster khusus ACK (tidak tersedia lagi), dan Buat kluster ACK Serverless.

    • Proyeksi Volume Token Akun Layanan diaktifkan pada kluster. Fitur ini aktif secara default pada kluster yang menjalankan Kubernetes 1.22 atau lebih baru. Untuk melakukan peningkatan, lihat Lakukan peningkatan manual kluster ACK.

      Saat diaktifkan, server API dan controller-manager secara otomatis mengonfigurasi parameter startup berikut:

      ParameterDeskripsiNilai defaultDapat dikonfigurasi melalui konsol
      service-account-issuerPenerbit token, dipetakan ke bidang iss dalam muatan JWThttps://kubernetes.default.svcYa
      api-audiencesIdentifier API yang digunakan untuk memvalidasi token masuk. Pisahkan beberapa nilai dengan koma (,).https://kubernetes.default.svcYa
      service-account-signing-key-fileJalur ke kunci privat yang digunakan untuk menandatangani token/etc/kubernetes/pki/sa.keyTidak (tetap pada nilai default)

    Langkah 1: Buat ServiceAccount

    Setiap namespace mencakup ServiceAccount default. Jalankan kubectl get serviceaccounts untuk menampilkan daftar akun yang ada di namespace saat ini.

    Untuk memberikan identitas berbeda pada Pod, buat ServiceAccount khusus:

    kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
EOF

    Verifikasi bahwa ServiceAccount telah dibuat:

    kubectl get serviceaccounts/build-robot -o yaml

    Langkah 2: Deploy Pod dengan proyeksi volume token

    Contoh berikut memasang token ServiceAccount terproyeksi ke dalam Pod nginx. Token tersebut dibatasi untuk audience vault dan kedaluwarsa setelah dua jam (7200 detik).

    1. Buat file bernama nginx.yaml:

      apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

    2. Terapkan manifes:

      kubectl apply -f nginx.yaml

    Verifikasi masa kedaluwarsa token

    1. Konfirmasi bahwa Pod sedang berjalan:

      kubectl get pod nginx

      Output yang diharapkan:

      NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          3m15s

    2. Ambil token dari kontainer:

      kubectl exec -t nginx -- cat /var/run/secrets/tokens/vault-token > vault-token

    3. Decode token dan tampilkan waktu kedaluwarsanya:

      cat vault-token | awk -F '.' '{print $2}' | base64 -d 2>/dev/null | jq '.exp' | xargs -I {} date -d @{}

      Contoh output:

      Mon  Aug 26 15:45:59 CST 2024

    Catatan Penggunaan

    Rotasi token: Kubelet secara otomatis memutar token sebelum kedaluwarsa. Konfigurasikan aplikasi Anda untuk memuat ulang file token secara berkala—polling setiap lima menit sudah cukup terlepas dari TTL aktualnya.

    Kompatibilitas SDK: Pemuatan ulang token otomatis di Go memerlukan client-go versi 10.0.0 atau lebih baru.

    Izin file: Izin file token ServiceAccount berubah dari 644 menjadi 600 saat menggunakan proyeksi volume token terikat. Jika fsGroup diatur dalam konteks keamanan Pod, izinnya menjadi 640.

    Langkah Selanjutnya